I have a feeling this statement is even more true in the age of AI and coding agents. Sure, today we often write prompts instead of code. But if we’re honest, isn’t that just an extremely fast version of copy-paste?
When people imagine programmers, the picture is usually quite dramatic. In the most optimistic version, it's a handsome hacker sitting in a basement full of computers with Angelina Jolie, breaking into bank systems and secret Pentagon databases.
A slightly less romantic but still impressive image is a developer hammering the keyboard at insane speed while lines of code cascade down the screen like in The Matrix.
And to be fair, when you start learning programming, that vision is not entirely wrong (except of course Angelina Jolie). You actually write a lot of code.
Someone even commented under my article
Your GitHub Contribution Graph Means Absolutely Nothing (And Here's Why)
that the greenest contribution graphs are often from aspiring developers who are simply learning by doing — coding every day, trying things out, experimenting. That’s completely natural.
I often talk with junior and mid developers, and many of them understand the job exactly this way: your role is to deliver features. Ship code. And honestly, there is absolutely nothing wrong with that.
Small personal update: I recently got accepted into the AWS Community Builders program 🎉I hope they give out cool hats and t-shirts 😅 If you feel like supporting me, you can leave a like on my LinkedIn post here.
But What Happens Later?
Something interesting happens as you move further in your career.
The more senior you become — and the more responsibility you have for the system — the less time you actually spend writing code.
Instead, more and more of your time goes into debugging, investigating strange issues, and generally solving problems that nobody else managed to solve.
You can think now: but some seniors still code a lot!
And yes, if you are an experienced developer working in a small startup, you will probably still spend a lot of time writing code. Especially now, when AI tools can accelerate development so much.
But as projects grow and become more successful, their complexity grows as well. And with complexity comes a different kind of work.
Less writing code. More understanding systems. Because when something breaks in production, someone has to investigate it.
Suddenly the support team needs answers. Right now!
Then you spend the whole day analyzing logs.
Oh, there is a race condition somewhere! You're a senior, you need to investigate it.
Is something wrong with our configuration? You need to figure it out!
And of course juniors always will come with the most famous developer question of all:
“Why is this null?”
Wait… Isn’t Programming Also About Architecture?
Now you might say: programming is not just debugging. Developers also need to choose architectures, frameworks, and technology stacks.
That’s absolutely true.
But the longer I work in this industry, the more I realize that in many areas almost everything has already been invented. There are design patterns, well-known architectural approaches, and proven solutions to many classes of problems.
When you design a system, you rarely invent everything from scratch. Instead, you reuse patterns that worked before, adapt architectures that others already tested, and build on the collective knowledge of the developer community.
In that sense, architecture itself is often a kind of copy-paste — just at a much higher level.
Ignoring all that accumulated knowledge would be either genius… or stupidity.
When I Was a Junior
When I was a junior developer, I was shipping feature after feature. I must have written kilometers of code back then. If something didn’t work, I would spend some time researching, trying things, googling errors. If I still couldn’t fix it, I simply went to a senior developer.
And that was it. No matter how annoying and how time-consuming the issue was, the senior had to solve it. That was literally his job.
I remember one situation from that time when the project on my local machine suddenly stopped building. I spent hours trying to figure it out, until a senior checked a few things and calmly said: “Your Node version is wrong.” That was the whole mystery.
Back then I also felt a bit sorry for seniors. They were always on calls, constantly interrupted, rarely writing actual code. Meanwhile I was happily implementing feature after feature. Infrastructure? Pipelines? AWS? I barely even thought about those things.
Today
I’m now a senior developer myself, and I even have to coordinate work across multiple teams. Do I still write code? Of course. But do I deliver huge numbers of new features like I did when I was a junior?
Not really.
Instead, a lot of my work looks like this: upgrading a framework and trying to understand why everything suddenly breaks. Checking whether a dependency update introduced a regression. Investigating strange bugs that appear only in certain environments.
Remember these famous frontend CVE we had recently? The kind that suddenly appears everywhere and triggers a small wave of panic.
Does it affect our project? Fortunately not.
Now the only remaining task is spending a week replying to emails explaining that we don’t even use React 😉
The Real Skill
Writing code can look like copy-paste. Architecture is just a high-level copy-paste. But debugging is pure problem solving.
It forces you to understand the system deeply, follow data flows, analyze logs, and test hypotheses. Sometimes no Stack Overflow answer helps. Sometimes AI tools don’t help either.
You simply need to think.
And after hours of investigation, the root cause often turns out to be something surprisingly small: a missing property, an incorrect configuration, or a single line of code.
Debugging sometimes feels a lot like detective work.
The Responsibility
This reminds me one story.
Remember that senior that had to help me no matter what? Now I'm that senior for my teammates.
Some time ago, a junior developer came to me because, while implementing a complex form, he hadn’t noticed that validation wasn’t working in one place. He had no idea how to fix it and had already been stuck on it for quite a while. Deadlines were approaching.
I tried to guide him, pointing out a few places in the code that might help, but it didn’t work. In the end, I had to sit down and dig into that piece of code myself.
The day before the deadline (I finished at 1 a.m.).
Was it stressful? Maybe. Should he inform me about this issue earlier? Absolutely. But sometimes that's the reality.
So… Am I Unhappy About That?
Do I feel unsatisfied because I don’t ship as many features as I did when I was a junior?
Not at all.
After all — who didn’t want to become a detective as a kid?
Senior developers are basically software detectives. 🕵️♀️
Top comments (13)
I never really felt to be one of those matrix hackers. As a frontend developer, too often dismissed as not doing real programming ("CSS is not a programming language" and JS or P** neither) and I even dare to prefer light mode editor schemes. I stare at browser developer tools more often than at source code. Maybe AI rarlely boosted my productivity 10x. But the code it spat out definitely needs debugging. But that just shifts the time I spent reading documentation, GitHub issues and StackOverflow asnwers to arguing with AI before double-checking official documentation anyway.
I spend a lot of time thinking, researching and planning, but debugging as well. I also adopted maintenance of legacy code not written by myself for several customers. So I'm becoming more and more of what you wrote:
Exactly, that’s pretty much what it looks like after a few years in the industry 🙂
A lot of the job becomes thinking, investigating, reading other people’s code, and figuring out why something behaves the way it does. And honestly, who knows, maybe these are actually the most powerful skills in the age of AI. Generating code is getting easier every year, but understanding systems and fixing what breaks is still very human work.
The only thing I truly can’t understand is the light theme for an IDE 😅
Although… to be fair, one of the best programmers I’ve ever worked with also used a light theme. So who knows, maybe that’s actually a sign of genius. xDDD
This hits different in 2026 with AI everywhere!
I've been thinking about this a lot lately with AI generating so much code, the ability to actually understand what's happening, debug it, and fix it when it breaks is becoming THE superpower. Anyone can generate code now, but not everyone can debug it.
The Matrix analogy is perfect 😂 Though my reality is more staring at console.logs for 2 hours than cool hacker vibes.
Question for you: How do you personally practice/get better at debugging? Would love to hear your approach!
Thank you so much for the comment! I really appreciate it 😊
And honestly… I don’t have any special exercises for debugging. For me it’s mostly just everyday reality at work. Bugs appear, something behaves strangely in production, something breaks after a dependency update — and you simply have to start digging.
Over time you just get used to investigating things: checking logs, tracing the flow, isolating variables, testing hypotheses. I guess debugging is one of those skills that mostly comes from experience and from seeing many different kinds of problems.
So my “training method” is basically: working as a developer every day 😅
Hi, Harsh!
You've described 2026 perfectly! We've built Etiq for this exact reason: AI is generating code, but it's hard to understand it. Etiq generates a lineage to make your code easier to be understood, it recommends testing and verified fixes. We are looking for product testers and we're ready to give free subscriptions. It will make debugging so much easier.
I agree with the core idea, but I think the deeper skill behind debugging is system understanding.
Modern software isn't just code anymore. It's a combination of services, APIs, queues, background workers, cloud infrastructure, authentication layers, and external integrations. Most bugs don't live inside a function — they live between systems.
In my experience, debugging usually means answering questions like:
Why did this request succeed locally but fail in CI?
Why does the queue worker process the message twice?
Why did the email confirmation arrive 40 seconds later?
Why does the WebSocket event fire before the DB transaction commits?
Those problems aren't solved by writing code. They're solved by tracing flows across the entire architecture.
Interestingly, this became very obvious while building a side project recently — a programmable temporary email infrastructure for developers and automation workflows. The code itself wasn't the hardest part. The real challenges were things like:
handling SMTP ingestion correctly
synchronizing inbox updates in real time with WebSockets
dealing with race conditions between email reception and API polling
designing expiration workers that don't delete active inboxes
Most of the work ended up being debugging distributed behavior rather than writing new features.
If anything, AI tools will make the "copy-paste coding" part even easier. But when a production system behaves unexpectedly across multiple services, debugging and architectural reasoning are still very human skills.
That's where senior developers spend most of their time.
Exactly! That’s a great way to put it. Thank you for such a thoughtful and clarifying comment!
I completely agree that the real skill behind debugging is understanding the whole system. Modern software is rarely just a piece of code anymore — it’s a network of services, infrastructure, queues, integrations, and timing issues between them. Many bugs don’t live inside the code, but somewhere between those moving parts.
And you’re absolutely right: the only way to debug those kinds of problems is to understand how the entire system behaves and how data flows through it.
Thanks again for expanding on that idea — this is a really great perspective. 🙂
Yeah I think you have a point - the real #1 core skill seems to be debugging, analyzing issues, troubleshooting, understanding existing systems ...
RE "architecture" - I don't think it's ONLY copy/paste, because you also need to make (reasoned) choices, but in many cases even architecture is rooted in understanding existing systems (especially when there's already heaps of legacy code) ...
Yes, absolutely! I didn’t mean to say architecture is only copy-paste. There are definitely important decisions involved, trade-offs to consider, and a lot of context to understand.
But the longer I work in this industry, the more I notice that when a feature becomes even a little bit complex, the first smart thing to do is usually to look at existing design patterns. Very often someone has already encountered a similar problem and described a solid way to solve it.
And honestly, when I sometimes look at the… very creative inventions some developers come up with, even the thought of checking design patterns first already feels like a sign of wisdom. 😅
Another great article! You are basically exposing our biggest industry secret here. Writing code nowadays is mostly just aggressive copying and pasting, or asking an AI to do the heavy lifting. The real job is spending the next four hours staring at the screen, questioning all your life choices, trying to figure out why that copied code absolutely refuses to work. 😂 Always a pleasure reading your stuff.
I'm afraid you are right, but I'm sad, because I miss the times when I thought my main skill was to craft beautiful code like a true artist, going back and forth between different patterns and chiseling out those variable and function names, until it was near perfection 😅
The satisfaction of finding and fixing a bug just doesn't last as long as the satisfaction from the persuit of perfect code.
I think system design is a more important skill set
That's not a thing anymore with AI rising. I mean obviously you debug, but not in the small scale. Either you go all in with debugging or you don't ever get to.