Creator or maintainer?

Don't even get me started on the junior/senior nonsense

There are two essential types of developer, and no, they’re not “junior” and “senior”. Think creator and maintainer (or builder).

Forget junior/senior

The junior/senior divide is pure nonsense. What exactly do these terms mean? Who gets to decide who is junior and who is senior?

Most often, it comes down to experience. After a certain amount of time, developers just assume that they are now “senior”. But why should anyone care?

If you are doing great work as a “junior” developer, that’s good enough for me. And if you’ve spent the past five or ten years doing shit work, you can call yourself a “senior” dev all you like, I’m not interested.

Truthfully, I am pretty wary of people who call themselves senior devs. It’s kind of like calling yourself an expert. I am uncomfortable referring to myself as either.

In my experience, the more you learn about any topic, the more you realize how much you don’t know. The goal of “expertise” doesn’t get closer; it recedes further and further into the distance.

This is because your initial estimate of how much there was to learn was incredibly far off. It’s a bit like the ten-year-old who says, “We’re going to be best friends forever!” What that kid doesn’t realize is that at ten years old, forever is about two weeks.

So this is the paradox of learning: the more you know, the dumber you feel. If you’re doing it right that is.

It really depends on which way you’re facing. When I look back, I see how far I’ve come. I see that I know much more than I did, and I can see that I know more than many other people. But when I turn around and face forward, where I want to be has receded so far into the distance that I despair of ever really knowing anything.

It’s humbling, as it should be.

Most devs should look forward more often. Hell, most humans should.

Frankly, I think that calling anyone a junior or senior dev is downright insulting. How rude. Doesn’t it depend on the context? And does anyone really have an objective measure for it?

The truth is this: if I’m hiring you, then I don’t give a rat’s ass whether you consider yourself junior, senior, or utterly godlike. I have only two concerns:

1. Can you do the job?

2. Will you do the job?

Why is it always this?

How fast can you run?

In the world of programming and technology in general, things are changing so rapidly that if you’re not continually running, you’re falling behind.

So I’m supposed to be impressed that you’ve been doing the same thing over and over again for the past ten years? That makes you “senior” and worth more money?

Sorry. I’m not buying.

The nature of modern tech work is that it is always changing. I’m looking for people who are adaptable, diligent, motivated, and quick studies. Frankly, I find these qualities more often in so-called “junior” developers.

I’d much rather hire an inexperienced developer with aptitude and a good attitude and train that person than hire a “senior” developer on the basis of years of service.

Oh, but people will say, it’s about maturity!

If that’s the case, then why don’t we call them mature developers (and immature developers)? Or if it’s really about experience, then experienced developers and inexperienced developers?

And isn’t everyone inexperienced when they try something new?

But does maturity actually have anything to do with coding ability? For that matter, how important, really, is experience? Perhaps we’ve overvalued it a bit.

People also talk about the ability of “senior” developers to mentor or coach “junior” developers. But again, what does seniority have to do with mentoring or coaching talent? I’ve met plenty of “senior” developers who are worthless as coaches or mentors.

(The idea that anyone can coach or mentor or teach is insulting to those who do. Can just “anyone” with no training at all do your job?)

Why not call coaches and mentors what they are: coaches and mentors? Why not call things by their proper names?

There is, however, one distinction that is very important when hiring developers. It’s the difference between creators and maintainers.

Commodity vs. bespoke developers

My partner is continually warning me not to use this terminology as people will find it insulting.

Fuck ‘em. This distinction is the most important distinction regarding workers of any type, and it’s the one that makes the most sense from the perspective of the enterprise.

So let’s be frank about it.

The vast majority of developers and programmers (or of people in general)—the maintainers—are commodity developers (or programmers). And this is a good thing because the vast majority of development work is commodity work.

A commodity worker is an interchangeable worker who can crank out the same product or service day in and day out and be OK with it.

Hello! The world runs on commodity work. Look around!

For every bespoke worker we hire, we need ten, fifty, a hundred commodity workers.

