Betsy Haibel recently seeded a discussion on Twitter around the mindset of hiring junior developers onto a team. I responded thusly:
If your codebase is so complicated that a junior developer cannot deliver value in it…
…then your "senior" team isn't, in fact, at a senior execution level. https://t.co/mSMR7jsZOD
— Chelsea Troy (@HeyChelseaTroy) July 29, 2018
Yes, there are exceptions to this rule, particularly in low-level, performance-oriented libraries. But that’s not most dev teams, and it’s not the most common question I got.
I got one question from people about this over and over: what about technical debt?
I’m familiar with the phenomenon: not all of your code is up to the standards you’d like, but the team committed to completing a certain amount of work by a certain deadline, so certain things have just sort of stayed in a not-great state. Under your team’s ideal conditions, they’d look better. Absolutely. I get it.
Seniority, to me, denotes a couple of things. First, of course, it denotes having the technical chops to execute, and to execute well. What constitutes sufficient technical chops is ambiguous: let’s leave this aside for now.
Second, and just as importantly, seniority denotes having the knowledge, the skills, and the nerve to push for conditions in which the team can execute well.
To be senior, one must know how to say no.
No to the client: “I love that you’d like to add this whizbang thing to the app. Let’s put it on the road map! Your users, though, seem to use the app more when this other thing runs faster. So let’s focus on getting that running faster so you can get more usage, and then we’ll do whizbang.”
No to the business: “I understand that we need to get X out for customer Y. In them meantime I recommend alternative A for customer Y, because right now we need time to do B so that our team can do X faster in the long run.”
No to other developers: “This solution you’ve proposed looks interesting. That said, I think we should find an opportunity outside of this app right now. We have 8 people working in here, and I’d like them all to get a firm grasp on a more standard and well-documented architecture before they maintain a more experimental one.”
This definition isn’t chiefly about saying no to people below the senior developer. Most people can say no down the chain. A differentiator of seniority is the ability to say no up the chain: to clients, to bosses, to purse strings.
You’ll also notice that this definition of seniority excludes developers with lots of years’ experience who happen to be yes-people. I’m not saying that someone needs to be cantankerous to be senior. However, to be senior, a developer or a development team must possess the experience and the depth to do three things:
a) Recognize the consequences of what they are being asked to do.
b) Push back or identify an alternative when those consequences are too great.
c) Make informed decisions about how great is ‘too great.’
When we take this to its logical extreme, we arrive at an example from a superficially unrelated Twitter discussion last month, courtesy of Alice Goldfuss:
You must decide: I won't be an accomplice.
Not to @Microsoft if it works for ICE.
Not to @Google if it works for the IC.
Not to @Amazon if it works for the CIA.
Not to @Pivotal if it works for the Air Force.You're a tech worker. You have job security.
Use it.
— Chelsea Troy (@HeyChelseaTroy) June 20, 2018
You’ll note that what we’re talking about here also involves tech workers saying no. But here, we’re not talking about the consequences of technical debt on a team’s velocity. Now, we’re talking about a more extreme case of consequences: the consequences of a project’s existence on human suffering.
In these cases, the consequences of fulfilling the work order are so great that it’s incumbent on those with the requisite seniority not only to say no, but also when pushed, to draw a line and refuse to cross it.
That demonstrates just how critical it is for developers to consider the consequences of their work and use their experience to guide a project toward the highest benefit to consequence ratio—or, if the consequences are untenable, to stop the project. This is a much easier thing to practice when there is gray area: when no one is dying. When it’s just a matter of technical debt. A creative senior developer can propose an alternative path that gives their team time to do things right while still executing on the businesses’ promises.
It’s not an easy thing to do. It takes context from past experiences. It takes negotiation acumen. And I’ll be clear: sometimes it takes nerve. Sometimes it takes sacrifice.
But if we want to be at the top of our field, that’s the execution level that ‘top of field’ demands.
So let’s rise to the occasion.
If you liked this post, you might also like:
This series about how to socialize big changes at work
Technical Leadership: Fault vs. Responsibility
My reflections on Michael Lopp’s book about managing software engineers