My coding heuristics now pretty much boil down to:
1) Less code is better code. The only code with no bugs is no code. After you get something working, remove as much code as you can.
2) Simple code is better code. Don't waste time making your code complex for the sake of being efficient until you've used it and proven that it's a bottleneck with a profiler. Otherwise, just do the simplest thing you can think of that will work.
3) Don't think too far ahead unless you specifically have been tasked with it. Otherwise, do what will work now. Refactor when necessary.
The worst is a huge monolith that has dozens of styles and favorite patterns sprinkled all over from years of opinionated developers leaving their mark. For anything non-trivial, it might take an hour or two just to get your bearings and enter the mindset of the original developer. Then, you have to make the decision of whether your new function is going to follow that (broken) pattern or add yet another new one.
Does this mean firing him?
If, over time, he continues to introduce more problems than he solves then he might be managed out but I'm hopeful that won't happen.
In this vain this often posted article is fun https://grugbrain.dev/
A debugger needs to be smarter than the person who wrote the code being debugged.
If someone is at their smartest when writing a section of code, they are thus unable to successfully debug problems involving that code.
> 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 hate to go against the Wisdom of the Ancients here, but there is no point at which you're too dumb to debug your own code. With increasing code cleverness, you may lose the ability to make quick mental jumps when debugging it - but this only forces you to be methodical. With a methodical approach, you will find the bug - the thing you might be missing is not smarts, it's patience.
As for cryptography: digital locks are broken by default. It takes care and smarts to design one that isn't trivially breakable. Trying to design a lock that's too clever for you to understand will almost always yield a lock that's broken just past the boundary of your understanding, so you should be able to break it once you realize it's possible and you put a little effort.
As for physical locks: same as above, plus you can always break it literally, by applying enough physical force.
The principal-agent problem looms large.
The best developers solve the hard problems without writing the worst code.
Not to get on a soapbox, but I would imagine someone with great pattern recognition would be able to realize this way of doing things is deranged; and ultimately helps them more than the team- On second though: perhaps they are genuinely the smartest people in the room -- prioritizing their image and importance by making others believe they're too stupid to understand what's going on.
I really should go study Gang of Four -- job security demands it.