- The CPU is infinitely fast.

- RAM is infinite.

- CPU caches don't exist.

- Cache lines don't exist.

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

Of course they do. A program's code is mostly a graph of names; they can be cornerstones of its clarity, or sources of confusion and bugs.

The first thing I do when debugging is ensuring proper names, sometimes that's enough to make the bug obvious.

Singapore is quite civilized, and they conduct caning strokes.

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

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

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.

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.

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?

Math.abs(Integer.MIN_VALUE) in Java very seriously returns -2147483648, as there is no int for 2147483648.