People who haven't been programmers have no way of knowing the extent to which programming consists of making decisions. It is, let me tell you, a very large extent. Many managers expect a few large, visible decisions when we're discussing “requirements” or “architecture” or “design”, but can't imagine the sheer number of decisions made when we're doing “implementation”. (These managers either haven't encountered Agile practices or have chosen not to learn from their encounters.) Everything strange and wonderful about the art of software development, the sometimes counterintuitive stuff we do in order to do it well, stems from three premises:
- Software is made by humans for humans.
- A person developing software makes hundreds, maybe thousands of choices each day.
- For any given choice, we won't always know its future price, but we'll always have to pay it.
In 2009, a Fortune 100 company hired me as a security engineer to develop a custom infrastructure product. I hadn't programmed professionally for longer than the four years I'd just spent earning a degree — not in computer science, but in music. Did I have what it took to do the job? I remember how unsure I felt. But a friend who vouched for me arranged an interview, it went well, and they made me an offer I was pleased to not refuse. A year later, I was managing the product and its team.
With a nod to Kent Beck, I'm not a great programmer, I'm just a good programmer with great judgment. My superpower is decision-making.
A developer's choices are most often reified in code. A manager's choices are most often reified in the product and in the team that produces it. For several years, as product manager and team lead, I did work that took full advantage of the quality of my decisions. It was an extraordinarily difficult environment in which to do the job well, and I made damn sure to do it well. But when I learned last year that my work was not widely or consistently appreciated, the struggle suddenly felt much less rewarding. It turns out that people who haven't been software development managers have no way of knowing the extent to which managing software development teams consists of making decisions. It's the entire first paragraph all over again, a level higher on the org chart.
I willingly accepted a reduced role with the promise that the arrangement was temporary. I knew I wouldn't be making the big decisions anymore; this was a welcome relief from apparently thankless work. I didn't know my informed professional opinions would not be considered when making the decisions, or that the decisions would be made poorly, or that I'd still be around long enough for that to hurt me. I certainly didn't know, when I'd found a role elsewhere in which I'd get to deliver far more value far more visibly — a role in which I'd spend some percentage of my time coaching development teams — that my temporary arrangement, which had become untenable, wasn't so temporary after all.
We don't always know the price, but we always have to pay it. I was paying.
If making decisions is my superpower, then I had a decision to make. It stemmed from three premises:
- I was no longer being used to make decisions.
- I was no longer being used to support the people who were making decisions.
- I was no longer able to switch to a role where I'd make decisions or help others make them.
After checking my premises, I handed in a brief letter with my conclusion. A few weeks later, it was my last day. Yesterday.
Today's my fourth anniversary with Bekki. As of a few months ago, we finally live in the same place. It's a nice place. I walk to the grocery, the butcher, the pharmacy, even the dentist, and a handful of good coffeeshops. Our house is full of comforts, two of which are covered in fur of their own devising. I'm writing these words sitting in the yard because spring arrived yesterday and we have a yard.
So I've left my job. What next? If I could, I'd want to slow down for a while and just enjoy what I have. And I can. It's the easiest decision in the world.