📖 This Weeks Article

I saw a tweet thread a few weeks ago that made me think:

There’s a bit of a meme in some parts that there is value in saying, out loud, “I realize that I am surprised.” For similar reasons, I often subvocalize “I believe I now understand the type of situation the ‘trivial’ advice was preparing me for.” https://t.co/JzdYmSvJWH

— Patrick McKenzie (@patio11) April 9, 2019

For bonus points, you’ll realize that you develop new layers to the understanding of the same trivial bit of advice over the years. It stays the same but you discover the nuance, contours, reasons it is easy to discard in the moment, etc.

— Patrick McKenzie (@patio11) April 9, 2019

And then you repeat it to someone and they say “lol that is obvious” and you wonder if you know the advice well enough yet to correct them on how not obvious it is going to be for their next 10 years.

— Patrick McKenzie (@patio11) April 9, 2019

I realized that I’ve encountered plenty of pieces of wisdom in my software career that have this property; I see them as clear and obvious when put in the abstract, but only learn to actually apply them by repeatedly failing to do so. This is what people talk about when they say something is “hard earned experience” I guess.

Here are some examples from my career:

1. In the long run, rate of improvement (or regression) matters more than current level - This has applications in hiring, code quality, and finding/staying in a job. But it’s often easier to observe how good something is now than to see how its changing, and I often fail to properly estimate what a trend means for a situation 1-3 years down the road. It’s also easy to mis-apply this principle when you for get about the “long run” part. A new employee with tons of potential won’t help you when you need an experienced hand now and fixing technical debt can easily cost you your ability to hit a quarterly objective. Knowing how to balance these long and short term goals is something I still struggle with all the time.
2. Rewriting from scratch is (almost) never worth it - Joel Spoelsky wrote about this way back in 2000 and I remember reading that article nearly a decade ago and nodding along. I seem to have infinite capacity to convince myself that my current situation fits in those parentheses though. In my career this has mostly been a problem where I’m able to more accurately forecast the pain that would ensue from fixing what exists (because that code exists and is easier to work with), while I appear to systematically underestimate the pain of building the new thing (because the internet told me it would be great, and the code doesn’t exist for me to nitpick yet).
3. Always consider multiple options - Pretty much any decision (technical or otherwise) benefits from having multiple contenders. This seems obvious. But I have often let myself fall into situations where I’m choosing between just 2 options, or really just choosing whether or not to do 1 thing. This has applications in technology choices, job choices, responding to another person’s provocations, and more. I intuitively know that more options are good, and I constantly miss opportunities to add options.

So how do we improve on these situations where we fail to apply obvious wisdom? I’ve been learning a few things lately.

1. Always review what you’ve done on a regular basis - Do weekly reviews about how your week went. Do quarterly reviews with yourself about how your job is going. When you make big decisions, make sure to find a time to check back in later and evaluate how it went. We make better decisions when we take the time to measure our results
2. Note Missed Opportunities - When you do those reviews, make sure to pay attention to when you missed an opportunity to apply something you knew. Sometimes we make mistakes because we just didn’t know something. It’s more common though that we didn’t properly apply our own principles and knowledge.
3. Identify Cues - Identify the thing that you know you’re going to have to handle different next time. Maybe you say “if I’m looking for a job, I should consider at least 4 or 5 different companies and not focus in on just one”, or if I’m asked to fix a legacy codebase, I will spend at least 3 months trying to improve it before considering a re-write,and I’ll look for real world comparisons to base a rewrite estimate on”. Whatever it is for you, when you can identify situations where a specific action should take place, it can help you be better the next time instead of repeating the same old mistakes.

🔗 New Site Content

April was a crazy month, so nothing new for now. Hoping to get back in the swing of things this month!

😎 Cool Stuff

• Why software projects take longer than you think – a statistical model | Erik Bernhardsson - I’ve been dealing with the estimation and planning side of software development a lot the last few months, and this was fascinating

• Application State Management with React |Kent Dodds - I have a WIP draft about my own experiences with pure React state management. Until that is complete, I’ll settle for linking to this, which is a good read on the subject.