It seems to favor the compact and efficient kind of code that is brittle in the hand of a mildly competent junior dev, or a heavy multitasking senior.
I like smart code, in fun projects, but on the job I prefer fast to read and to reason code. Don’t try to be fancy.
So I guess that’s a book to challenge my assumptions. I like that. Thx.
https://github.com/dwmkerr/hacker-laws#kernighans-law
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
I know it's explaining the joke, but you've blown past "clever" if you've reached the point where you can't debug it.
Otherwise, you're the only one who can fix your code, and becomes a whole bus factor thing.
We don't have the same level of "proven solutions" and constraints and mathematical rigor that engineering has, nor do we have the legal/liability requirements of "Professional Engineers".
I hope that I qualify as the equivalent of an artisan, like a carpenter that makes furniture, that has elements of both art and craft. Even as I've moved up (and down) the hierarchy of programmer/senior/"architect"/manager.
Programmers fit the "craftsperson/journeyperson/apprentice" model much better than engineering practice.