"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?"
The limits of the team, even insisting on >1 person being able to fix any code written by the team, are probably much higher than the average of the team. Furthermore, the average isn't going to improve much if code is never written above it. This isn't to say go all out with the most clever code possible, or make things difficult for the sake of difficulty, but consider that it's possible to help upskill your team by showing them better ways (even if sometimes technically "cleverer ways") to write code. It's ok if something isn't as familiar to everyone initially -- exposure helps that. Do better code reviews, code walkthroughs, lunch & learns, book clubs, consultants to come in and teach something, there's lots of ways to improve as a team.
I once talk about the art of programming in a job interview and got flashed by a bachelor of biz with: but isn’t it suppose to be engineering? I died a little bit inside…
I've been a programmer for 40 years, I've never considered myself to be an engineer.
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.
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.