July 30, 2016

Sharpening the wrong axe

Hello developer friend,

I hope you have a wonderful weekend. Before I start mine, I wanted to share a quick question that I think is worth ruminating on...

What are you doing right now in your work and studies that is going too well?

In other words, what are you investing too much time in just because you enjoy improving it?

For me, in recent months... I had been focusing on a non-technical skill: I wanted to get better at using Twitter. That may sound a bit frivolous, but given that I'm a writer and educator... Twitter is how I get to know new people and what they are interested in, and how I test my ideas and materials. For many it's just a source of distraction or entertainment, for me... it's a tool.

I'll spare you the pointless details, but the short story is that every goal I had set out for improving my use of Twitter, I had hit. They're not measured in things like tens of thousands of new followers... but they are measured in likes, retweets, and replies to my materials... because that's a sign that I was reaching people who found my ideas interesting.

And that's good stuff, in moderation. If you like what I write, it's in part because I spend a huge portion of my time listening to and observing what practicing developers are up to... what they're struggling with. And then I test the hell out of my own ideas to see what sticks.

But Twitter itself doesn't reward you for listening... it rewards you for speaking. And it's natural that if that's the reward mechanism... it's easy to let your goals drift and without even noticing it, you're suddenly sharpening the wrong axe. Or rather, that the particular tool you're focusing on mastering is no longer the one that deserves the most attention -- but you keep doing it because it feels good.

For a more technical back story, a similar thing had happened to me a few years ago when I had gone deep into studying object-oriented design and the theory behind it.

I had dug into original source materials for things like the SOLID principles (and by that I mean Parnas, Liskov, etc. not just Bob Martin's summaries) ... I'd read Noble's classic "Arguments and Results" paper and built practical examples around it, I'd gone deep on Law of Demeter and found an amazing interpretation  from David Smyth that basically lay out the fundamental rules behind modern asynchronous object-oriented programming.

It was a pure joy... because I was digging in areas that while not altogether unfamiliar to the world -- were lesser known, and it was easy to come out of the academic mines with some fascinating ideas that I could share with practicing developers and show how some of these old ideas had evolved over time, and how they might fit into modern work if you had re-examined them from the bottom up.

From there, I started wandering into more abstract realms. Stuff like Sakkinen's Disciplined Inheritance paper from 1988 which really hammers home the Inheritance vs. Composition argument in painfully precise terms... and manages to explain why module mixins provide the worst of both worlds before Ruby even existed yet. Incredibly enjoyable material... for me.

The problem was that I had left many my readers in the dust. When I was talking about SOLID and showing practical examples to complement the abstract ones that are often used... it was helping people see how the ideas might be relevant to their day-to-day work, especially as it relates to writing testable code. When I was explaining why Demeter has little to do with "counting dots" and more to do with untangling the rat's nest of wires that connect objects together... people could relate to that.

When I started saying "Hey look, I implemented something like module mixins, but they are plain old Ruby objects, and they communicate solely through composition and dynamic message passing" -- well... a few folks with beards longer than mine (or the gender-neutral equivalent) bowed their heads in quiet contemplation. Everyone else, I imagine, started looking elsewhere for learning material until I found the plot again: the stuff that was relevant and interesting to a wide array of practicing developers.

In moderation, this sort of laser-focused drilling down into the substrate is good for you and for the people you serve. In excess, it leaves you feeling disconnected from your true purpose... unless your goal is to become a world renowned expert in SomeSpecificThing.

It seems like this is an occupational hazard for many of us, so I'll ask again:

What are you doing right now in your work and studies that is going too well? 

In other words, what are you investing too much time in just because you enjoy improving it?

To find the answers... think about your external goals. The people you're serving... the products you're building... the major story arc you have in mind for the next five to ten years of your life.

The odds are great that there's at least one axe you're sharping because of a runaway positive feedback loop (or in some cases, a negative reinforcement loop... but that's a more complex topic) ... and that it's actually getting in the way of your larger goals.

If you put that tool down and take a look out into the wilderness and remember what is you're trying to do... it'll be easier to go back to the shed and figure out what has gotten a bit dull, or what has been buried way in some dark corner that may be worth bringing back out into the light.

You'll probably encounter a bit of internal resistance if you take this exercise to heart -- I'm asking you to trade something you like doing that you're getting good at, for something that may have been collecting dust or rust. But if you follow through, you'll almost certainly learn something valuable about yourself, and improve your ability to serve others in the process.

I'm happy to talk more about this any time, so just send a reply if you have thoughts to share. But even if you just mull this question over on your own... I hope it helps.