Ask HN: Does software development cause greater decision fatigue than other jobs
I'm gonna buck the trend here and say that this might be true.
Software development indeed has lower stakes than other professions (legal, medical). No one is going to die or be put in an iron cage for life as a result of our work -- well, at least not directly. But the bad consequences of their decisions leave with their clients. We are often tormented by our mistakes for years on end.
If you work in software long enough you also start to perceive a cyclical pattern in software "best practices" which leads to burnout. The hard problems you cut your teeth on as a journeyman become yesteryear's folly, and vice versa. If there are such a thing as fads in medicine or law, they certainly move at a slower pace than software.
It's also possible the developer makes more decisions, albeit at lower stakes, than doctors and lawyers. When you write a piece of code, you probably make dozens of tiny decisions per hour. Think about the last time you saw a doctor. Did you notice him/her pause at any point to think something over or make a decision?
So which is more prone to decision fatigue: a worker who makes a few decisions per day, based on a stable body of literature, that may lead to someone having a bad time somewhere far away in the world? Or a person who makes 100 decisions per day, based on fads, hunches, politics, and blog posts, that may increase their own workload by a factor of 10 in 6 months?
I recently watched a lot of Lean Manufacturing/Agile videos recently[0] (physical factories, not software), and was looking to translate some of the methods to the SDLC process. What's interesting is related to this. The endgoal of Lean process is to take out all the decision making out of building/repeatable process, and only spend struggle/decision making on improving the process. The Kanban Cards tell everyone what to do. See card? Do x and move card to y. Repeat. In the current state, doesn't really apply to software.
The goal of software is to automate/codify everything, so we _should_ not repeatedly doing things. Even implementing a function takes a few decisions. What's the name? What's the input? Input validation? What's the output? What's the name of the variables inside the function? Should you use .map or for in? Not to mention thinking about interactions between parts of the larger infrastructure/system (browser for FE, network stack for full stack, DB for BE). Every change we're making is an "improvement" to the understanding of the business process/problem to solve. To reduce code LoC means to decide on the framework/approach/DB/limitations. More decision making. And the abstractions can go on and on.
From my Front End point of view, I'm handling a lot of intertwined concerns. On the actual app side, there's UI Layout, copy (and dynamic copy for pluralisation or otherwise), data correctness, user input/output validation, handling errors (from BE or network) (and displaying the correct error and do the correct action after that). On the tooling and deployment side, I have to be aware of domain/subdomain, URLs, mobile/desktop interaction (back button on mobile on modal), deploying, preload/precache, compiling the code with bundlers, optimising size, knowing the browser limitation, security concerns, etc. I'm sure I missed a lot still.
I know there's also this much nuance and complexity to any part of the stack (BE, IoT, DevOps, QA) even non-tech in Design and Product. The computer is so abstract that I feel we as an industry haven't (or can't) converge into something that is easier to work with (org, process, or tooling wise), even across organisations.
Wow! I've researching different parts of SDLC and Software Engineering / Software Architecture / Distributed Systems in general, and I noticed a lot of cross-cutting and intertwined/interrelated concepts. I even start adding a first page/slide of every document titled "Intertwined concepts".
I have many friends in medical jobs where their decisions can have extreme effects on other people’s lives, to the point of risking life or death if they make the wrong decision for the patient or miss some key information.
From that perspective, software development feels like a low-stakes game.
Obviously there are many jobs with less decision fatigue, but I don’t think software development is uniquely bad compared to other highly paid professions like legal or medical.
All things considered, software engineering is one of the cushier high-paying careers out there. We definitely have it good.
No, because the great thing about software is how malleable it is. Try undoing things in hardware, construction, law, or surgery.
No. Not even close. Most tech decisions are reversible (we even have term for it - technical debt), which lowers risk and means we don't need to avoid decisions. We have tools that mean we don't need to make repetitive decisions about a lot of things (linters, code formatters, codemods, etc) - once we've decided the tooling keeps everything nice and tidy so we don't have to question our decisions. We have it so much better than most people.
Precisely - the reversability makes a huge difference. Just make sure you use version control.
Comparing programming to tax preparation:
It depends, of course. Both have hard days where you are hyper focused and making critical decisions, and easy days where the work is fairly routine. I find tax prep to be more decision exhausting, perhaps because the tax code and IRS are involved, perhaps because the decisions need to be explained to the client.
Maybe. Personally I think the poor quality decisions are more likely to be the product of politics or some constraint that leads to not having a good choice and just having to go with the lesser evil.