Should programmers be more specialized?

05 Jun, 2026

Many programming jobs exist in teams where roles are only lightly differentiated. Everyone goes on-call; everyone is expected to know the whole stack; everyone does in fact work across the stack; everyone helps a little in interviewing; and so on.

To be clear: plenty of jobs are not like this. Higher-level engineers often take on work specific to them. R&D work, and other work involving deep domain knowledge, is often more specialized. Some companies simply work in other ways. But lots and lots of jobs use the team-of-undifferentiated-programmers model, where to the extent you can specialize, it's mostly a matter of informal bartering.

There are strong forces pushing in this direction:

1. There can only exist so many job titles, and in a lot of places your official work has to have a one-to-one-ish relationship with your job title.
2. Making all your programmers hyper-generalists (at least officially) gives a team at least one kind of resilience against turnover and re-orgs. Management is quite happy to trade off some absolute competence for this kind of reslience.
3. Encapsulation is hard, and many codebases are entangled in a way that makes specialization almost incoherent. (You cannot specialize in a part of a thing that does not have proper parts.)
4. Engineers are promised equal(-ish) distribution of on-call duty, and there's no mechanism for renegotiating that. This is a sort of special case of (1), and the more general point is that organizations sometimes just have no way to permit specialization.
5. In some cases, a given person's doing too much of the interviewing or of irreplaceable technical work would create not just resilience risk but primary-agent risk. (They would have too much control of huge flows of value.)
6. Managers usually have an easier time evaluating programmers on the hyper-generalist model. They are also often more competent in "developing talent" on the hyper-generalist model than more specialized models. It's relatively easy to, e.g., see that someone is incompetent in React and make legible gestures to help them learn it. It's a lot harder to see that someone is great at the front end and find ways to make them even better.

Despite all that, I've long thought that programmers, or at least programmers at large and medium-sized companies, were under-specialized. Here's one of my favorite blog posts ever, where Dan Luu argues for a certain kind of specialization. Some other notes:

1. There are, again, informal remedies. Teammates can coordinate in picking up work. They can also trade work "under the table" after it's been assigned. This might sound sketchy, but some things simply must be done under the table.
2. Many big companies have official policies or mantra about nurturing strengths. These are not always observed.
3. Some of this simply reflects the broader culture: tech companies are disproportionately based in America and populated by people immersed in educational and parenting cultures that often emphasize a kind of demonstrable well-roundedness.¹
4. My history is very relevant here: in several jobs, back in the day, I was demonstrably very good at interviewing and much, much, much worse at, say, on-call.²

If you are a programmer in this kind of environment, please understand that the company's model of achievement might not be the best model for you to have for yourself. This is even more true because AI is changing both optimal patterns of competence and team structures, but that's another post.

#counterexamples to Betteridge's law of headlines #generative AI #sociology of software #software