There are clever code constructs in the world. Some of them are quite useful in the right circumstances. Some, like Duff's device or the Curiously Recurring Template Pattern might prompt a double-take or some serious study to comprehend. Some are are even simpler to understand, like the Visitor design pattern, yet puzzling them out and making an implementation that actually works releases some endorphins. You feel accomplished for working through a difficult code device. Actually having N-levels of nested lambdas feels like the work of a wizard when it actually works and gives a result you are looking for. Clever and inobvious operator overloading can make some weird code work, and make you feel pretty good. A bizarre bit of code can feel like a real accomplishment. I was listening to a Stack Overflow broadcast a while back and heard one of the participants praising an obscure code trick as being "elegant", while the other corrected him that it was a kind of a hack.
Dirty tricks may stretch your brain in new ways and teach you things you would not otherwise have learned about your programming language or environment. Learning strange devices and code patterns can open you mind to new ways of thinking about software. These puzzles rightfully make you feel good about your growing skills. That "eureka!" endorphin rush is prized by mental athletes and rightfully so.
I've built things that made me feel proud for the wrong reasons.
Being "clever" is not strictly a bad thing. Being someone who loves code means loving a good puzzle. The problem is that the rush of figuring out or implementing puzzle-based code feels like an accomplishment and a triumph, when in reality it may be opulent self-indulgence.
Certainly there is plenty of code in the world that suffers more from a lack of brilliance, being unintentionally (even unknowingly) stuffed to the brim with implementation complexity. Programming stupidly tends to produce more code than necessary, and more complicated code as one kludge covers for the deficiencies of another kludge and the patches pile up on each other. Not thinking about the code, not learning to write code that is efficient in effect and parsimonious in quantity, not considering side-effects and weaknesses, not programming *well* is a horrible thing. We are told that 80% of all people believe that their work is "above average." That means nearly 40% of us are wrong about our work, and also not in a place to even recognize it. We all need to learn more about this crazy trade.
Yet the vast bulk of code is more workaday stuff, and would benefit more from from clarity and simplicity than from ego-stroking brilliance. We don't need very many Duff's Device implementations or clever metaclass madness or obscene table-based subsystems that totally obscure the flow of a program with levels of indirection through void pointers. There are things that we *can* do but should not do, and yet these things feel like implementation triumph. We put them together, and by golly they actually work! They may even be performant, yet even our better coworkers are loath to maintain the code.
The problem is not that we need to dumb-down the code. The problem is that we need to simple-up the code. If we can turn our mental resources to find ways to eliminate opulence and duplication and create more amazingly simple code, we can eventually get a reputation for writing code that attracts our coworkers and fluidly accepts change. That beats a reputation for writing obscure, difficult, and fancy code any day.
My dream is that my coworkers will see code I've worked on and breathe a sigh of relief. "Oh," they'll say, "it's Ottinger code. No problem." This echoes Ward Cunningham's comment to Uncle Bob (quoted in Clean Code), that truly clean code does pretty much what you expect it to do.
I think that Abraham Lincoln's stated goal is still a worthy pursuit for the software professional.
No comments:
Post a Comment