There is a specific kind of quiet I have been thinking about lately.
It is late. The office is empty, or the house is finally asleep. There is a problem on the screen that refuses to be solved, and for once there is nothing else. No Slack. No calendar invite. No one asking for an update. Just a cursor, a failing test, and the slow, private work of understanding what is actually going on.
I miss that quiet more than I thought I would.
Somebody asked me recently whether I missed writing code by hand, the way we used to before the machines started doing so much of it for us. I gave a quick answer at the time. Something practical. Something about leverage and output and how the job was never really about typing. All of that is true, and I have written about it more than once. But it was not an honest answer. The honest answer is yes. I miss it. I miss it in a way that has very little to do with productivity and everything to do with what the work did for me.
It started as a puzzle
Every real problem was a small mystery. A bug that made no sense. A system behaving in a way the documentation swore was impossible. You could not brute force your way through it. You had to sit with it. You had to hold the whole thing in your head at once: the data flowing one way, the state changing another, the single assumption buried three layers down that turned out to be wrong.
There is a particular feeling when the shape of the problem finally clicks into place. It is not loud. It is a quiet click, somewhere behind your eyes, and suddenly the mess resolves into something you can actually see. For a moment you understand a small piece of the world completely. Not partially. Not approximately. Completely. There are not many places in adult life where you get that.
The research was half the pleasure
Before I wrote a single line, I read. I read the documentation, and then I read the source when the documentation lied. I read old forum threads from 2011 where someone had hit the exact same wall and described it badly, and I read the one reply underneath that quietly solved it. I learned how things actually worked, not how they were supposed to work.
That reading was never wasted. Every hour spent understanding a library, a protocol, a strange corner of the language, compounded. You were not just fixing today’s problem. You were drawing the map you would use for the next ten years. I still carry maps I sketched fifteen years ago, late at night, one problem at a time.
Then came the flow
And then the part no one warns you is addictive. You start writing. Test, red. Adjust. Test, red again. A small change. Test, green. Then the next one. The loop is tight and honest and completely yours. The computer does not flatter you and it does not lie. Your code either works or it does not, and when it does not, it is patiently, precisely your fault.
Hours would disappear. I would look up and it was dark outside, or light again, and I had not noticed either happen. People talk about flow as though it were a productivity trick. It was never that for me. It was closer to meditation. The world narrowed to one problem, the noise in my head went silent, and for a while there was only the work. I have spent a lot of years since trying to find that same silence in other ways. Very few of them worked as well as a hard problem and an empty evening.
The craft was in the final read
The part I loved most came at the end. You would finish, and then you would open your own diff and read it like a stranger. Not the author, the reviewer. You would look for the line that was clever instead of clear. The name that made sense at midnight and made none in the morning. The comment that explained what the code did instead of why. You would delete things. You would rename things. You would make it smaller.
That final pass was where the craft lived. Anyone can make something work once. Making it simple, making it obvious, making it kind to the next person who would have to read it, that was the real skill. And then the edge cases. Always the edge cases. The empty list. The null that should never happen. The user who would do the one thing you swore no user would ever do. Hunting them down was tedious, and it was also a kind of care. You were quietly promising the future that you had thought about it.
And then you were brave
Then you did the bravest thing a developer does. You opened the pull request.
There is a small, particular anxiety in that moment that anyone who has shipped code will recognize. You have spent hours, sometimes days, on something you have quietly started to think of as a little bit of a masterpiece. It is clean. It is tested. You are proud of it. And now you are about to hand it to people whose entire job, in that moment, is to find everything wrong with it.
The comments would come. Sometimes a few. Sometimes far too many. A question about a decision you thought was obvious. A better approach you had not seen. A blunt “why?” underneath the line you were most proud of. It stung every single time, even after twenty years, even when the reviewer was right, and especially when the reviewer was right.
But that was the point. The code got better because it was seen. You got better because you were questioned. The masterpiece you walked in with was almost never the thing that shipped, and the thing that shipped was almost always better for it. Being reviewed was humbling in exactly the way that makes people good at their craft.
Why it felt like therapy
Here is what I understand now that I did not fully understand then.
Writing code was one of the few parts of my life with a clean loop. A problem, a real one, with a real answer. Effort that mapped directly onto progress. A moment where the thing did not work, and then a moment, entirely because of you, where it did. Most of adult life does not offer that. The problems that matter most, the ones about people and organizations and health and the future, are ambiguous, slow, and never fully solved. Code gave me a small, honest corner of the world where I could put something right and actually know that I had.
That is why it felt meditative. That is why it felt therapeutic. It was not the syntax. It was the wholeness of it. The completeness. The rare, grounding experience of a problem you could actually finish.
What I hold onto
I do not write much code by hand anymore, and neither do most of the people I work with. I have made my peace with that. The tools are extraordinary, the leverage is real, and I am not interested in pretending the old way was better simply because it was mine. It was not always better. It was often slow, and lonely, and stubborn in ways that helped no one.
But something real did go quiet when the typing stopped, and I think it is worth naming instead of waving away. The craft has not disappeared. It has moved. It lives now in the clarity of what you ask for, in the judgment to see when the answer is wrong, in the taste to keep what is good and delete the rest. That is still meditative. That is still a kind of care. It just wears different clothes.
Still, every so often, I close everything, open an empty file, and solve something small entirely by hand. No assistant. No shortcut. Just me, the problem, and that old, particular quiet.
I do not do it because it is efficient. I do it because it reminds me why I fell in love with this in the first place.
Final words
If you have been doing this long enough to feel any of that, I would love to hear from you. What is the one late night, the one stubborn bug, the one small masterpiece you still remember solving entirely by hand?
You can find me on LinkedIn (linkedin.com/in/ivanturkovic), X (x.com/ithora), and Threads (threads.com/@ithora).
If you want to reach me directly, the contact page is at ivanturkovic.com/contact.
For hiring or fractional CTO inquiries, you can book a 30-minute call at cal.eu/ivan-turkovic/30min.
So tell me: when you open your editor tomorrow morning, is any part of it still fun, or did that quietly become something you used to do?
Then tell me what you think. Do you miss writing code too, or are you glad to let it go? I am genuinely curious where you land.
If this post made you think, you'll probably like the next one. I write about what's actually changing in software engineering, not what LinkedIn wants you to believe. No spam, unsubscribe anytime.