Journal

Missing those podcast vibes this morning, I picked out a new podcast to start. After finishing The Learning Developer’s Podcast, I had bulk-subscribed to a fistful of active and popular development podcasts. Developer Tea, in particular, sounded great and I had seen it heavily recommended in a few different places.

My normal method for consuming podcasts is to start at the beginning and then work my way forward. With frequently long commutes and especially with how much I was travelling pre-COVID, I could rapidly get up to speed in just about everything as long as the content was being released at a normal rate. Nowadays, less travel and a shorter commute means that catching up will probably take long. For most things, that’s not going to matter, but for development… it may be an issue depending on the topics?

Practices improve, toolsets get disrupted, market trends change, and being aware of where things are right now will be critical to break into the market and perform well immediately. The history and why we do things is extremely important and interesting to me, but also requires supporting information for the history to make sense, and to give context around why things are important or impactful. As such, I think I might need to start from the latest posts and check out a few different podcasts, and perhaps pick and choose from titles.

Thankfully, most of the handful of episodes of Developer Tea I’ve heard so far seem to give pretty great general information, and appear to be mindfully crafted to hold up with time. Lots of lists and quotes, too! For example:

“The best workers are those that work towards an excellence level and not a work hour number.”

Jonathan Cutrell, Developer Tea

It may not seem like it, but part of my aim with Learning Log has been to provide quantifiable context for my relative experience with topics. Time is a poor indicator of excellence (which we see well-documented in tenure-based career progression versus merit-based), and some days the quality of my learning and progress is better than others. I am not clocking when I am working on a particular individual skill and recording them independently (partially because my focus for these logs is usually smaller chunks of time (2-4 hours) or large chunks of working on a specific project), nor do I feel like that would add value to myself or the reader. If I recorded only time towards CSS when I was writing CSS, and then only recording time when I switched back to React, I’d probably end up spending more time recording time than developing either of those skills along the way! It’s not like my brain isn’t also thinking about both approaches at the same time, either - specifically the combination of skills is what I’m building.

You may have noticed that my times are rounded to the nearest 5 minutes with few exceptions - this is intentional. My normal logging workflow is to add my time in chunks to the post data as I work, from start time to end time, and I round down to that nearest 5 minute chunk. I definitely lose visibility on a growing chunk of time in the grand picture, but I would rather under-promise (how much time I spent) and over-deliver (my relative familiarity and ability with said skill). When a skill hits 10,000 hours (416 days and 16 hours, if I don’t change the formatting in my Skills table by the time you’re reading this), I’d like to feel confident that it’s not premature!

The goal is to show where my time is going in broad strokes to expose trends and focuses, and to give a sense of the overall commitment that I have made through this process. Rather than having a large list of things that I may-or-may-have-not worked with very much, plus an arbitrary number ranking system to denote my self-evaluated proficiency… I can just show you the numbers. Math can help simplify the evaluation, sure, but otherwise you can see for yourself most of what I’ve done since starting this log. This information, coupled with the quality of the work I aim to produce, should help illustrate the target of “excellence” that I am striving for.

“Developers who are focused on what they have done in the past appear to be riding on their previous momentum, while developers who are focused on what they are going to do tomorrow are riding on the value that they can create every day.”

Jonathan Cutrell, Developer Tea

While much of this site is focused on capturing the past, one area that I have been personally very interested in is the Tasks page. I’ve quickly amassed a backlog of projects to work towards, so there’s no shortage of things to work on lately, but by having my site automatically suggest where I could focus and what I can do to be more successful going forward has been very helpful. I’ve been thinking recently that it might be good for me to include a list of projects by status, as well - I have badges added to some projects to help indicate progress, but this is a little cumbersome to update.

Something else that I saw shared on Twitter was to make commitments for the week ahead. Say what you’re going to be working on, and then show that you’re doing it. My social media game is frankly super weak, but this may be a way to generate some content, challenge myself to stick to it, and hopefully communicate some consistency along the way.

As far as progress, I’ve once again amassed a huge backlog of reading material that I genuinely would like to get to, so I worked on whittling down that list a little tonight. Maybe it’d be a good idea if I looked into training to improve my reading speed!

Tasklist