Any job that requires problem analysis and coordination skills has the same effect. As a software developer (well they call me architect these days), I'm more or less sure there's nothing special about our profession.
But in the soft sciences, like economics, politics, social topics, history, etc., deluded thinking is commonplace even among those highly educated in the field.
What I find curious, though, is STEM PhD's apply rigorous logic to determine if something is true or false. But the same people, when thinking about non-STEM topics, throw logic, reason, and analysis out the window and just go with their gut feel.
A commonplace example is STEM people know very well that (A implies B) is not the same thing as (not A implies not B). They don't make that mistake in their field. But they apply that logical fallacy everywhere else.
You absolutely can. The problem is in the ambiguity around the work "working". Take for example the case of a person/team shipping a poor quality implementation which is initially celebrated and rewarded (because no one realizes it's a poor quality implementation) only to fall over in production and cause large problems/disruption for the team/product/business.
This is not an uncommon scenario in software development and I would argue is a case of people pretending (or thinking) something is working when it isn't.
We (engineers, scientists, whatever) exploit ambiguity as a work avoidance strategy all the time, but for many fields exploiting ambiguity is the work. IMO it's like the difference between a think tank abusing statistical bias versus using a firehose of falsehood to push their agenda. Ambiguity is just a tool in the former case that occasionally causes problems, but it is the life blood of the latter tactic and creates a much more destructive atmosphere for critical thinking and societal trust in general.
Like what? Marketing, politics maybe, what else?
It's the "how many people could leave this company before anyone noticed?" game.
Software organizations have such good margins on capital they can afford to hire extraordinary quantities of dead weight before they become unsustainable. I've been at organizations where probably 75% of the software engineering org could be fired with no impact on creativity, growth, or maintenance efficacy.
It's actually the efficiency of software that allows ineffective people to stick around without being noticed. Contra this article, I've noticed whole sections of the software industry deliberately float around organizations at scale. They're typically the people with a boatload of "ex-Cool Company" in their LinkedIn handles.
And yet engineers are doing it all the time. Think of Dieselgate or the Boeing 737 MAX.
One might object that the discovery of Dieselgate or the flaws of the Boeing 737 MAX is prove that the engineers responsible for it were not able to pretend. But then the sentence is analytically true for every other profession too: the discovery of a flaw falsifies claims of flawlessness.
I think that some types of flaws make themselves apparent comparatively easy in (software) engineering. But this might even fire back if it makes an engineer too uncritical so that she put too much trust into the result of her work.
Besides, I do not think that we have good metrics to compare distant professions in terms of their ability to deliver high-quality results. It is perhaps somewhat justified to compare neigboring professions, such as a biologist arguing with a physician or a historian with a political scientist in specific cases. But beyond that, I can really only imagine an exchange of prejudices.
These two are closer to fraud than engineering mishaps.
The big issue with the 737 MAX wasn't the MCAS, it was that management and marketing hid its existence from buyers and regulators. So when it started misbehaving the pilots were not aware this thing was turned on and was steering the plane.
The MCAS did what it was built to do (make the plane behave like a traditional 737).
Why did management hide this crucial information to buyers and government regulators? Because had they not, it's unclear regulators would have certified the plane to begin with since nobody could, in good faith, claim it was eligible to the same type certificate as its predecessors.
In the case of the 737 MAX, I doubt that only the manangement is to be blamed. This sounds like the adage that success has many fathers, but failure none. The practicality of certain design for its intented purposes in its actual use cases is at the heart of engineering. I don't think that a top-down view is sufficient where it is "manangement" that is setting specific goals and "engineering" is only obligated to observe these specific goals instead of also considering the broader context.
Back to the original debate: Even if "the MACS did what it was built to do (make the plane behave like a traditional 737)" the whole design did not what it was supposed to do. Admittedly it did fly, but not safely. And the whole process of quality control, which should ensure that it was safe, did fail as well.
This is why I think a claim like "engineering ... cannot pretend something is working when it isn't" is quite naïve. Why do we need all those complex regulations about quality control, when it is so obvious that something is working or not?
But they were aware of how to deal with runaway stabilizer trim, which is supposed to be a memory item (i.e. don't need to consult the checklist). After the first crash, Boeing sent an Emergency Airworthiness Directive to all MAX pilots with instructions on how to regain control. The EA crew did not follow those directions.
The prevalence of Agile and Scrum in our industry suggests we're exactly as prone to magical thinking as other groups are. Maybe more so than some, in fact, because many people in the IT field seem to believe that studying some mathematics and logic immunizes them against unscientific thought.
A few years ago I saw a fascinating documentary about orangutans in Borneo. Local women used to come down to the river to wash clothes, and there were a few orangutans who saw them beating the cloth against rocks. So one or two of the more enterprising orangutans started copying them, picking up the clothes and beating them against rocks. Clearly the apes thought, if these ape-like things are doing it, there must be a good reason, and we should do it too.
In my three decades in the IT industry I see the same thing over and over. Groups and teams do things because that's what Google does, that's what Netflix does, that's what Microsoft does, that's what this blog post by this person says. No-one asks, what's the real reason that those companies do those things, and are we sure it even applies to us. So our industry is full of companies whose teams just cargo-cult whatever it is that other companies are doing, endlessly beating the wet clothes against the rocks believing that one day they'll be rewarded for it.
Examples:
- Fixing a marriage
- The Vietnam war
https://en.m.wikipedia.org/wiki/McNamara_fallacy
This makes avoiding self-deception much harder in those domains.
How much is it the other way round?
>you cannot pretend something is working when it isn't.
If you can verify any hypothesis with an experiment, you don't need logic. You can go with your gut feeling, and iterate until it works. Because the compiler and the program itself are bound by logic, software developers don't need to cultivate the same strict logical thinking that other disciplines need.
You can fake "working" software, that's why so much of it is low quality because to outsiders it is magic and to us insiders...apparently it is magic that only we can perform and those other people can't. We still get paid.
The weird thing is working across multiple fields, the social scientists were the most honest with what they didn't know and made no pretensions about it. But they won't write an essay bout it and post it to HN. The pretensions in this essay would have shot it down in their heads.
I got another comment flagged for "snarky", but I know you are smart enough to see the inherent disrespect to other fields (and perhaps ignorance of them), in your post.
There are undoubtedly good people in those fields. But when a distinguished professor of economics tells me personally that he believes in communism (yes that happened), I lose respect for him, not necessarily the field.
This is actually less true of software than of other engineering fields. An airplane can only weigh so much, and it needs an engine that's at least so powerful, else it will never leave the ground. With computing, the constraint ceiling is much higher, and it's still getting higher year over year albeit more slowly than it used to. Consequently, you can brute-force a terrible abstraction into kind of, sort of working and it will be acceptable for most use cases, only to break spectacularly when subjected to loads beyond a particular scale.
Hm, not sure about that. People talk about making MVPs by letting the user think there's a product there when in reality the solution is done manually, or there to just collect email addresses. See Wizard of Oz, concierge, etc MVPs as examples [0]. There are also no-code tools one can employ to make things seem like they work, again at least to the end user.
[0] https://openclassrooms.com/en/courses/4544561-learn-about-le...
Maybe not, but you can change your definition of what working is.
Tell that to my boss, who wants to ship every prototype and POC to our customers and call it a day.
At any given time, there might be piles of complexity that nobody has ingested at the moment, and would take time to dig through to get caught up.
A builder can look outside his window to get a crude idea of how far along the project is.
In software, it's often really, really hard to tell.