Sharp tools, dull minds
What keeps me coming back to the writing of Nicholas Carr is that he splits me in two, violently agreeing and disagreeing at the same time. And then I have to step back and tell myself, “don’t rush to agree or disagree, just try to understand what he’s saying.” He has rapidly become one of the most thoughtful and balanced critics of our current digital age.
Psychologists have found that when we work with computers, we often fall victim to two cognitive ailments—complacency and bias—that can undercut our performance and lead to mistakes. Automation complacency occurs when a computer lulls us into a false sense of security. Confident that the machine will work flawlessly and handle any problem that crops up, we allow our attention to drift. We become disengaged from our work, and our awareness of what’s going on around us fades. Automation bias occurs when we place too much faith in the accuracy of the information coming through our monitors. Our trust in the software becomes so strong that we ignore or discount other information sources, including our own eyes and ears. When a computer provides incorrect or insufficient data, we remain oblivious to the error.
How automation is creeping higher up the labor stack to so-called white-collar knowledge jobs, especially programming, has been on my mind for a while. Modern IDEs are getting “helpful” enough that at times I feel like an IDE operator rather than a programmer. They have support for advanced refactoring. Linters can now tell you about design issues and code smells. The behavior all these tools encourage is not “think deeply about your code and write it carefully”, but “just write a crappy first draft of your code, and then the tools will tell you not just what’s wrong with it, but also how to make it better.”
I’ve been on both sides. There are times when I fire up Eclipse just so that I can auto-complete my way to put out some code now. There are other times when I stare at the stark screen of a text editor (not IDE), the blinking cursor accosting me: “what the hell are you going to do now without all your fancy crutches?” But after the initial stab of fear and helplessness, I revel in the freedom of it, and savor the delicious rebellion of writing code without an IDE nagging me with suggestions and hints and corrections at every damn keypress like a 21st century Clippy from a horror movie.
Am I arguing for primitive tools? No. What I’ve described in the previous paragraph are my personal feelings while writing code. The tools (at least, the good ones) encode the knowledge and hard-won lessons of an entire army of programmers. They often point me to issues I’m blind to while writing code because I’m in such a rush to just make the damn thing work. In aggregate, they lead to a cleaner codebase.
So what am I saying then? I’m saying that we should let the tools help us without becoming crutches, to let us write sharp code without dulling our minds. That sounds paradoxical. It is a subtle mental stance one takes towards one’s work, tools, and output.
The most guru programmers I’ve seen have this paradoxical zen-like stance: they use the tools to the full extent possible (because, well, that’s what they’re there for), but understand enough about what those tools do and how they work to be perfectly productive even without them. It reminds me of the concept of moh, and non-attachment, while being an active participant.