Please let’s not reinvent concepts or words. We are not the chosen ones nor do we live in a field that is different from any other.
Many other fields require the same mental capacities we employ: from doctors to school teachers all the way to even accountants. They are literally doing the same stuff we are doing: grabbing stuff that was already built by others, thinking about it, discussing it, having meetings, etc.
I hate it when a community becomes so biased towards their own field in a way that creates a bubble and interferes with actual innovation. This has sadly been the case for the software industry.
In some sense all white collar jobs are sitting at a keyboard typing, but I think we can usefully go a bit beyond that and look at the interiority of the people performing the labour - and also the management and economic structures surrounding it.
Programming is really unusual in that it doesn't have the "profession" structure of doctors, lawyers etc - nor does it have the classic Taylorist assembly line. What does characterise it is traditional companies trying to structure it that way and being absolutely obliterated in the market by "outsider" companies doing things with smaller, less hierarchical teams.
At one edge it resembles (and competes for hiring with) the "quant" side of financial trading. Also a focus-heavy industry.
> Many other fields require the same mental capacities we employ: from doctors to school teachers all the way to even accountants. They are literally doing the same stuff we are doing: grabbing stuff that was already built by others, thinking about it, discussing it, having meetings, etc.
Here I disagree. Doctors? It seems true.. But school teachers and accountants? Nope..
I don't really think these fields compare, unless your 'software' is limited to doing some outsourced CRUD work..
However much people tout against it, I believe software engineering is closer to any other engineering (say Mechanical) than it is to other fields. Our task is solving problems in efficient ways, and optimizing things for one thing or another. Except these days unfortunately the bar seems very low..
> Our task is solving problems in efficient ways, and optimizing things for one thing or another
Sounds literally like every other white collar job, or in fact ideally any job ever. I agree with OP, we devs are sometimes a bit too full of ourselves, when in fact mostly we have simply just another engineering work. I used to think that way too when I was young, naive and inexperienced.
My wife is a doctor, and when I compare, we have it too easy considering our compensation. When was the last time your bug killed a human being / destroyed their health for good? When was the last time when you got dragged into court for a bug you submitted 3 years ago and jail with permanent loss of license was a real option? Getting 25$ for 12-hour weekend nightshift?
Instead we have remote work, digital nomads and people humble-bragging about 400k FAANG compensations being at the low end and barely livable.
* By some accounts Toyota's electronic throttle control system (ETCS) had bugs that could cause sudden unintended acceleration
* The Boeing 787 Dreamliner experienced an integer overflow bug which could shut down all electrical generators if the aircraft was on for more than 248 days
* In early 2019, the transportation-rental firm Lime discovered a firmware bug with its electric scooters that can cause them to brake unexpectedly very hard, which may hurl and injure riders.[6
* A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of beta radiation
Yeah and that's what, 0.1% of all software devs globally that can potentially do physical harm? Most of us just hurl data between places and worst damage is financial. You can't even compare the scales.
If you're a construction engineer, any serious flaw in any building you design can kill, sometimes hundreds.
How many engineers of those few cases you mention went into jail and were forbidden to work in software industry forever?
Not at all. Having jumped from the medical field to software, I can tell you that medicine is its own uniquely hellish world full of nasty tensions nobody talks about in honest terms and wicked problems that don't really have solutions...
But I do think that in a way the problems of the two industries can be similar: they both fail miserably at properly separating the work and responsibilities into different professions that make sense. Like, in medicine, taking MDs alone, you should have at least these separate professions inside each speciality:
- Patient Relations people - from PatR-agent to PatR-manager
- Diagnosticians - *partially* replaceable by AI in the future
- Patient Treatment Managers
- Patient Team Manager
- Clinical Research Project Operator
- Clinical Research Project Manager
- Clinical Research Project Architect
- ...
You should have different schools/universities/majors preparing different kinds of people for these separate kinds of jobs!!! And after this, actual partition into medical specialties might actually be more flexible, some MDs actually have multiple specialties and that can work, but cumulating all the functions above into what one person leads to extreme overload, it's like the software equivalent of having a full-stack-web-plus-security-plus-embeded-software-engineer that also has to take on project manager responsibilities! Overload + partitioning across the wrong dimension ("organ-system-based"-specialities that makes no sense in modern medicine since we know all diseases manifest across all body systems) + the separate socio-economical hellscape.
Software industry has the excuse of being really really young, medicine on the other hand had decades (or centuries...) to figure things out, but it got it all wrong because optimizing for profit and personal-ego-development trumped everything...
Anyway, you're not right, you're more than right :) Things are so good in software that we forget how totally f'ed up the rest of the world is...
Teachers absolutely do take pre-existing knowledge of pedagogy, apply it, discuss it, modify it. There's tonnes of publications on the topic; groups form to reflect and promote ideas at every level from the single school to government.
> Many other fields require the same mental capacities we employ: from doctors to school teachers all the way to even accountants. They are literally doing the same stuff we are doing: grabbing stuff that was already built by others, thinking about it, discussing it, having meetings, etc.
They are doing some of the same things, not all of the same things. The ways they are different is obviously important.
Software development requires a level of precision found only in other engineering disciplines, because computers are pedantic and unforgiving. Biological systems, like those dealt with by doctors and teachers, are forgiving and robust. For instance, most medical interventions at the family doctor level are actually unnecessary [1].
That said, software development is far from the hardest field.
- teachers : if you have let's say 30 students, you need one teacher, in you have 300 you probably need 10 teachers. I don't know how can you one person deal with 300 students giving them the required attention. Since you have the school program you can start paralyzing the tasks.
- doctors : If you have 10 sick peoples... 1 doctor, with 100 you probably need 10 doctors. A doctor need time with a single patient to study the case.
There is probably plenty of good examples, but not that ones.
About building softwares, even if you pick the right guys and split the task properly (which requires peoples, time and a high level of understanding) and let peoples work on their own, you lead to inconsistency. Splitting an existing task to add new developers and save time requires redesign and headaches to avoid incompatibilities, probably breaking new things or requiring some rework in the work done by the others.
> Unfortunately people get bored, especially in creative profession, when the product is mature, the job becomes more boring.
This is backwards, IME. I want to maintain a system and make it run great. Management is always pushing for some damn new thing, and features and velocity over stability and quality.
Consider whether this is a trait of developers in general, or your own personality. I have colleagues who push ever forward with no regard to maintenance, and others who prefer the satisfaction of refactoring a working system into working even better.
I find that both types can be very productive software developers, given the right team and leaders.
It is poor style to capitalize FOCUS throughout the article.
For example, when a mathematician starts reading a paper that uses too many acronyms, they generally freak out. It's a strong signal that they've wandered into the wrong part of town. While there is brilliant work done in applied domains, one rarely finds it in acronym-heavy papers.
After a lifetime of reinforcement with this filter in place, it's very hard to read FOCUS as anything but an acronym. That's not what you intend, so look into styling your html with bold or italic emphasis?
(I was at a faculty meeting that was spending an unreasonable amount of time debating an acronym for our salary committee, something that would reinforce the message that there are other aspects of our compensation. My contribution: "I love how Brits use short words for things. As a member of the most symbolic department, I'd like to speak in favor of an acronym-free workplace." I got the Provost evil eye.)
The way you define focus sounds a bit strange to me. Focus is indeed needed for programming - that's why you need to be in the zone when coding - but it's the focus we refer to usually.
As we live in a frantic attention economy now focus is indeed very valuable as dealing with the ongoing bombardment with distractions is truly expensive.
Just think about all those remote workers getting reminded all the time that some new Slack, Flock, Skype, WhatsApp, Facebook, e-mail messages arrived.
All the companies above make money by hijacking our attention and forcing us to focus on the work we do for them for free instead. Imagine us focusing at the code instead.
Maintaining focus is actually labor.
Adding more devs might not help with a late project, but it does help with building bigger systems. So, I disagree, software is extremely labor intensive work.
> Software is not labor-intensive. Not many people are necessary in order to produce good software.
Not many people are needed to produce 500gr of good rice. And lots of people are needed to produce something like all the software Google or MS maintains.
The specialty of software is the low cost of marginal products. This is the new thing here, not labour intensiveness.
> On the contrary, Brooks’s law on software project management states that “adding manpower to a late software project makes it later”.
This has more to do with communication, collaboration and slowness of getting up to speed when joining a software project.
Attention is not easily managed labor. This becomes extra complex in cultural environments - industrial/work - which do not strive to promote commonality of attention among the group members, such that it fosters communication, and ultimately .. production.
This is clearly visible in the HR requirements practices. Companies which have a confidence in their ability to manage the on-boarders' attention, tend to interview for communication rather than experience - those who haven't made the investment in attention-management techniques, such as great training, technical on-boarding routine, etc., tend to focus on experience over sociability.
>Brookes' law
I've found, with 30 years of experience in software development from both the trenches to management and back, that there is an aspect of this law which goes ignored - "Adding manpower to a late software project makes it later, but adding documentation to a late software project makes it easier to add manpower.."
The better you document things so that strangers can understand them, the easier time you have on boarding strangers and getting them up to speed. This is a cultural mechanic, and alas is usually in the wrong persons' hands - i.e. HR, upper managements, etc. Technical people need to get this right for the true fire to burn ..
Interesting, I would reverse those terms entirely: culture is explicit (it has to be continually re-told in order to persist) whereas structure is a consequence of the natural form of life, imposed upon the laws of the physical universe.
Indeed interesting. Someone told me long time ago: if you dont provide structure at the job, people will find a shared method of working but it will be culture then (harder to change, mostly implicit).
This stayed with me. I think I recently read a similar statement again in some text.
From what I understand, labor intensive means work that involves some sort of "physical" labor. How would you classify focus as a labor intensive work? An average individual can't maintain focus all the time. But an average individual can do physical work for long hours. The way our body works is different to way our mind works. Are you tired after hard physical labor? You just need some rest and good food. You can do physical labor even if your mind is not in the right place. Many workers in factories are so used to doing the same repetitive stuff (like packaging items in an assembly line or chopping vegetables for a high-paced restaurant) that they do it subconsciously. All they need to do is to get into a "zone".
But same can't be said about focus intensive work. You can do physical work without thinking. But can you code without thinking? There is nothing repetitive about coding. And if anything is repetitive we end up automating it.
This argument is built out of rough numbers that came to hand using quick searches. It's not particularly accurate but gives an idea of the orders of magnitude involved.
Google has approximately 100,000 employees.
Not nearly all of them are software engineers but, for the sake of this argument and to be generous, let's assume that they are.
Let's also be generous in assuming that only people in the US, and nowhere else, use it. That's about 330,000,000 users.
OTOH, the US army has approximately 1,300,000 service members and 800,000 reserves as well as approximately 330,000 civilians.
So (ignoring physical suitability) the potential labour power of the US army is approximately an order of magnitude greater than Google. Moreover, "labour intensive" usually means "people who go out to do physical things": the work scales with the number of hands you can bring to bear. Combat aside, military forces are often involved in work that requires lots of people to do things in "meatspace":
* Rescue operations
* Medical assistance in impoverished areas
* Food & humanitarian relief
* Security at embassies and other locations
* Policing in volatile areas
* Natural disaster relief
* Law enforcement
* Piracy and drug interdiction
When the software engineers aren't busy thinking about software, they carry cups of tea between the kitchen and their desks (well I suppose they're probably thinking about programming then as well ;-)).
Finally, Google currently has a big operation, but like many startups, a pretty big product (the original search engine) was built by ~20 people. With those people they crawled almost every site on the web. If you wanted to go and read every document in every filing cabinet and index that then you'd need a labour intensive force bigger than the US army.
Many other fields require the same mental capacities we employ: from doctors to school teachers all the way to even accountants. They are literally doing the same stuff we are doing: grabbing stuff that was already built by others, thinking about it, discussing it, having meetings, etc.
I hate it when a community becomes so biased towards their own field in a way that creates a bubble and interferes with actual innovation. This has sadly been the case for the software industry.