I can guarantee you that I have been doing just that for 20 years, creating and working on the same codebase, and that it only got better with time (cleaner code and more robust execution), though more complex because the domain itself did. We would have been stuck in the accidental complexity of messy hacks and their buggy side effects if we had not continuously adapted and improved things.

In manufacturing there are economies of scale and adding more people increases workforce, in mindfacturing there are diseconomies of scale and adding more people increases confusion, yet many managers view software with a manufacturing mindset.

When I do functional unit tests, they tend to include the same functional logic as the code to test. What I strive for is then to express it in a different and possibly clearer way, and I see the testing as mutual testing of two implementations, one more easily humanly checkable.

Agreed. A program is made of names, these names are of the utmost importance. For understanding, and also for searchability.

I do a lot of code reviews, and one of the main things I ask for, after bug fixes, is renaming things for readers to understand at first read unambiguously and to match the various conventions we use throughout the codebase.

Ex: new dev wrote "updateFoo()" for a method converting a domain thing "foo" from its type in layer "a" to its type in layer "b", so I asked him to use "convertFoo_aToB()" instead.

I only use "TODO" eventually followed by a sub-classification like "TODO bug": it maximizes discoverability by other devs and tools, and allows for a lot of variants (both technical and/or functional) while still permitting a complete scan with a single grep.

Or: the hardware that generates beliefs about how things should be - whether based on religious or ideological dogma -, as opposed to science which is not prescriptive and can only describe how things are.

Domains are often not very deep, as a lot of people need to understand them.

I've seen smart people quickly figure things out and propose upgrades in a matter of weeks, on points lifelong experts overlooked, or were too lazy to dig.

Reminds me of a company that was looking for people good in both the domain and software, to bridge the experts/devs gap (which is often a bottleneck, information flow between brains being slow and unreliable). They found out that it was much easier to teach the domain to devs, than to teach software to domain experts, i.e. that software was the hard skill.

>the same person with a different psychological education can become suicidal or give zero damn about the same situation

Or even like it. Reminds me of a quote about solitude: "I live on what others die of." (Michelangelo)

>burnout from having to deal with bloated software and the deadlines associated with that

I did not have the deadlines, but to bear having to deal with bloated software, my solution was vodka: since it has no color, I filled mineral water bottles with it and everyone thought I was drinking water.

Hah! Yeah I drank more alcohol that I normally do during this period, however I work from home so I never had to hide it :D

Jujutsu - I like the name.

I often see programming as going MMA with data, until you get what you want out of it.

Using brute force algorithms is going berserk, vibe coding is spamming summons in hope they get the job done, etc.

Agreed, I'd just like to complement vibe coding feels like spamming retarded Mr Meeseeks hoping they get get the job done. It's _probabilistic programming_