The Senior Software Engineer

October 17, 2015 • on perspective

I’ve been building websites professionally for about 10 years now, and for most of my career have focused on getting better at writing clear, valuable, maintainable code. In many of my roles, I’ve been the sole developer on a project, so that was the best I could do. But since joining Lessonly and working on a growing team, I’ve come to realize that there’s only so much a single developer can do, and that by empowering my team, I can produce better, more lasting work than I could just by putting my nose to the grindstone.

It was with this on my mind that I discovered David Bryant Copeland’s The Senior Software Engineer: 11 Practices of an Effective Technical Leader (thanks to @_swanson’s review of it). Copeland’s book is about being a technical leader, exactly the role I find myself aspiring to. What sets a technical leader apart from a novice engineer are their priorities. While the novice cares about building the best possible product—an important goal, to be sure—the technical leader takes a slightly wider view, focusing on the health of the team producing that product, and of the wider business context that allows that team to exist in the first place. In short, the novice focuses on building an artifact, while a technical leader focuses on producing value.

Now, that doesn’t mean technical leaders don’t write code. Copeland dismisses the myth that being a technical leader means trading the command line for an Excel spreadsheet and becomming—gasp!—a manager. On the contrary, technical leaders tend to get the most interesting and impactful problems to solve—but it’s true that being a technical leader means you’re no longer primarily concerned with writing code, but with delivering value to your team and company. In Copeland’s words:

This isn’t a book about being a middle manager of a software team. It’s a book about all the skills you never realized you needed to cultivate when writing code.

“Never realized you needed” is key here. Being a technical leader isn’t a new job for a software engineer that we can either take or leave, it’s the same job once you realize it’s what you should have been focusing on all along. For me, it’s personal. I’ve come to realize that merely writing code—no matter how good the code—isn’t enough to produce great work as part of a team. What is needed is what Copeland covers in the rest of the book.

The Practices of an Effective Technical Leader

When listed out, these practices are somewhat obvious. The real value is in Copeland’s treatment of what they mean and how to enact them (so read the book!) But for future reference, they are:

  1. Focus on delivering results.
  2. Fix bugs efficiently and cleanly.
  3. Add features with ease.
  4. Deal with technical debt and slop.
  5. Play well with others.
  6. Make technical decisions.
  7. Bootstrap a greenfield system.
  8. Learn to write.
  9. Interview potential co-workers.
  10. Be responsive and productive.
  11. Lead a team.

A few of these came as surprises to me, especially “8. Learn to write.” But upon reflection, in my capacity as a software engineer I produce far more English—in emails, documentation, and discussions—than Ruby or Javascript, so of course it makes sense to improve that skill.

Dealing With Reality

A major theme running through the book is that the technical leader knows how to deal with the reality outside the VM: with constraints, co-workers, and managers. Some key advice I’ll take away:

  • Keep promises to a minimum, but deliver everything you promise.
  • Provide realistic status updates, not after-the-fact excuses.
  • Being an expert means pushing back when you’re being asked to solve the wrong problem.
  • Treat requests to “work harder” as non-sequiters. You and your team are working as hard as possible. If you’re going to miss a deadline, that’s a fact. Promising to “try” to hit it anyway is a recipe for burnout and future disappointment.
  • On that note, don’t commit to hard deadlines—they ignore the vicissitudes of software development and what it means to do things that have never been done before. Very few deadlines must be met (and if they truly are hard, you should set a soft deadline weeks or months in advance). Instead, be clear to those asking for estimates that you can provide a rough one, and will follow up with regular, honest progress updates. Transparency trumps surprise disappointments every time.

Dealing With the Outside World

Another of Copeland’s points I appreciated was the importance of interactions with those outside the engineering team. I especially like the unofficial Service-Level Agreement he keeps with regard to email:

Given this, here’s my SLA for emails:

  • All email read once per hour during normal business hours.
  • Urgent emails (by my assessment of urgency) get a response within an hour.
  • All emails requiring a response get a response by the next business day.
  • If I cannot provide the requested information in one business day, I’ll respond with an estimate of when I can.
  • All information requested is provided within five business days.

This may seem like a lot of work, but it ultimately saves time. When someone emails with an request for info in the morning, by getting back to them within the hour that you’ll provide the info by end-of-day, it keeps them from potentially stopping by your desk that afternoon to “check in” on the status of their request, costing you time chatting and regaining focus after the interruption.

In sum, The Senior Software Engineer was one of those books I encountered at exactly the right time. At a time when the way I think about my job was changing anyway, I’m confident that Copeland’s book has pushed me in the right direction. If you find yourself starting to wonder whether there’s more to building software than writing code, you owe it to yourself and your team to read this.