We don't experience the sun going up and down, we experience its direction changing relative to the horizontal plane, and it is not an illusion: it matches planetary motion. The mistake arises when interpreting the raw experience. Sensations don't lie.
Another example: Metal feels colder than plastic, but the sensation is right again: you are loosing more heat when touching metal.
Bounded collections still allow for useless reachings of their bounds, and corresponding memory and CPU wastes (and possibly functional/domain issues).
The main reason I saw around me for memory leaks in GC'ed languages, is devs only thinking about the 'add' part, not the 'when-to-remove' part. I always think of both and the only leaks I got were from slowdowns causing events to pile up in scheduler queues (deliberately not bounded).
Before, not after: when the code makes it hard to implement a new feature (the definition of technical debt: code that is properly designed but only for previous features), first refactor the code to make the feature easy to implement, then implement the feature.
As John Carmack said: "if a lot of operations are supposed to happen in a sequential fashion, their code should follow sequentially" (https://cbarrete.com/carmack.html).
A single method with a few lines is easy to read, like the processor reading a single cache line, while having to jump around between methods is distracting and slow, like the processor having to read various RAM locations.
Depending on the language you can also have very good reasons to have many lines, for example in Java a method can't return multiple primitive values, so if you want to stick to primitives for performances you inline it and use curly braces to limit the scope of its internals.
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.
>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.
>My largest source of sanity in this career is to spend extra time at work doing the things that I love in my position. Ironically, I get high performance ratings because of this - but have to fight to spend my time on it.
Why do you have to fight if it's extra time? And couldn't you avoid the fighting by just doing it on regular time?