Illustration by Jason Crane.
My new Yak Shaving Expert t-shirt is fitting, and not only because it’s the right size. For instance, today I wanted to start backing up my email, so I found offlineimap to my taste, so I went to pkgsrc to install it and saw that we’re a couple releases behind, so I updated the package. Sometimes it turns out that in order to do what you want, it’s necessary that you first go shave a yak. Maybe I’ll get to try backing up my email tomorrow.
In software development, it’s pleasing when any desired change proves easy to make. When a change proves prohibitively difficult, we have to decide what to do: either to stop wanting it, or to want it anyway. In neither case will we be able to know the full cost of our decision. But our choice can and should be informed by our need for predictable cost of delivery in the future and our willingness to delay gratification in the present. It’s sort of like insurance. If over our product’s lifetime we need to minimize the frequency with which we have to stop everything and shave an entire yak, then we know the discipline required.
I’ve felt mildly and persistently overwhelmed since the great server crash of late 2008. First I had time to deal with the fallout, but no money; then money, but no time. Not having all my personal data organized and available has meant that for any given task, I’ve learned to assume I can’t just go and do it; instead, I’ll have to first figure out what I need, then go digging to find it all. Then, and only then, can I hope to complete the task. So the act of getting started has been harder than usual, the list of tasks has grown large, the cycle has been self-sustaining, and the effect of five years of this drip-drip-drip on my cognitive capacity has been noticeable, at least to me.
My personal yaks have finally come home to roost. (Yes, they’ve evolved the ability to roost.) I have money, time, grand ideas, and some clippers. Where to start? A few weeks ago I guessed I’d want to answer that only after refining my enormous backlog a bit. Now I think whichever item I feel like doing next is what I’ll do next. Why try to impose an ordering, when I know full well it’s yaks all the way down?
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.
There are many ways to develop software. The method I’m most familiar with is to have people do it. You know, humans.
Dogs would likely find it gratifying to deliver working, valuable software to their humans.
Since software is made by humans for humans, one bottleneck is the state of our knowledge. You want something. I want to help you get it. But what is it, exactly? Why do we think so? How can we be sure? Let’s say we feel pretty sure. How much can you afford to spend to get it? How much might it cost you to have me do it? Do we still think it’s what you want? Let’s say yes. Am I en route to what you want? Why do we think so? How can we be sure? Am I going to complete it under your budget and time constraints? Why do we think so? How can we be sure? Let’s say I do. Is it still what you want? Let’s say yes. Have I done what you needed? Why do we think so? How can we be sure? And so on.
Every time we find ourselves surprised, disappointed, confused, or stuck, we’re being bottlenecked by our knowledge. We thought we knew, but it turns out we didn’t. To exacerbate this, we can make a habit of pretending we always know and we’re always sure. To ameliorate it, we can make a habit of checking what we currently believe and why. If we haven’t checked whether it’s true recently, it might not be true now.
Since software is made by humans for humans, another bottleneck is the state of our trust. If you don’t feel comfortable sharing your needs with me, I won’t be able to understand them very well. If I don’t understand your needs, you won’t be interested in hearing my ideas for meeting them. If you’re not interested in my ideas, I won’t be able to help you very well. If I don’t do you much good, you won’t feel comfortable sharing your needs with me. And so on.
Of course, there’s also a positive feedback cycle. If last time we both got what we wanted, this time we’re more likely to give each other what we need. When we work together, my first meta-task is to convey to you that it’ll be worth your while to trust me. Once you begin to believe it, my next meta-task is to quickly give you ways to validate your belief. If we haven’t checked whether it’s true recently, it might not be true now.
Since software is made by humans for humans, another bottleneck is the state of our empathy. If I don’t care about you, you’ll feel it, you won’t grant me your trust, and the knowledge we’ll need to acquire together simply won’t be available to us. If you don’t care about me, likewise. When we work together, my zeroth meta-task is to convey to you that I care.
This one’s easy for me. As a solitary kid, I got into programming for the thrill of solving my own problems (which I still get a kick out of, believe you me). As a full-sized social animal, I’ve built a career in software development for the thrill of helping you solve yours. What matters to you matters to me. When we work together, you’ll be able to tell right away.
Oh, right: since software is made of bits on computers, another bottleneck might be the state of our technical skill. Technical skill can help us acquire knowledge and earn trust. It cannot help us empathize with each other. If and only if we’re doing wonderfully at that, technical skill might become our bottleneck. In which case we’d be perfectly able to overcome it, together.
It was quick because Bekki, having met him more than once, already knew he was for us. She’d been eyeing candidates for adoption online and occasionally visiting them, and she had gone to meet Rascal the day before Thanksgiving. By then nearly all my belongings had migrated to our house in Bloomington, but I was still living out my last few weeks in Washington Heights. Until the end of January we knew we’d be at home together for one week, in Germany together for three, and apart for another three while I was away for a conference and for work. Sweet as my trusted source assured me Rascal was, we knew we couldn’t take him. Not quite yet.
When someone else did, we figured that was that. But here he was again. So it came to pass that we were able to go together to see Baloo (as he was now called) and to learn as much of his story as the shelter could tell us. He had been brought in by a family who purchased him on Craigslist but didn’t have time; adopted by a young couple who returned him after three weeks due to a family member’s allergies; adopted by another young couple who returned him after three days due to his nonstop vomiting; and here we were, another young couple. We liked him and we thought we’d like to adopt him, but we didn’t want to continue the pattern, so we went home and slept on it. The following day we knew not only that his troubles endeared him to us more, but also that we were ready for whatever they might be, whatever he might need us to do.
His first days with us were quiet and loving, when they weren’t vomitorious. Some combination of politeness and hunger impelled him to try to clean up his own messes, which we quickly put a stop to. Dozens of carpet-bombings and a couple medical inspections later, we’re slowly getting the hang of managing his stomach, he’s getting more comfortable with us and otherwise, and we’re starting to discover hints of a boisterous personality. Bekki got home from driving me to the airport to find that the dog had amused himself in our several hours’ absence by reorganizing the house a bit. And that’s how we realized that was the longest we’ve left him home alone. Is this 10-year-old fellow’s apparent gentility with his feline and human housemates a façade? I’m away from the home office till mid-March, so we’re about to find out.
His new name was Bekki’s idea: he responded well to “Rascal”, he’s husky-derived, and one of his new owners is a programmer. Haskell. It’s even more fitting because we lazily evaluated his name just in time to tell the vet. Now I have two Haskells to get to know. For the moment, I’m focusing on the 65-pound wannabe lapdog who wishes I’d walk faster, then cuddle more.
For the last two and a half years, ever since Bekki started her Ph.D. program, I’ve been splitting my time between New York and Indiana. At first, as part of a larger group expected to work together from the New York office on Tuesdays and Thursdays, I could at best fly out on a Thursday evening, work remotely Friday and Monday, and fly back Monday night. After a year of that, I transferred (along with my product and team) to another group in order for us to be better managed, which had the pleasant side effect of enabling me to stay and work from Bloomington for stints of a week or longer.
Another side effect of a steady diet of lighter travel and enlightened management was that by the time 2013 rolled around, I realized I was mentally ready to prioritize my health. If you were to guess that getting healthier might be accompanied by other improvements, you’d be right. I celebrated my 35th birthday yesterday, so I’m of a mind to reflect on some ways in which 2013 went well for me and how I intend to build on each in 2014.
I hoped — but initially didn’t quite believe — that I was prioritizing my health. I treated my weight loss as a project to be managed. Other than assigning arbitrarily fixed scope (“lose 45 pounds”) and fixed deadline (“in a year”), I managed it with an Agile-influenced self-designed process that helped me make the daily choices I wanted to make, radiated current status visually at home and at work, prompted me to periodically review progress, and incremented itself one simplest-change-that-could-possibly-help(-and-stick) at a time.
As is typical when the stated goal and the stated deadline are both “fixed”, one must be prepared in the end to adjust the goal. I didn’t lose 45 pounds. But because the parameters were of my own invention, I don’t feel disappointed in the least about the project. Rather the contrary: I’m nearly 30 pounds lighter than a year ago, I feel and look more like myself, and I’ve managed to convince myself that I really have been prioritizing my health.
For 2014, now that I trust what I’ve been doing, I’m willing to make more significant lifestyle changes.
I restored this site to operation and wrote 22 articles. You won’t be surprised that my two most frequent topics were (1) health and (2) Test-Driven Development.
I was surprised to have written so much. In 2014 I’ll make a point of delivering no fewer than 26 articles, no less often than every two weeks.
One of the TDD-related articles was from my talk at pkgsrcCon in Berlin. As a longtime member of
pkgsrc-pmc, the steering committee for the pkgsrc package management system, I have long felt the need to demonstrate technical leadership by improving the architecture of the system. I plan to attend this summer’s pkgsrcCon in London; I hope by then I’ve done more than merely maintain my packages, and can show some consequential improvements to pkgsrc internals.
I was elected to the Board of the NetBSD Foundation. In 2013, I learned what the board does and how it does it, and represented NetBSD and pkgsrc in two interviews. If health was last year’s top priority for me, NetBSD is this year’s.
I’ve been serving for several years on the Board of the Philolexian Foundation, which supports the operation and strivings of the Philolexian Society of Columbia University. This year I ascended to President. I also took inspiration from my frequent proximity to Indiana University to write and perform a reasonably bad poem at Philo’s annual Alfred Joyce Kilmer Memorial Bad Poetry Contest.
Two of the articles featuring Test-Driven Development were about ikiwiki, web content management software I’ve used to solve publishing problems for NetBSD and Philolexian. Before 2014 is out, I’ll finally be publishing this site with ikiwiki too.
Another of the Test-Driven Development articles reflected my deepened understanding that TDD is a technique for learning rapidly what’s going on in code, even (maybe especially) when one doesn’t know the language well. I figured that out because a workshop at CodeMash 2013 pleasantly forced me to. CodeMash was the first software development conference I ever attended and the first of three in 2013. The third was Software Craftsmanship North America, where I experienced my first Code Retreat and the long-absent, much-needed feeling of being among peers whose software values matched mine.
In 2014 I intend to spend much less time with people who don’t care about what I care about, and much more time with people who do.
The other conference I attended last year (as a newly minted Certified Scrum Professional) was Scrum Gathering Las Vegas. Thirty of my most valuable 2013 minutes were spent at the SGLAS Coaches’ Clinic talking with Roger Brown. Considering coaching as a career, I wanted a coach to help me understand more precisely what that looks like and whether I might be able to do it well. Roger’s answers to my questions about the coaching life fit my mental model — and when I answered his questions, his reactions indicated that I’d be smart to try it.
Another thirty of my most valuable 2013 minutes were spent at the New York office talking with a senior manager. I shared with him my desire to coach, the potential benefits to the company, and my need to validate the idea. He knew of a team looking for some coaching and sent me to Montreal to coach them.
For a total of five days surrounding Thanksgiving with the family in New York, I worked on-site with the team as a whole and individually, developers and managers, hands-on and nonstop, and it was exhausting and exhilarating. My brief time with that team validated for me that I was already pretty decent at coaching, that I could be great at it, that it might let me make a small dent in the universe, and that I loved it.
In 2013 I determined that I needed to feel greater appreciation for my work, that I was willing to identify and deliver more valuable work in order to get it, and that helping teams make better decisions about software development would be highly valuable.
In 2014 I expect my responsibilities to change from managing a single product to coaching multiple teams, and I expect my efforts to produce observably meaningful results for all involved.
A year ago the fact of living in New York wasn’t the bottleneck to improving my health. A few minimal effective changes later, I feel otherwise. I’m doing well; to do better, I need to be able to safely ride my bike on pleasant paths without shlepping it up and down three flights of stairs, to randomly drop by a tennis or basketball court and probably get to play, to comfortably house some sort of dog (preferably large) who requires lots of walks, to relax in a quiet home, and to travel less.
My team isn’t — indeed, most of the company’s development teams aren’t — in New York. So continuing to live there wouldn’t win me much effectiveness or save me much travel. If I were to split my time such that my periodic trips were to the New York office, the proportions would be quantitatively different, but the arrangement wouldn’t be qualitatively different.
My life isn’t in New York. To a midwesterner by temperament, it never could have been. I’m grateful for eight and a half formative years there, and I’ll be happy to see it every time I visit, but New York was only ever a place I tolerated in order to get what I needed.
Everything I need now is in Bloomington.
When I think about how I spent my 35th solar orbit, I feel anything is possible in the next one. I feel powerful. More than ever I know who I am, who’s for me, and who I’m for.