A policeman sees a drunk man searching for something under a streetlight and asks what the drunk has lost. He says he lost his keys and they both look under the streetlight together. After a few minutes the policeman asks if he is sure he lost them here, and the drunk replies, no, and that he lost them in the park. The policeman asks why he is searching here, and the drunk replies, “this is where the light is.”
This anecdote is silly, but the effect it describes shows up everywhere in life.
For software developers, source code is often “where the light is,” and so that’s where we focus by default.
But for all the problems we face in software development, almost none originate in source code. They are business problems, or communication problems, or infrastructure problems, or just plain old human-to-human problems.
When we turn a blind eye to the problems that accumulate upstream from our coding work, their damaging side effects do appear in the codebase. Work is rushed and goals are poorly defined, so code gets buggy and difficult to understand. The requirements keep changing, and a stable domain model never takes shape. The wrong tools are chosen because people who haven’t created space for careful learning are under pressure to just pick something, quick.
All of these things impact the health of a codebase, and so they’re easily mistaken for coding problems. As a result, programmers focus on coding best practices and idioms, because these things do generate a positive impact in the area that is most visible to them.
But this approach is like following a trail of footsteps under the streetlight, expecting it to lead you to the missing keys. It feels productive, but it will never get you to the right place.