12 things I miss since coding died

When I was 14, my 19-year-old cousin taught me how to code. He had a successful business and took me under his wing. By teaching, I mean that he gave me tasks I thought were impossible and just asked me to do them (I knew absolutely nothing about coding). 

On the good days, it was like solving a hard puzzle. You have multiple ways to solve it, and you need to figure out the best one. There are some rules, and you slowly piece things together. 

On the bad days, I felt so stuck that I seriously considered pouring water over the laptop, so I could say, “Sorry, I can’t work, oops”. But when I was finally able to figure the solution out (and I always did), the intellectual satisfaction was so addicting. 

It’s no secret that software has changed. Coding by hand is dead, I haven’t written a line of code in more than a year. 

But… I really miss it. Yeah, I said it. Solving coding puzzles and being paid for it, is something I really, really enjoyed (even after I became a manager). 

We cannot just move on without giving a proper farewell and acknowledging that loss. Yes, there are many exciting possibilities with AI - but I don’t want to talk about them today. I want to talk about the exciting/weird/frustrating experiences I’ve had over the last 17 years, as they won’t happen again.

Here’s my list, I'd love to know which ones resonate the most with you.

I loved debugging complex and unexplained behaviour, especially weird race conditions. 

My method was very old-fashioned - I opened a spreadsheet, rows for times, columns for services/systems. And I slowly placed logs/events from everywhere, starting to assemble the puzzle. Even with platforms that held all our logs, I still found that method the most efficient for deep understanding. You can find the gaps that way, and all the weird anomalies. 

And when you find that small clue, thinking: “Weird.. That log wasn’t supposed to be here”, and then another one, and another one - finally understanding the weird bug. 

Amazing feeling.

I’m not a huge fan of code reviews, very often it was a chore. But once in a while, you really get into it. You dive deep into the code, and find some meaty and unexpected findings. Not a nitpick or a bug fix, or an obvious mistake by the other engineer - something so complex you felt like “yeah, that was important”. You knew the PR author would read it and respect you a bit more for finding it.

Going so deep into a rabbit hole - and climbing out of it. 

You try to fix something, and it's something else, and then it's something else, and then it's something else, and then it's something else. You feel like there's no way you'll be able to get back to what you started with. 

But slowly, you climb out piece by piece, like filling in an emptying a stack data structure. 

I was born in Russia, and many of my relatives are still there. I flew quite often in my childhood from Moscow to my family in the middle of Siberia (Irkutsk). It's a six-hour flight, and all you see is forests. I remember thinking to myself: there's a high chance that if I dropped somewhere here and went in a random direction for an hour, I might be the first human being who actually stood in that spot. The first ever in all of humanity who stood in that exact spot. Something about that possibility excited me.

12 years ago, I worked for a big corporation, and we had an on-prem RedHat OpenStack installation (Infrastructure-as-a-service platform. Doesn't matter, super niche). When we Googled the problems we had, there were no Stack Overflow answers. 

I remember us trying to translate from Chinese and Russian forums (somehow, the weirder and more niche the tech, the more likely it’ll be only the Chinese or the Russians playing with it).

Usually, when you code, it’s like going to a busy mall. You are doing a thing that was done thousands of times. But sometimes, you get a moment you feel is rare, or even unique, solving a weird combination. Like an explorer.

During my first four years, until I went to a bootcamp, I didn’t know what proper debugging was. I was just printing everything in the console and trying to understand from that.

I remember in my early days, actually in my first four years, I didn't know what proper debugging was. I was printing everything in the console and hoping I could understand that way.

But then I started to work with Visual Studio (not the code version, the classic Visual Studio 2012). I was working with C++, trying to debug multi-level pointers, and figuring out dynamic memory allocation. Step in, over, step over, step it, step out. Uncovering a lost world by dancing with the computer. 

You are sitting on a problem for a while and feel quite stuck. You try the same thing for the fifth time, and you know you need to refresh a bit, so you take a break.

You use it to walk around the office, grab a coffee, talk to people. Get refreshed. 

That one is gone too. It’s not rare to see engineers walking around the office with the laptop in one hand, to not stop the Claude session. It can always do more, run more. One my engineers recently told me: “I feel so much more exhausted, because those break moments are gone. It’s always like: let’s push one more Claude session, just a few more. And even if you wait, it’s just a couple of minutes, and you feel stressed to get back to it. There is always something running”.

Improving your work environment by spending unreasonable amounts of time tweaking configurations, shortcuts, macros, aliases. 

The unreasonable part is taken from us. Now it's completely reasonable because you just need to say what you want to automate. I liked that bit of a guilty feeling of working on an unreasonable task just for yourself.

I used to enjoy teaching the next generation of coders. Sharing wisdom, tricks, and tips you learned the hard way. Feeling like your experience is worth something, and the juniors appreciate getting some of your wisdom. 

Today, nobody asks you, they just talk with Claude. Teaching human to human is almost gone. 

You finish the working day. You have a hard problem, and you're stuck. And then somehow, in the shower, in the toilet, or during the walk (most often the case for me), you have this, "Oh fuck, I know what to do there" moment, and you rush to the computer.

Your brain figured it out. Your brain, purely your brain, without anything else, without any LLM, figured it out. 

Having a monster, a crazy race condition, or a weird, weird bug nobody can reproduce. You grab a teammate, and you stick together, and you're, "we're going to solve that thing no matter what." Like fighting a boss monster together.

You catch one thread. They know something else about the system and connect another dot. You are both excited, and you feel like you're going to nail it. When you reach the solution, it's both of your brains, together.

I liked writing technical designs for complex features. 

Drawing out the boxes, thinking about edge cases, using my brain to come up with a design that the team will implement, that multiple people will work on. It’s a step before writing code - you create the universe where the code will be written.

And right now, it's... Well yeah, you still do that with an LLM, but it’s much less you. I could have spent days, sometimes even weeks on big projects, carefully designing something, being immersed in it, understanding it from A to Z. I miss that.

Going back to the story that opened the article.

A 14-year-old me, needing to create a projectile-launcher mechanic for our arcade game. Our dragon (the character) is running, and a pirate ship needs to shoot cannons at it to land on its path with some randomness. Remember, I don’t know anything about coding, nor physics. 

I had zero idea where to start from, I was close to tears. I felt there was no way I'd be able to solve it. But then I broke it down into very small steps. I succeeded in something, and then in the next thing, and then in the next thing. After a couple of weeks of long evenings, it finally worked. 

That feeling, when something you felt you could not do finally works, is absolutely amazing.

A couple of months ago, Suzan Bond recommended me to read “Transitions: Making Sense of Life's Changes”, by William Bridges (you may remember Suzan from her great guest post The Engineering Manager's role is under attack).

Just finished reading it over the weekend. In the book, Bridges covers the three phases every transition has (in life, in relationships, in careers): The ending, the neutral zone, and the new beginning. All of us in software are currently in the neutral zone, still figuring things out, trying to find our new beginnings. Our old career is dead, and there are new and exciting ones, with many interesting challenges. 

But still, it’s an ending. For yourself, and especially for your engineers, you need to acknowledge that. People are too dismissive, not giving it enough space. For some people it might be more painful, some might be glad it arrived, but all of us feel it.

All of us in software are in that middle now, still figuring things out. Our old career has ended, and I feel like we're rushing forward to say everything's okay, it's cool, we love it, there are so many opportunities. Some of that is true. It is exciting. But we need to acknowledge the ending. Many of our engineers are afraid, worried, scared, and we can't just rush over that.

This article is a light and nostalgic place to say it out loud: there is an ending and there were good parts we can't get back. 

💔