I saw a Reddit post recently that highlights what I think is a relatively common but totally misguided view in tech about the value of “technical” vs “nontechnical” discussions, though it didn’t use those words.
I saw a Reddit post recently that was a list of popular/recommended books for developers (it must be the season; I’ve seen at least three similar listicles in the day or two since then). One of the top books was Clean Code by Robert Martin, and there was a comment about how the book was popular because it was “easy to digest” despite giving almost no “meaningful substance about how to solve problems”.
This rubbed me the wrong way. Regardless of the merits of Clean Code specifically (I found it valuable but your mileage may vary), I felt this comment showed a misunderstanding of what problems we try to solve as engineers.
In one sense, the commenter is basically right: the book doesn’t talk through a lot of specifics for how to solve particular technical problems. There’s very little in there about data structures, for example, and the code examples are pretty mundane; you probably wouldn’t be shocked to see either the before or after code snippets in your own company’s codebase.
But that misses the whole point. The value of the book - and of books like it - is not that it is talking about how to solve problems through code; it’s that it’s talking about solving problems about code.
I remember several times when I looked back through my early-career code and saw technical mistakes, yes, but also where I wrote code that worked and was efficient enough, but which was a total mess anyway. I think most people who’ve been programming seriously for more than a few months have had similar experiences. In things like this the problem is not so much in the code as how the code interacts with the world outside itself, from our trying to understand what the hell we were thinking when we wrote it to a future maintainer spending hours to debug an issue they have when they use it in a way we didn’t initially expect.
Problems like this are more part of the ‘art’ of programming than the science.
It’s not enough for us to solve technical problems. The code we write rarely exists in isolation, and it is absolutely possible to have code that efficiently solves a problem while simultaneously making the system that contains it harder to understand, test, and maintain.
We must think about how our work fits into the larger systems we build and work in and what tradeoffs we should make in one aspect of our system to benefit others. Solving purely technical problems is just one part of our road to mastery.
Top comments (0)