I have to say I was surprised by the many thoughtful replies I received to my last email... I thought of it more like notes scribbled in the margins rather than a proper essay, but it generated some very interesting feedback.
The basic story I was trying to tell in Sharpening the Wrong Axe is that sometimes we have a tendency to fixate on developing skills just because doing so makes us feel good; that there is a strong feedback loop that rewards us for focusing on one particular area of our skill set rather than looking at the bigger picture.
I wanted to call out the dangerous nature of this way of working, because it tends to lead towards "compulsive skill development" rather than "intentional skill development" -- something I fear is deeply embedded in the current culture surrounding software development.
Based on the feedback I received, I think I could have done better at pointing out that it's definitely the case that "following your interests" is both natural and healthy in moderation. The key is to remember that developing any particular skill is a self-reinforcing feedback loop, and in order to prevent yourself from developing extreme tunnel vision... it's necessary to have another feedback mechanism that acts as a sort of counterweight and keeps things in a state of balance.
One way to do this is to check in with yourself on a regular interval, once a week or once a month, and think "What did I do this week? How does it fit into my long-term goals?" -- Simply asking this question is a good enough reality check, and will help you catch yourself when start heading too far down the rabbit hole.
But there is also another way, and I didn't really think about it until I read some of your emails. And this way is certainly more fun: You allow yourself to dive into the deep end of something you're interested in, with the full intention of letting yourself get carried away with things, and with no expectation of creating something of value.
When you take this approach, there is no illusion that whatever you are practicing or studying is "productive work" ... there's full awareness that you're engaging in a form of play. And from there, you can treat this sort of activity as you would any other source of entertainment or hobby.
Although you can't force it, a pleasant side effect of working this way is that while you are playing, you may end up developing useful things by pure chance. And if you're having fun, you may also manage to work through difficult or poorly understood terrain without ever really considering it "work" -- and that may leave you in place where you can help others who were driven to that space by necessity rather than interest.
In my last email, I had talked about a multi-month foray into deep object-oriented design research that had initially been motivated by teaching practicing developers some useful concepts to apply in their daily work... but had somehow spiraled into me running over decades-old academic materials with a fine-tooth comb, much of it more closely resembling abstract math than anything related to real world software development.
I had labeled this as a mistake, and I think it was: I had a journal to run and that journal was for folks who had practical jobs. I wanted to give them a taste of deeper theoretical ideas, but not ask them to drink an ocean of abstraction alongside me.
But then after hearing a few of you say "but there's value in doing things just for the fun of it," and "there's value in knowing deep theory because it helps shape how you look at the world" -- I have to say, I agree with both of those things. So the problem wasn't the deep dive, it was that I dove deep without remembering why I was doing it.
As a counter example, another article I wrote was one that I had no intention to research or produce in the first place. I had been reading Gödel, Escher, Bach at the time... which is an amazingly enjoyable mind trap for people who like that sort of thing. I then started to think on how the concepts in that book might relate to software development... especially as it relates to the connections between expressiveness and simplicity.
What came out of this was an article with a pretty opaque title that I assumed few people would bother to read: The anatomy of information in software systems. It was a complete joy to write and so it basically came for free, but I didn't expect it to be useful or interesting to those who don't study theory in their spare time.
Oddly enough though, this article is one that I share more often now than many of my other, more vocationally-focused work. Here's why: It explains a simple idea that is fundamental to what we do as software developers, but is often missed when we're focusing on the job to be done.
The basic premise of the article is this: The more simple something is to process using a computer, the harder it is to understand... the more expressive and 'natural' something is, the harder it is to implement with computers. This shows up in the difference between machine language and Python code, as well as the difference between a binary file format and JSON data. It shows up in choices like when to use full-stack web frameworks vs. minimal tooling that handles little more than HTTP requests.
This one article is one of my favorite pieces of material I've ever produced, and it came at me totally by accident. I don't think that's entirely coincidental.
So hopefully with this follow-up, you can see that I definitely don't advocate a working style of "all work and no play" or "serve everyone except yourself" -- I just think we need to build some habits that prevent us from buying into the fallacy that 'do what you love' is a singular path towards success and happiness.
As long as you're able to see work as work and play as play... the two can overlap greatly as long as they don't conflict with one another.
So... serve others well AND have fun. Just don't assume that those two things always need to happen at the same time. :-)