Learning to Code Slow Again
A reflection on AI, productivity, and Recreational Programming
A reflection on AI, productivity, and Recreational Programming
In the last four years, LLMs have become more and more powerful. I still remember when ChatGPT first came out, and I was surprised by how good it was at generating text. Now there are more LLMs than I can count, each with its own strengths.
Lately, they have also changed the way I see programming itself.
The problem was not that AI made programming easier. The problem was that it made me question what it means to be a software engineer.
When I first started programming, I found it fascinating how stupidly simple logical instructions could make a powerful program that does something useful. I could even imagine making my own Twitter, since it was literally what my second-year assignment was. It felt like I could build anything, limited only by my own creativity.
The process of programming is definitely not without challenges. There would be errors, and we would need to debug them, usually by printing some messages inside if blocks. If that didn’t work, Stack Overflow would come to help. It was stressful, but very satisfying once we solved them. Sometimes making it work was enough. Who cares if it takes minutes for the program to run?
Over the years, I found that AI could indeed help a lot. Soon enough, many of those problems became easier to solve with LLMs. It felt a lot less stressful to debug errors. Inefficient code could be optimized with only a single prompt. It really has made me more productive and helped me solve more problems.
But now it feels more and more like “How can I force AI to solve this problem?” rather than “How can I solve this problem?”
It has become addicting to just prompt with barely touching the code. Even now, it has started to feel like more people can solve problems that previously required software engineers.
So what is the need for a software engineer?
It started to feel scary to code. Not because I could not code anymore, but because I kept comparing myself to something that could produce more code, faster, in one sitting. I lost my identity and was burnt out.
By some chance, there was this guy known as Tsoding who just talked about dynamic arrays in C, and somehow it became an internet meme. But the way he talked about it interested me. I gave him a chance and started to watch his streams.
He amazed me. He broke all of the tech bro stereotypes that had been feeding my mind lately: ship fast, optimize everything, use the newest tool, automate everything, and never waste time reinventing the wheel. He just did programming for the sake of it.
He often reimplements something even when better solutions already exist. He programs incrementally. He does the easiest solution that works first and then later refactors it if some optimization is needed. He spends hours building something that AI can do in minutes. He makes things that many software engineers nowadays consider taboo feel like a normal part of programming again. In a strange way, watching him reminded me of what I used to imagine software engineering was.
What he did was called Recreational Programming. It means programming not because it needs to become a startup, not because it solves a business problem, and not because it looks good on a resume, but because the act of building it is fun. And I think this is what we lost.
All this time, we have been force-fed the idea that being a productive software engineer is measured by the speed, usefulness, or business value of the program. While that might be valid, what made programming fun in the first place for me was not any of that. And worse, LLMs helped me become more productive while making me feel like I was programming less. This is what led me to burnout.
AI can probably write more code than me. It can probably write it faster, and sometimes even better.
But that was never the whole point.
The point was the feeling of turning an idea into something real.
The point was getting stuck, slowly understanding the problem, and finally making it work.
The point was building something not because it was useful, but because I was curious enough to try.
Maybe being a software engineer is not about proving that I am still needed. Maybe it is about remembering why I wanted to build things in the first place.