Journal

On Friday, I finally made a Twitter! If you have any good recommended accounts to follow, please feel free to add them in the comments below. An active Twitter really seems to be a requirement of modern tech, and I’m hoping I can warm up to using it with time.

My weekend has been filled with lots of reading across both Saturday and Sunday, as I had been accumulating a hefty backlog of tabs, articles, tasks, and notes. An article that I did see immediately recommended in my Twitter feed was Getting Over the Fear of Open Source. The key points made in the article was that initially contributing to open source is scary, but it provides two key experiences:

  • Working with a large code base
  • Working in a group environment

Getting over that initial fear of contributing to open source will ideally help me to dive into new projects with more confidence. This is critical exposure that prospective employers would be looking for in someone without prior development job experience, as well.

It will be interesting to see what my Hacktoberfest experience will be like. With my background, I have architected and developed entire application platforms by myself, such as a cement mixer line with over 8 million possible configurations of interface packages, hardware, truck body components, accessories, and functions, spanning across multiple devices, languages, and IDEs. I do not know how intimidated I will be by just a large application, but my suspicion is that finding something I can technically handle with my current skills and overcoming my insecurities about where I am in my learning process will be the larger challenges.

Like the article above, I’ve run into DEV.to a few times now but haven’t looked into it too closely, as my initial impression was that it was Medium but for tech. I’ve stayed away from social media platforms for over the past half-decade for my mental health, but now that I’m slowly re-engaging with a selective and professional mindset, I’m more willing to bite and and looked up some of the pros and cons of each. Long story short, there’s a new DEV button in my footer now! I’m not sure if I will be reposting content from Learning Log to DEV…at least probably not for a while, and undoubtedly “blog” content over “log” content.

…Does that distinction make sense to anyone reading this? I’ve tried to be consistent when referencing it, but “logs” are what I consider these daily entries, whereas “blogs” will be stand-alone content with a full narrative arch, and usually longer format. Perhaps that makes more sense inherently since this content you’re reading right now is absolutely not standard to the typical developer blogs online.

Almost immediately after signing up with DEV, I saw a book in my feed - Your First Year in Code. Skimming the summary makes me think that this might be exactly something that I need to read right now, so that’s now on my active reading list and I will be carrying it around with me to read in my free time. Similarly, I serendipitously encountered a massive reddit post titled Getting Started, which is now in my bookmarks bar. These resources sound like the kind of content that I want to capture with this blog, albeit in a very raw form, and from the specific perspective of someone switching from an already successful and well-established career.

The next item in my reading list was about what job-seeking developers need in their GitHub. I realize that the state of my repositories, at the present moment, is not great - boilerplate reademes, incomplete or non-functional projects, and a bunch of different directions. Polishing these repositories and completing the projects should absolutely be a priority on my pre-application checklist. The article makes the point that my portfolio should highlight:

  • Variety
  • Completeness
  • Functionality
  • Performance
  • Readability
  • Documentation

As far as the kinds of projects to showcase, it recommends:

  • Websites
  • Programming exercises (this is a great idea!)
  • Games
  • Mobile apps
  • Scripts, utilities, and plug-ins
  • Employer-targeted code
  • Contributions to other users’ projects

Another item I had pulled aside is called 9 Habits I Wish I Had as a Junior Developer. The habits identified are:

  • Volunteer for things you don’t know
  • Ask to pair up
  • Talk about what you’re doing and what you’re not doing
  • Write a blog
  • Have a notebook and a system
  • Keep notes about your wins
  • Have a time slot for important tasks
  • When stuck, take a break
  • Don’t chase silver bullets

Thankfully, I already practice more than half of these daily! Some I started doing when I instituted them at my day job, others I’ve done in my daily life, and some of them have come from Learning Log and the learning process. I do frequently use physical notebooks for note taking, and heavily lean on digital services like Trello and Todoist for most other items and notes. Moving forward, I think that I would like to transition to a more formal note system, similar to what my wife uses. She has a small A5 latching ring notebook as her primary book, and is constantly taking notes, creating pages, reorganizing and sorting, and maintaining a highly organized and easy-to-follow record.

One note the author included was “habit stacking,” and using the end of a pomodoro cycle as an indicator to stand up, stretch, and drink some water. I love this idea, as I do tend to not fully engage with the end of a cycle and slip right back into where I left off before the break ends, especially when I’m stuck. I’m writing this bit early in the morning on Sunday, so I will try to start doing it when I come back to writing later.

Scrolling through other threads, I encountered this great comment on how to organize development projects on your computer and to avoid code hoarding. I do not currently have a great system for keeping these projects organized, but as I scale from 10 projects to 100 projects, putting a system in place will be critical.

Unfortunately, it’s getting close to bedtime on Sunday night, and I’ve run out of time to write my full reflections on everything from this weekend. The next few items below were articles that stood out as being informative or useful, which I am adding to preserve:

Reviewing progression items to sort, I realized that the scope of the items varies wildly - some were blogs with a 15 minute read time, whereas others were 6 month programs. I may be collecting progression items and recording my impressions and notes, but I’m not collecting much about the items themselves. This presents a tremendous opportunity to help prioritize learning and set schedules, as well as evaluate my own perceived value of the items for future learners and general reference.

Some progression items have seen highly suggested from skilled developers and sites, whereas some items I have collected from lists or encountered naturally myself. Using an estimated value system, I would like to record the communicated value of the resource depending on the quality of the source, and then I can follow up with an “actual” value number to evaluate how the resource compares to other similar resources. The scale I think I would like to use is a +/- from 5, being neutral expectations of item value, where numbers greater than 5 indicate how much more valuable the item was compared to my expectations, and how much less for values under 5.

The issue with this “Value” approach is that it will likely be subject to ceiling and floor effects, similar to the log-based “Importance” value. For that, I really should look into using Gwern’s Resorter to re-prioritize the entries as I complete them. Creating a file with Liquid to scrape out the comparison data at build should be simple, however if I want progression items to be grouped only with similar items, I may need to employ a RubyGem to create multiple documents. With this process, I’d imagine it might be possible to use the same gem to take the resorted results and push them back into the progression entries…which would absolutely be worth looking into!

With the new progression data fields added to all existing entries and with a few with values, another thing I’ve wanted to work on is establishing a roadmap for my learning and, ideally, future career. It will give me a place to capture data and goals that will be critical for long-term success, but may be difficult to put into context otherwise. It is a very rough draft right now, but I have the roadmap broken down from short-term objectives out to senior-level leadership. The roadmap is currently accessible from either the About page or the navbar. The navbar is a bit too long again with it up there, however…so that may get changed.

Tasklist

  • Read through my open tabs and backlog
  • Start working on a roadmap for breaking into tech - treat it like a project and identify features, milestones, metrics, and timelines for tasks
  • Progression item improvements
    • Add “est-duration” (estimated duration, in minutes) to progression items to help prioritize and select tasks.
    • Add a 0-10 “est-benefit” (estimated benefit) value to progression items to prioritize high-value resources
    • Add a 0-10 “act-benefit” (actual benefit) value to progression items to help identify/aggregate high-value resources for future learners and as reference
  • Add DEV and Sourcerer social media buttons
  • =>May need to add a months value to min-to-time? Years??
  • => Set up and test Resorter
    • => Collect post importance metrics in Liquid for resorting