The Know-not-all Developer

In the Hacker News discussion of a recent post by a programmer who had publicly quit Google, I ran across a comment that I wished I could have sent back in time to the younger, angrier version of myself who was constantly frustrated with the goings-on at his early developer jobs.

People were debating how to win the “political game” that seems to determine one’s success in a larger organization. In discussions like this, I’ve noticed (and participated in) a common cynicism about “politics” amongst developers—that one’s technical merit is chronically underappreciated and that you must scheme your way to the top.

Hacker News comment

It took me years to come to the difficult realization that maybe the people who were placed in positions of authority were there because they had a better grasp of the needs of the business by which we were employed. Maybe they had strived to understand a broader context for their work and how it impacts the profitability of the company.

Are there boneheads in management? Of course! Just like there are at any level of an organization. But I personally found it better for my mental health and career satisfaction to develop some humility about my relationship to the broader organization.

My advice for a younger me would be this: Listen to the folks in your management chain that you have regular exposure to and try to develop a sense for the kinds of problems they tend to think are important, and then focus yourself on those areas. Also, you don’t know everything.

The Professional Buzzkill

I’ve joked occasionally that every software project needs a dedicated “Buzzkill”—someone who balances out the pie-in-the-sky thinking that often hurts these projects.

I do believe that optimism is one of the greatest dangers to most software projects—people being unrealistic about the complexity of things and how long things take to do well. But no project ever gets off the ground without optimism, right? Would any non-technical person ever sponsor a software project if they really took in the full complexity and likelihood of failure that their project (or any project) faces?

Broken toy

So let’s accept the necessity of the optimist. Instead of damning optimism, let’s promote context. Maybe every team needs the “Contextualizer”—the person who places new ideas in context and then encourages discussion in that light.

One of the great triumphs of Scrum is that the product backlog acts as a context for features to land in. Force the product owner to think about all the other stuff they’ve asked the team to do, every single time they have a new request.

I pledge not to shoot your idea down, but I will give it some context!

Ownership

One of my favorite Twitter accounts in the software industry is Esther Derby’s. I’m constantly nodding along. This one got me thinking about the concept of “ownership” on software teams.

Esther tweet

It’s a common refrain from software project managers that they want developers to take ownership of the features they build, as in, accept accountability for what they’ve built and its quality—to care about it.

As someone whose career responsibilities have occasionally involved diving into another team’s codebase to figure out what went wrong, I’m guilty of thinking to myself, “How could these devs have shipped this crap? Don’t they care about the quality of their work?

Later on, I get a glimpse into the management of the team, and witness how the developers are pressured constantly to deliver more features, forget the bugs, and “commit” to delivering requirements they had no hand in writing and no say in the timetable for delivery.

It is damn near impossible to get developers to really take ownership of their code when all the circumstances of the project are implying: “Shit it and ship it!

Development teams must have veto power over scope and estimates, which I’m sure scares a large contingent of managers out there, but without that there is no hope for “ownership.”