Not blue-collar because we wear blue collars or perform physical labour, but because programmers are not professionals - we're not architects, we're bricklayers.
In the conventional business mindset programmers just implement a plan devised by someone else. Consequently we are fungible (easily replaced by cheaper alternatives), and a cost rather than an asset.
That's like arguing that surgeons are performing a blue collar job when they're given a diagnosis and test results from another physician. In theory they're performing the same repetitive motion, just like programmers are in theory creating an implementation to solve a given problem.
However, there are provably good and bad surgeons and provably good and bad programmers. The reality is that you're making a lot of decisions when you cut out a tumor or implement a spec, decisions which take skill and practice to get right. I certainly wouldn't want my surgeon to be a cheaper alternative, nor would I want a programmer working for me to be the same. Not all programmers or surgeons are equivalent, since there is a large element of skill and practice.
Surgeons are briefed on the problem, the diagnosis, the patient's medical history, given all the information they need to know about the project. They are then locked in a small room with all the tools and assistants they need, and given complete and total authority and autonomy over the process and results. Because of that, surgeons are some of the most respected people in their environments.
Programmers are dripfed information on a "need-to-know" basis by managers who have no clue about the process involved (and therefore with no clue about what information is needed). They are then placed in an open area, interrupted regularly, have to justify the cost of any tools, are never given assistants, and have exactly zero authority or autonomy over the process or results. Because of that, programmers are some of the least respected people in their environment.
But we do have a few things in common: if the patient dies it's the surgeon's fault, and if the project fails then it's the programmer's fault.
This stark comparison is exactly why we're blue-collar workers not professionals.
I see your point. I'd argue that programmers who are treated that way have bad managers, though, rather than it being a function of programming as a profession. I've never dealt with a company that hasn't given me some autonomy, though, so I can't really comment on that perspective.
A company can give programmers autonomy, or it can give them bits of information and treat them poorly. It could also do this for its sales team, its lawyers, or its marketing department. This strikes me more as a problem with the company rather than a problem with the nature of programming.
Yeah, there are business out there who treat programmers "properly", but they're unfortunately the exception rather than the rule, and that's not going to change any time soon.
I push back when the business hands me implementation in requirements (e.g. "Make me a button that rings a bell 10 seconds after I click it" versus "I need to know when a query finishes; it usually takes 10 seconds." which leads to "holy CRAP, that query takes 10 seconds?! Lets solve that!").
The first few times I did it, it caused a bit of an uproar, but very quickly they came to realize that they got better quality software when the person making it understood why he was making it.
Likewise, if you're in an environment where you're an eyes-down bricklayer (and unhappy about it)... Maybe it's time to put your big-boy pants on.
I agree, and I've done the same, but I do find it ridiculous that we have to be the ones to fight the battle.
This is all known stuff, there's endless research and case studies showing that providing creative programmers with autonomy and authority over their environment creates massively better software results.
But the illusion of control is hard for some people to let go, I guess.
>Programmers are dripfed information on a "need-to-know" basis by managers who have no clue about the process involved (and therefore with no clue about what information is needed). They are then placed in an open area, interrupted regularly, have to justify the cost of any tools, are never given assistants, and have exactly zero authority or autonomy over the process or results. Because of that, programmers are some of the least respected people in their environment.
That doesn't describe my job very well. (OK, I don't have an assistant, but I don't think I need one.)
Or are you deliberately making a contrast between "coders" and "software engineers"?
>They are then locked in a small room with all the tools and assistants they need, and given complete and total authority and autonomy over the process and results.
A surgeon of that level would be more analogous to a very senior programmer with management responsibilities. Said surgeon only got to that point after years of working very long hours with little autonomy.
And surgeons only get that autonomy for a fraction of their day, every doctor I've ever met complains about hospital and insurance company bureaucracies.
If you want to compare a bunch of 20-40 year old programmers sitting in an office plan at facebook to doctors, you'd do better comparing them to ER residents who definitely don't have the kind of autonomy you're talking about.
There are also plenty of "professional" programmers working as consultants.
But from my understanding of the health industry, the consultants are absolutely the top of the food chain despite their whinges about management. This is not true of even highly-paid consultant programmers (and highly-paid tech consultants are almost never allowed to waste their time actually programming).
>and highly-paid tech consultants are almost never allowed to waste their time actually programming
There are plenty of niche programming consultants that are highly paid to actually program--firmware reverse engineering, and cryptographic security specialists are 2 of them.
There was a whole thread a few years ago where tptacek argued that $400 an hour is reasonable for certain specialty programmers, which is more than all but the highest paid surgeons make.
He gave 4 example categories: "expert developers with domain expertise in finance" also "cryptographic security specialists", "hardware reverse engineers", and "high-end SEO"
true, good point, but I still think (from my vast stock of unresearched and ill-informed opinions) that the combination of authority and respect is massively more common in surgeons than it is in programmers.
And if it isn't actually, then it certainly is in the public consciousness.
I'm much more familiar with "Here is this problem space that there's great rewards in addressing successfully, we don't actually know how to address that problem space, we can just see that it needs to be addressed because of (business indicators a-z). Can you help us address this problem space?" And then figuring out how to do that + implementing it (if it's actually possible at all).
Is this not programming?
Programmers are dripfed information on a "need-to-know" basis by managers who have no clue about the process involved (and therefore with no clue about what information is needed). They are then placed in an open area, interrupted regularly, have to justify the cost of any tools, are never given assistants, and have exactly zero authority or autonomy over the process or results. Because of that, programmers are some of the least respected people in their environment.
That sounds horrifying, how on earth are you ever expected to accomplish anything worthwhile in such an environment, and in the present ultra-competitive market, why would anyone tolerate being treated that way?
> we're not architects, we're bricklayers. In the conventional business mindset programmers just implement a plan devised by someone else.
I think this analogy is wrong. Like architects, we can and must help requesters understand what's possible. "Architect, please design me a house supported by tiny pillars." "Programmer, please solve the traveling salesman problem for me."
> Consequently we are fungible (easily replaced by cheaper alternatives), and a cost rather than an asset.
The more central to a business their code is, the more this mindset will hurt them.
That is how we are often treated. That is also (one of many reasons) why large projects constantly fail (or else go so massively over budget that you should still call it a failure).
In the conventional business mindset programmers just implement a plan devised by someone else. Consequently we are fungible (easily replaced by cheaper alternatives), and a cost rather than an asset.