[tboyd47]

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?

[raihansaputra]

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.

[0]: https://www.youtube.com/watch?v=EqtKKkastWk

[nivertech]

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".