"To a good programmer most jobs offerings are commodities, they are interchangeable and their offerings/rewards/challenges are very similar."
Consider the following two jobs:
- Job #1 expects me to work 80 hours a week in an open-plan office, building yet another web site for yet another startup, and pays a below-average salary.
- Job #2 expects me to work 40 hours a week in a private office, writing software that solves interesting problems, and pays twice as much.
I don't think that these jobs are at all interchangeable. If I currently have Job #2, it would be almost impossible for someone offering Job #1 to convince me to go work for them.
You get into a new programming job, and you know what you get from it. You hire a programmer and you don't know what you can get from him. I see only one side commoditized.
- A programmer with one year of experience writing CRUD applications is fairly easy to replace.
- A programmer with many years of experience designing and building large, scalable, maintainable, secure and reliable systems is much harder to replace.
- A programmer who knows your legacy code inside out is very hard to replace.
From an individual perspective we're not interchangeable the way two ears of corn or two apples might be. Even two programmers with identical technical skills are going to have different personalities and values that make them good or poor fits for different workplaces.
From a whole-market perspective, programmers are commodities to a large degree. There's a market with supply and demand. In the long term a junior programmer can be hired and shaped into the mid-level programmer a company needs, and so forth. Even apples have different varieties and some that are objectively (fewer worms) or subjectively (more tart or sweeter) better than others or better suited for different purposes.
Large companies are more likely to (and can generally afford to) treat programmers as commodities than small companies. Small companies tend to be more concerned about fit and someone being productive right off the bat. Larger companies can afford to invest more in training and have departments large enough that everyone has to interact anyway with people who might not be their first choice of collaborator, so "fit" matters less.
Not really. The existence of a large market doesn't suffice to classify something as a commodity. The acid test is this:
Two companies that each go out to the market and try to buy a thousand tons of wheat or a thousand barrels of crude oil, can reliably get the same result.
Two companies that each go out to the market and try to hire a thousand programmers, even for the same job descriptions and salaries, will get substantially different results, because they will have different errors and irrational biases in their hiring processes.
A thousand programmers? Yes, they will get around the same results. I've
seen various software created by such companies, and it all was of similar
quality.
Programmers? Yes.
Software Engineers? No.
People that can pass irrelevant whiteboard questions? No.
People that can actually create usable scalable software? Yes.
While advances in technology have reduced the barrier for many people to advance up the programmer path, the need for people that actually understand the problems has not diminished. Too many fresh grads and bootcamp kiddies are in the marketplace right now, this floods us with lots of inexperienced folks. Senior people, especially those with experience in scaling problems, are still very hard to find.
I don't think any professional class could be described as a commodity. In any job where people have to use their intelligence, experience and wits to effect an outcome, you will get widely differing results based on the individual.
But inasmuch as any professional could be described as a commodity, I think "programmer" is particularly fraught along two axes. The first axis is discipline: the differences between web, GUI, OS, embedded, distributed, and other programming disciplines is enormous. In order to be anything approaching a commodity you would have to choose such a narrow slice of expertise that there would hardly be enough experts in that particular thing to call it a commodity. The second axis is domain: the primary job of a commercial programmer is to translate some business logic into executable code. A good programmer with decent communication skills ought to be able to do a passable job at a new domain (assuming a competent domain expert to help work out the requirements!), but the value of really understanding the domain will magnify the value not just the mythical 5x or 10x, but potentially 100x or 1000x by identifying underlying truths and patterns that a "commodity" programmer would not necessarily discover until years of experience made them a domain expert.
> In order to be anything approaching a commodity you would have to choose such a narrow slice of expertise that there would hardly be enough experts in that particular thing to call it a commodity.
Like (backend|desktop)x(Java|.NET) programmers, iOS|Android programmers,
Reac^H^H^H^Hweb frontend programmers, or testers? Those are commodity. You can
have them dime a dozen (obviously, mediocre, not the best ones).
All the larger projects I've worked with were designed initially so you add/remove "programming resources" as needed.
"Simple" languages such as Java SE and JUnit were heavily used to enable that.
Over time some people still found ways to make themselves indispensible. When such people left, it was much harder to replace a single component that they maintained, but in the end it was possible either by refactoring, virtualizing or even copy-pasta.
For better or worse all successful software projects that I worked with did better where no one was irreplaceable.
No one truly is, but when they put themselves in that 'hero' position, it means they can't take the weekend off when it's deployment time or they need to deal with support cases personally and they burn out. And then it hurts the project more compared to an average contributor burning out.
To sum up - project managers will tend to organise software so it's more of a commodity, programmers will try to do the inverse.
Software being more of a commodity is usually better for the project and worse for the programmer and vice versa, at least in the short and medium term.
Nothing beats software craftsmanship combined with domain expertise. That is what makes the impossible possible. The developers that have these skills are not a commodity.
The scenario that you describe is not uncommon. It is a cultural problem, where there is no information sharing and developers "own" the code, even within a team.
On the other hand, sometimes, especially in larger organisations, there are too many C-level developers and that will burn out or drive away any A- and B-level developers.
The initial symptoms in the latter case is similar, with hero-developers and personal dependencies, but the difference is that the productivity slowly grinds to a halt as the code grows by copy-paste into a huge tangle of fragile code and bugs.
In these kind of organisations, programming is probably also treated as a commodity.
A highly skilled engineer working on compression, cryptography, data stores, operating systems, compilers, etc... (the building blocks for other systems), cannot be treated as commodities today.
Highly productive engineers with regular skills, might not be easily replaceable either, it might just not make financial sense for your company.
Engineers with regular skills and regular productivity can be replaced. But abusing this might have effects on the culture.
In today's environment - yes absolutely ! I mean they're treated like a commodity. Managers like to view them as pieces of in industrial machinery pipeline that can be plugged in interchangeably on any project. Sadly, this is the state of things.
In the eyes of non-technical management, programmers are just another fungible resource. Just like assembly line workers.
Those non-tech PHBs think that programming is just a variant on typing. If you aren't typing then you aren't producing. That's why designing, documenting, brainstorming, planning are discouraged.
So many programmers do feel like they are being treated as a commodity. Better to avoid working for such companies. Which might explain why programmers are attracted to working in startups, where they are treated as valuable contributors.
Not particularly more or less than other fields requiring similar creative adaptivity. If you ask a programmer to do commoditized tasks and punch the clock, then yes. If you ask them to engage themselves at their highest level of intensity and give them the environment and schedule to do so, then you get something very different per person, something potentially worthy and unique but hard to grade on the curve. And as we all know, organizations tend to need more of the former.
Would be more interesting to know what kind of programmers are not a commodity yet. Is there a specialization that can get you a job with the very first application or at least with the first few?
What does it take for someone's skills not to be a commodity?
I imagine sports starts, rock stars, famous lawyers, and so on, but they come and go. There are also people so specialised and knowledgeable; physicists, mathematicians, and other scientists, etc.
It's all a case of 'degree of commoditisation', I think, but one of the few non-commodity 'skills' is probably personal connections.
29 comments
[ 2.8 ms ] story [ 69.4 ms ] threadTo a good programmer most jobs offerings are commodities, they are interchangeable and their offerings/rewards/challenges are very similar.
Thus the developer you are interviewing is also interviewing you.
Consider the following two jobs:
- Job #1 expects me to work 80 hours a week in an open-plan office, building yet another web site for yet another startup, and pays a below-average salary.
- Job #2 expects me to work 40 hours a week in a private office, writing software that solves interesting problems, and pays twice as much.
I don't think that these jobs are at all interchangeable. If I currently have Job #2, it would be almost impossible for someone offering Job #1 to convince me to go work for them.
Programmers, as part of the working class, are an alienated workforce, something similar to "commodity". And so are all other classes.
[1]: https://en.wikipedia.org/wiki/Commodity#Types_of_commodity
- A programmer with one year of experience writing CRUD applications is fairly easy to replace.
- A programmer with many years of experience designing and building large, scalable, maintainable, secure and reliable systems is much harder to replace.
- A programmer who knows your legacy code inside out is very hard to replace.
From an individual perspective we're not interchangeable the way two ears of corn or two apples might be. Even two programmers with identical technical skills are going to have different personalities and values that make them good or poor fits for different workplaces.
From a whole-market perspective, programmers are commodities to a large degree. There's a market with supply and demand. In the long term a junior programmer can be hired and shaped into the mid-level programmer a company needs, and so forth. Even apples have different varieties and some that are objectively (fewer worms) or subjectively (more tart or sweeter) better than others or better suited for different purposes.
Large companies are more likely to (and can generally afford to) treat programmers as commodities than small companies. Small companies tend to be more concerned about fit and someone being productive right off the bat. Larger companies can afford to invest more in training and have departments large enough that everyone has to interact anyway with people who might not be their first choice of collaborator, so "fit" matters less.
Two companies that each go out to the market and try to buy a thousand tons of wheat or a thousand barrels of crude oil, can reliably get the same result.
Two companies that each go out to the market and try to hire a thousand programmers, even for the same job descriptions and salaries, will get substantially different results, because they will have different errors and irrational biases in their hiring processes.
While advances in technology have reduced the barrier for many people to advance up the programmer path, the need for people that actually understand the problems has not diminished. Too many fresh grads and bootcamp kiddies are in the marketplace right now, this floods us with lots of inexperienced folks. Senior people, especially those with experience in scaling problems, are still very hard to find.
But inasmuch as any professional could be described as a commodity, I think "programmer" is particularly fraught along two axes. The first axis is discipline: the differences between web, GUI, OS, embedded, distributed, and other programming disciplines is enormous. In order to be anything approaching a commodity you would have to choose such a narrow slice of expertise that there would hardly be enough experts in that particular thing to call it a commodity. The second axis is domain: the primary job of a commercial programmer is to translate some business logic into executable code. A good programmer with decent communication skills ought to be able to do a passable job at a new domain (assuming a competent domain expert to help work out the requirements!), but the value of really understanding the domain will magnify the value not just the mythical 5x or 10x, but potentially 100x or 1000x by identifying underlying truths and patterns that a "commodity" programmer would not necessarily discover until years of experience made them a domain expert.
Like (backend|desktop)x(Java|.NET) programmers, iOS|Android programmers, Reac^H^H^H^Hweb frontend programmers, or testers? Those are commodity. You can have them dime a dozen (obviously, mediocre, not the best ones).
If you're doing something mundane, easy, and well-defined, yes.
If you're doing something unique, difficult, or undetermined, no.
Nothing beats software craftsmanship combined with domain expertise. That is what makes the impossible possible. The developers that have these skills are not a commodity.
The scenario that you describe is not uncommon. It is a cultural problem, where there is no information sharing and developers "own" the code, even within a team.
On the other hand, sometimes, especially in larger organisations, there are too many C-level developers and that will burn out or drive away any A- and B-level developers.
The initial symptoms in the latter case is similar, with hero-developers and personal dependencies, but the difference is that the productivity slowly grinds to a halt as the code grows by copy-paste into a huge tangle of fragile code and bugs.
In these kind of organisations, programming is probably also treated as a commodity.
A highly skilled engineer working on compression, cryptography, data stores, operating systems, compilers, etc... (the building blocks for other systems), cannot be treated as commodities today.
Highly productive engineers with regular skills, might not be easily replaceable either, it might just not make financial sense for your company.
Engineers with regular skills and regular productivity can be replaced. But abusing this might have effects on the culture.
Those non-tech PHBs think that programming is just a variant on typing. If you aren't typing then you aren't producing. That's why designing, documenting, brainstorming, planning are discouraged.
So many programmers do feel like they are being treated as a commodity. Better to avoid working for such companies. Which might explain why programmers are attracted to working in startups, where they are treated as valuable contributors.
This means for instance inventing the concept of a "$LANG developer", when many good developers can adapt to any language.
I imagine sports starts, rock stars, famous lawyers, and so on, but they come and go. There are also people so specialised and knowledgeable; physicists, mathematicians, and other scientists, etc.
It's all a case of 'degree of commoditisation', I think, but one of the few non-commodity 'skills' is probably personal connections.