6 ms·

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 o

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.

WalterBright 5y ago
The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. If your airplane design doesn't fly, pretending it did doesn't work. 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.
- stronglikedan 5y ago
  > you cannot pretend something is working when it isn't. Tell that to my boss, who wants to ship every prototype and POC to our customers and call it a day.
  - WalterBright 5y ago
    You certainly can pretend your car has 10 gallons of gas in it when it has only 1, but you're still going to run out of gas after that gallon is burned. I suppose one could conclude that pretending can work if the consequences are borne by others.
    - alisonkisk 5y ago
      Or programming your flash drive to pretend it has 32GB when it only has 4GB, as is done on Amazon.com
    - bdcravens 5y ago
      If you can roll down a hill, it appears to be "working". If it's parked and the radio and headlights still come on, it's "working".
- afarrell 5y ago
  Some problems genuinely aren’t very amenable to mathematical/engineering analysis. Examples: - Fixing a marriage - The Vietnam war https://en.m.wikipedia.org/wiki/McNamara_fallacy https://en.m.wikipedia.org/wiki/McNamara_fallacy This makes avoiding self-deception much harder in those domains.
- hyperxy 5y ago
  I wonder why the need for this validation. I see deluded thinking all the time in this field, in fact, I see it more in this field than any other because it is so easy to be self made here. 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.
  - WalterBright 5y ago
    > 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.
- cortesoft 5y ago
  > is you cannot pretend something is working when it isn't Maybe not, but you can change your definition of what working is.
- jensensbutton 5y ago
  > you cannot pretend something is working when it isn't 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.
  - discreteevent 5y ago
    Sure, but even in your example the it doesn't take long before something hits the fan. On the other hand the trickle down theory of economics (for example) is still going.
    - WalterBright 5y ago
      Communism and rent control's 100% failure rate has never dissuaded any of their adherents.
  - akiselev 5y ago
    > The problem is in the ambiguity around the work "working". 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.
    - dsjoerg 5y ago
      > "for many fields" Like what? Marketing, politics maybe, what else?
      - 5y ago
- randomsilence 5y ago
  >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. 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.
- bitwize 5y ago
  > The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. 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.
- Archelaos 5y ago
  > The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. If your airplane design doesn't fly, pretending it did doesn't work. 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.
  - 908B64B197 5y ago
    > 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 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.
    - WalterBright 5y ago
      > the pilots were not aware this thing was turned on and was steering the plane. 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.
- cercatrova 5y ago
  > you cannot pretend something is working when it isn't 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-lean-startup/4703206-discover-the-4-types-of-minimum-viable-product https://openclassrooms.com/en/courses/4544561-learn-about-le...
- romaniitedomum 5y ago
  > The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. If your airplane design doesn't fly, pretending it did doesn't work. 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.
  - kristjansson 5y ago
    While I do appreciate the cross-species cargo-cult metaphor, I don't think Agile, Scrum and their ilk qualify as engineering in that sense. The program either compiles and does what it says on the tin, or it doesn't. The bridge either stands up, or falls down. Agile et al. are systems for managing humans, who aren't known for responding to inputs as reliably as gears, girders, or compilers.
    - Supermancho 5y ago
      I can design a car that runs on water. It will only go downhill but it works. The bridge either stands up or falls down is an exercise in underspecification rather than a demonstration of an absolute metric.
jollybean 5y ago
The level of specificity in the complexity I think makes it unique. 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.
leoh 5y ago
This comment implies a lack of familiarity with other jobs. If you are a doctor, for example, you have little ability to determine the way you work, unless you are exceedingly elite in your field, and even then can be deeply constrained by the institutions you are a part of.
- patates 5y ago
  Unless you are "exceedingly elite in your field" you wouldn't do much problem analysis as a doctor, you would do routine checks. The point still stands IMO.

WalterBright 5y ago

The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. If your airplane design doesn't fly, pretending it did doesn't work. 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.

stronglikedan 5y ago
> you cannot pretend something is working when it isn't. Tell that to my boss, who wants to ship every prototype and POC to our customers and call it a day.
- WalterBright 5y ago
  You certainly can pretend your car has 10 gallons of gas in it when it has only 1, but you're still going to run out of gas after that gallon is burned. I suppose one could conclude that pretending can work if the consequences are borne by others.
  - alisonkisk 5y ago
    Or programming your flash drive to pretend it has 32GB when it only has 4GB, as is done on Amazon.com
  - bdcravens 5y ago
    If you can roll down a hill, it appears to be "working". If it's parked and the radio and headlights still come on, it's "working".
afarrell 5y ago
Some problems genuinely aren’t very amenable to mathematical/engineering analysis. Examples: - Fixing a marriage - The Vietnam war https://en.m.wikipedia.org/wiki/McNamara_fallacy https://en.m.wikipedia.org/wiki/McNamara_fallacy This makes avoiding self-deception much harder in those domains.
hyperxy 5y ago
I wonder why the need for this validation. I see deluded thinking all the time in this field, in fact, I see it more in this field than any other because it is so easy to be self made here. 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.
- WalterBright 5y ago
  > 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.
cortesoft 5y ago
> is you cannot pretend something is working when it isn't Maybe not, but you can change your definition of what working is.
jensensbutton 5y ago
> you cannot pretend something is working when it isn't 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.
- discreteevent 5y ago
  Sure, but even in your example the it doesn't take long before something hits the fan. On the other hand the trickle down theory of economics (for example) is still going.
  - WalterBright 5y ago
    Communism and rent control's 100% failure rate has never dissuaded any of their adherents.
- akiselev 5y ago
  > The problem is in the ambiguity around the work "working". 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.
  - dsjoerg 5y ago
    > "for many fields" Like what? Marketing, politics maybe, what else?
    - 5y ago
randomsilence 5y ago
>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. 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.
bitwize 5y ago
> The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. 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.
Archelaos 5y ago
> The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. If your airplane design doesn't fly, pretending it did doesn't work. 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.
- 908B64B197 5y ago
  > 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 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.
  - WalterBright 5y ago
    > the pilots were not aware this thing was turned on and was steering the plane. 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.
cercatrova 5y ago
> you cannot pretend something is working when it isn't 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-lean-startup/4703206-discover-the-4-types-of-minimum-viable-product https://openclassrooms.com/en/courses/4544561-learn-about-le...
romaniitedomum 5y ago
> The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. If your airplane design doesn't fly, pretending it did doesn't work. 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.
- kristjansson 5y ago
  While I do appreciate the cross-species cargo-cult metaphor, I don't think Agile, Scrum and their ilk qualify as engineering in that sense. The program either compiles and does what it says on the tin, or it doesn't. The bridge either stands up, or falls down. Agile et al. are systems for managing humans, who aren't known for responding to inputs as reliably as gears, girders, or compilers.
  - Supermancho 5y ago
    I can design a car that runs on water. It will only go downhill but it works. The bridge either stands up or falls down is an exercise in underspecification rather than a demonstration of an absolute metric.

jollybean 5y ago

The level of specificity in the complexity I think makes it unique. 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.

leoh 5y ago

This comment implies a lack of familiarity with other jobs. If you are a doctor, for example, you have little ability to determine the way you work, unless you are exceedingly elite in your field, and even then can be deeply constrained by the institutions you are a part of.

patates 5y ago
Unless you are "exceedingly elite in your field" you wouldn't do much problem analysis as a doctor, you would do routine checks. The point still stands IMO.