service: contribution to the welfare of others
“Why are you adding 9 reviewers to this PR?”
“So it gets reviewed quickly.”
“Does that work? Let’s find out.”
An hour-long project ensued extracting data from our code review tool and correlating number of reviewers with time-to-review. Turned out the optimal number of reviewers to minimize time-to-review was between 1 and 2. Any more reviewers and delay grew substantially.
Hang on. More reviewers = more delay is an interesting factoid, but was that really the best use of 2 programmer-hours? Couldn’t we have done more for the company by working on a feature?
And yet. And yet. The best engineers I’ve worked with are most likely to take a detour to satisfy their curiosity. Either they are so good that wasting time doesn’t matter or their curiosity investments pay off in some way.
Payoff
When my theoretical understanding doesn’t match my observations I question my theory. What would have to be true for those 2 hours not to have been wasted, but instead to have been a valuable way for us to spend our time?
I see 4 sources of profit from curiosity:
- Energy
- Direct payoff
- Compounding
- Scale
Running on the feature hamster wheel is exhausting. Taking time to just engineer for engineering’s sake can bring me back to my regular work with renewed energy and purpose. I’m working on this feature because I choose to work on it, not because I have no other options. (Something something Little’s Law.)
Sometimes that “diversion” immediately ends up saving me time I was about to spend. 15 minutes finding a library that saves me 4 hours of coding is a good investment. (20 hours trying to use a library where I could have coded what I needed in 15 minutes is a story for a different essay.)
Improvements tend to compound. I don’t just save X days on my code reviews, I save Y% of waiting. My next idea might save Z%. You do the math. What percentage productivity do I need to gain per month to support how many hours of curiosity excursions?
Finally, improvements tend to spread. If we figure out to name 1 or 2 reviewers, we’ll likely tell other people and they’ll tell other people. The benefits of our 2 hours of investment are multiplied by the number of people who benefit.
Put these all together and you have a solid rational case for investing in your curiosity. Don’t worry about that, though. Curiosity isn’t a rational process. Invest because geeks gonna geek.
Too Much?
But hey Kent if everybody spends all of their time making everybody faster and nobody does any work, then no work gets done, right? Perhaps, or maybe we get so infinitely fast that a random quanta of real work builds the entire product in a nanosecond. Could happen. Not likely.
I’m not suggesting a curiosity-only work style (although that’s close to what I like). In general I start with the 80/15/5 Rule :
- 80% of time goes to work with a high probability of a reasonable payoff
- 15% of time goes to related work without expecting a payoff (refactoring, automation, alternate approaches)
- 5% of time goes to being a curious geek without any need to connect to payoff
The once-in-a-while payoffs from the 15% work gives you your next 80% task. The every-once-in-a-while payoff from 5% gives you your next career direction.
Language Warning
As I wrote this I found it hard to avoid judgmental and apologetic language. I kept wanting to say “indulge your curiosity”, like curiosity was some exotic flavor of ice cream that you ought to be ashamed of wanting. Beating myself up for indulging, in the sense of doing something for myself without thought of the cost to others, is a burden I’ve carried far too long. One of the beauties of geeking is that you can enjoy what you do while serving others. Watch your language as you talk about and think about what makes you a geek.