Commodity devs don’t like change. Commodity devs have their favorite framework, library, etc. and they want to keep using it. Sure, they might embrace new features, especially if those features or improvements make their work easier, but they don’t want to start all over in an entirely new framework or paradigm.

Met any people like this? Of course you have. They are the vast majority.

They prefer to be given work for which they already know the solution, or for which there is a solution available. They are happy building the same sorts of things over and over again, perhaps with minor improvements or a new look and feel.

What they don’t want is a blank slate and no hint as to how to proceed. Vague acceptance criteria. They like things black and white.

For most commodity devs, coding is just something they do. They put in their hours and then they go home to their real lives, which rarely involve coding.

Bespoke means custom

Bespoke devs get bored easily. The last thing they want to do is the same thing they did yesterday. They are continually looking to the next thing. Often, they are terrible at finishing what they start, and don’t even think about asking them to maintain things.

To the bespoke dev, nothing is black and white. Everything is ambiguous. And this is what excites them: the freedom to explore. Vague or missing acceptance criteria? Who cares? They’ll make their own.

As I said above, most of the work to be done in this world is commodity work. Most dev teams are essentially factory assembly lines. The work comes in one end as a story, and goes out the other as a deployment, but the process is essentially the same, endlessly so.

This just kills bespoke devs.

Bespoke devs are most often the people who get so excited about some new idea that they can’t stop thinking about it. They’ll work nights and weekends for free just because the work is so fascinating to them. It’s not just a job; it’s an adventure.

Most hiring practices are supremely stupid

So why oh why do most job descriptions in job postings sound like what they desperately want is a bespoke dev when what they really want is a commodity dev.

I can only guess it’s the same reason that most people think that they’d love to be a celebrity (though they make no effort to become one): it looks better. More exciting.

“Commodity dev” seems shabby and ordinary. How much cooler to be a “bespoke dev”!

We’ve created this false hierarchy. If anything, commodity workers are far more valuable on the whole than bespoke workers, even if individual bespoke workers’ relative scarcity means that they get paid more.

But that hierarchy is nonsense. It takes all kinds to run a world, and no particular kind is better than any other. Is chocolate cake better than a salad? Try eating chocolate cake for every meal and get back to me on that.

Get the balance right

Balance is the key, and balance means aces in their places. One person can be an ace bespoke dev and another can be an ace commodity dev.

An ace is an ace is an ace.

Just as you can’t just exist with nothing but developers (though many startups have tried): you need designers, testers, coaches, UX engineers, marketers, maybe even a manager or two. None of these positions is any more important or carries any more weight or glory than any other.

All need to mesh together properly or the machine won’t work.

This unfair and absurd maldistribution of prestige causes no end of trouble on the job.

Case in point: I am definitely a bespoke developer. I never want to repeat myself.

This looks great on a CV. It plays well in interviews. With only two exceptions, I have been offered the job every time I’ve interviewed for one.

Imagine then my dismay when I discover that yet again I’ve been fooled. The work they have for me is common commodity work. The other members of my team love it. But I am desperately chafing at the bit.

On several occasions I’ve managed to maneuver myself into a greenfield project and have been able to write my own ticket. But more often than not, my true talents were utterly wasted. This happens so often that I sometimes despair at every truly doing what I love.

This situation is not just unfair to me: it is a terrible waste of the company’s money. They could have gotten a commodity dev for 30% less than they paid me, and that person would have been much happier and might even have stuck around.

Similarly, I have friends who are great commodity devs. Occasionally, they’ve talked themselves into bespoke roles. And they’ve always regretted it. That’s if they’re not simply freaking the fuck out.

Businesses—and workers—should become aware of which roles and which workers are commodity and which are bespoke. And then match the roles to the workers.

Not only will this ensure much higher efficiency, but the workers and management will be much happier as well.

And not that I’m trying to talk myself out of a job, but consider carefully just how many truly bespoke devs you need. It’s probably a lot fewer than you think.

Aces in their places. That’s the way to go.