Developers Are Solving the Wrong Problem

Summary

Everyone is either offended or excited about “vibe coding.” It’s all the rage and going to solve all your problems, or it’s the next great evil spewing crap code all over your systems. Those of us who love well structured clean code which is modular and concise seem to be a dying breed. For someone who’s early career was shaped by McConnell’s Code Complete, Brooks’ The Mythical Man Month, and Fowler’s Refactoring, this feels.. odd. But when we dig into the WHY, something interesting happens: Why do we want “well structured” code? Well structured code is easier to understand to debug, extend, and maintain. But is there a single, shared definition of “well structured”? Why do we want “clean” code? Clean code is easier to understand to debug, extend, and maintain. But is there a single, shared definition of “clean”? Why do we want “modular” code? Modular code is easier to understand to debug, extend, and maintain. But is there a single, shared definition of “modular”? Actually, yes the Single Responsibility Principle addresses this one. Why do we want “concise” code? The less code there is, the easier it is to understand to debug, extend, and maintain. But too concise can make things harder to understand. But when it gets down to it, all of these goals point at the problem. It’s Not About You Previously, we needed “well structured clean code which is modular and concise” because writing code was easy but reading code is hard. Really hard. Painfully hard. Making sense of someone else’s code is harder still. All of our practices are really just to decrease that pain. Anything we can do to make it easier for the next person – or ourselves six months from now – is worth it. But what if the next “person” isn’t a person? If we assume that the code will only be debugged, extended, and maintained by a computer, most of our reasoning for clean code goes out the window. We don’t care what a human can do with the resulting (output) code as long as they can consistently generate c...