When I began working in software, I tied my sense of accomplishment to the stuff I was able to do.
I used to get a huge feeling of satisfaction from a weekend spent working on a clever hack. I would spend serious effort making something run twice as quickly, even when there wasn’t a problem with how quickly it was running in the first place. Meeting those types of challenges was my primary motivator.
Now, in a leadership position on a talented team, I find myself just as much in the business of avoiding writing code as I am in writing it.
A clever hack used to be improving an algorithm, and now it’s avoiding writing an algorithm. The clever achievements I’m most satisfied by now are improvements to processes or documentation that make things better without having to open vim.
When I reflect on something I’m proud of, it’s usually finding a way to deliver the same value with none of the code. To me, that’s the definition of a win.
Every line of code we don’t write is dollars we didn’t spend, and time on the calendar we get back for free. The opportunity cost of writing one piece of software is not being able to write another piece of software. We’ve all got to be judicious with resources, but this is about more than that. It’s not just efficiency, or focus, it’s about getting to the heart of what I’m here to do.
My job isn’t to write code. It never was. It has always been to make people’s lives better and more productive. I used to focus on one tool to do that. Now, it’s just one tool in a versatile toolbox. It’s not even the second or third option I reach for.
This philosophy forces me to get to the bottom of what someone is wanting to achieve, rather than assuming software is the best way to solve the problem. It makes me think an octave higher. To me, this process offers priceless insight.
Assume you’re incapable of writing code. How would you solve this problem?
- What if you had to solve it with money?
- What if you had to solve it with a paper-based process?
- How would you hire temps to do it?
- Could you solve it with hardware?
Usually, by the end of this, I know a ton more than I did before, and I’ve found out how many of my initial assumptions were stupid. It gets me closer to adding value directly, instead of shoehorning my preferred solution onto a problem.