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.
I first learned of the existence of a composer named Nikolai Medtner fourteen years ago, when overworked Amazon robots advised me, having peered deeply into my purchase history, that the missing je ne sais quoi in my Shopping Cart was a $60 box set of his complete piano sonatas. An ambitious suggestion, to be sure. I was nonplussed. But I became willing to plus it when I spotted that the pianist was Marc-André Hamelin, whose existence I had already discovered and come to appreciate. Anything Hamelin wanted to record, I wanted to hear.
Medtner’s music did not endear itself to me immediately. But when it did, it began slowly and persistently altering my life choices. I am now a person who eight and a half years ago moved to New York to find my way back to music. I am now a person who agreed to perform in recital for the first time since high school because it meant an opportunity to share my love of Medtner. I am now a person who composed a small piano piece (under the stylistic influence of Medtner) in order to prove to myself that I had what it takes to write worthwhile music. I am now a person who graduated college with a degree in music, who expects my musical training to continue, my musical life to flourish.
After all these years, I found myself last night in a room (Zankel Hall at Carnegie Hall) in which I saw for the first time my favorite pianist playing my favorite composer. The time and place of this culminating event were themselves, to me, poetic. And it’s fitting that Hamelin’s recital led to a new and timely insight about why Medtner’s music so resonates with me: his extraordinary musical intelligence never — unlike plenty of self-consciously clever composers — draws attention to itself. It is only, always, ever subservient to the physical and emotional experiences he designed coterminously for the pianist and the audience. I asked my sister afterward whether she’d noticed that an entire movement had been in an unusual time signature (15/8). She had not, because the movement had not been written in order to be noticed for its cleverness. Medtner himself would probably say it was written that way because that’s how it needed to sound, that he subjectively and with great care divined the natural shape it needed to have, then worked hard to preserve and develop it to its fullest expression.
With renewed vigor over the past year, I’ve been doing the same for myself, reevaluating the various ways in which I choose to spend my skill, ability, and effort, seeking to minimize waste and maximize returns. Several slow-building changes are close to fruition, one particularly so as I write these words. I’m excited to tell you more soon.
In classical sonata form, two themes of contrasting character battle for primacy, then reconcile. Medtner’s chief contribution to sonata form is his novel route to reconciliation: he brings his themes together in time. By arranging for us to hear them simultaneously, he shows his seemingly incongruous motifs to be thematically related and contrapuntally complementary. Each theme demonstrates its value in isolation and opposition, they take turns developing, and in the end it turns out that not only can they coexist, but also in so doing they deepen each other. These profound syntheses in Medtner’s sonatas, with their hard-earned simplicity, are for me some of the most intellectually and emotionally thrilling moments to be had in music and, as such, in all of existence.
Medtner’s been leading me by example all along. Fourteen years and it took me until last night to see it. To harmonize two themes, identify their common ancestry, then play them together. The denouement has to be earned; it’s hard. Until, at long last, it finally becomes simple.