In this post I would like to talk about an idea that I've played around with in my work recently - slowing down.
There is a saying attributed to sharp shooters in the military: "Slow is smooth, and smooth is fast". More and more, I'm learning that this is true in software development as well. And it's not less true in the AI era - on the contrary, I will argue in this post that it is more true in the AI era. Let me explain.
AI promises science-fiction like increases in productivity. But I have a question: Can we, in the long-term, not the short-term, sacrifice quality on the almighty altar of "productivity"? I would argue that this is a highly questionable proposition. Yes, AI can code faster than I can. I don't dispute that. But can it produce higher quality than I can? In places, maybe, yes. But across the board? Across a whole system? I would argue that it is not remotely at that level yet. And I argue from my own experience, using AI daily, albeit more as a research assistant than as something writing code for me.
There are two reasons for that: One is selfish, the other has to do with responsibility and being a craftsman instead of "just" a coder. The selfish reason is that I love to code. It is the best part about the job for me. And I'll quit before I let a machine take something I love away from me.
But the other is that I will gladly put up my ability to produce clean, high-quality code by engaging in a dialogue with business people and architects against any AI you choose. Experienced developers are still way better at producing clean, maintainable and extensible abstractions and therefore code then AI is, and may ever be. I mean generating unit tests for existing classes? Ok, fine, if you carefully review what it generates, then yes, it can save time. Though I have yet to come across a case where I didn't have to modify the output, even for simple classes.
But generating production code in critical systems? Unless someone forces me to I will never do that. The reason is the following: If I make the GIT commit, or even if I just review the GIT commit, I am or at least share in the responsibility for the code. And I'm not just hired to produce code that somehow, by some miracle, does what it's supposed to do. I'm hired to produce high-quality technical solutions that not only customers, but also my fellow developers love to work with. I'm not a code generator. I'm an author of well-designed solutions, and that starts with well-designed code. The ultimate measure of code quality is this: If you write code that is so easy to understand and well-designed that another developer can read it, maintain it and extend it without consulting you then you have done a truly masterful job. In other words, great software developers are, and this is admittedly an ideal we can never completely realize in practice, 100% replaceable.
But to even come close to that ideal you have to code slowly and resist the hype around measuring productivity by raw speed. This is where the title of this post comes in - you have to move slowly. Take your time. Think about each and every line, and never loose sight of the context in which you create the code. All this requires effort - way more effort than producing something that somehow, someway "works". But well-designed systems are easier, and also faster, to extend and maintain than poorly designed ones. I don't agree with Robert C. Martin that making a mess costs us time instead of saving it on every time-scale. In the short term, and to some extent even a little longer than that, making a mess can save time. But not in the long term. In the long term quality saves time, and also money because it produces less bugs.
And in my experience the reward of working this way is the feeling that you are not just someone payed to do a job, but that you are truly practicing a craft, and that you are practicing it well. Doing things well is one of the most fundamental sources of human joy.
So, in the age of AI, you have a decision to make: Do you want to buy into the "it's all about speed" hype - or do you want to be a craftsman in the best sense of the word?
Will you engage in slow programming? Because remember: Slow is smooth. And smooth is fast.
Top comments (0)