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...
For further actions, you may consider blocking this person and/or reporting abuse
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
Ohh that's great, please can we connect?
I disagree with this, because right now, at the dawn of the AI era, the opportunity has opened up for a senior (1969 - at least that's what I am according to my age) developer to tackle problems that he didn't dare to tackle before, because his knowledge in the given field was lacking. However, the ideas may have been formulated in him for a long time, and now, as a senior, he knows exactly how to control the agents and what discussions will help him achieve his goal, which if it's a problem that hasn't been addressed before, or hasn't been addressed from that approach, then it could be a program built on completely new foundations.
Just so I don't talk into the air, here are my two most recent challenge submissions:
This one is about a laxy lines fill area calculation problem, realized by rust-wasm
This is a base problem of a modern online vector based drawing appllication, if you search them, you don't found one which is lighweight enough and free. Only the large vector editor have this functionality but that price is high.
dev.to/pengeszikra/rustroke-wasm-m...
Other one is much-much lazy problem: Can I hide a RPG game in a news page?
dev.to/pengeszikra/the-royal-gazet...
But on my real work I also fixing a legacy based EU, ME, EA wide used applications, that work is really software detective works. I found who is the killer ( left the company years ago )
But those two things don’t really exclude each other 🙂
AI can generate code, but you’re still the one managing it — deciding what makes sense, what doesn’t, and where something needs to be improved (sometimes just by writing a better prompt).
And I really liked the part about the “killer” who already left the company. I definitely have a few of those cases in my projects too 😅
The op declaration that the real skill in programming is debugging, ie detective work.
When I read your response, I'm confused by your counter argument so I'm going to debug it.
"I disagree with this, because right now, at the dawn of the AI era, the opportunity has opened up for a senior developer to tackle problems that he didn't dare to tackle before, because his knowledge in the given field was lacking."
at the dawn of ai
Why at the dawn of ai makes any difference? Are you implying you ai is better than experienced coders? Ai doesn't write fashion. It follows orders. All experienced ui developers are better than ai. Ai has not won any prize in any art creation, ever. Ai does not asses ui experience daily or know human interest to know whats next. The same I'd argue for code stability. Its not constantly on call to manage a code base which does a hundred different things simultanuously. Its not managing a business of change.
'his knowledge ... was lacking'
Correction:
His knowledge is lacking
Analysis:
So what. A person still needs to debug, read, interpret, think improvement, respond/apply
'...as a senior, he knows exactly how to control the agents...which if it's a problem that hasn't been addressed before, ...then it could be a program built on completely new foundations.'
I interpret that long statement (debugging) to mean a human coder (senior or otherwise) doesn't need to debug but can write a new solution from scratch using ai tools. That maybe possible (if small code base), but how can they prove their new solution meets all intention of original product.
No code is perfect. No original code has complete regression testing solution that a new approach can test against. Knowledge of systens typically exist with people (a mix of company lifers, and not all stake holders).
Thx your feedback!
The dawn of AI are just means the fact it is a brand new historical times for every one. I don't say AI can compare with a experienced developer.
Nor can you setup your agent to: constantly thinking on a code base which does a hundred different things simultanuously. Also able to Ihelp managing a business of change at least can monitorizing the business need.
Even in the detective works is fit for agents. The big gap is current AI agents fragmented works, and limited context handling capability. When connect AI agent to browser with mcp then able to saw and running a real program, in this case much easier help with debug problem, but the current level is need us, to localise a problem and drive it how can help.
AI is real good to read a debug message.
So I think experienced developer is better than AI, and going even better with a proper AI handling.
You totaly right: AI don't prove their new solution meets all intention of original product.
In my example the lack of knowledge is: I am not a rust developer, but AI solve that gap.
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.
Hahaha, exactly! Especially the part about staring at the screen and questioning all your life choices. 😂
And sometimes it gets even better: you spend an hour investigating why something doesn't work for someone… only to discover they installed the wrong version or forgot to update something. 😅
Oh, the classic 'it works on my machine' trap. Spending half a day deep-diving into the codebase only to find out they never actually updated their environment, or simply forgot to clear their cache, is a very special kind of pain. I think we need to start billing for emotional damage when that happens.😂
amazing
Interesting take. In a way, I think you're right: we probably spend more time tracking down bugs than actually writing code. That may simply reflect how roles evolve—juniors write most of the code, while seniors spend more time stabilizing it.
That said, my experience has been slightly different. I've never really produced huge amounts of code, and I've probably spent more time debugging than I should have—ever since I started back in 1990.
But one thing is certain: finally finding and fixing the bug after hours of searching is incredibly satisfying.
You know, it was actually a bit similar for me. I always wanted to understand everything from the inside, build things myself, and really see how they work — which also meant running into a lot of bugs that I had to solve along the way.
I think that experience really pays off later.
And yes, when you finally figure out why something doesn’t work after hours of searching, the satisfaction is huge. 😅
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. 🙂
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 love your quote:
"...that the greenest contribution graphs are often from aspiring developers who are simply learning by doing — coding every day, trying things out, experimenting."
This is inspiring. I have tried to grapple my mind around why I have not gotten a bonified dev position yet, but also reiterate to myself that I need to take this time to learn absolutely everything I can. That means trying everything, being messy, going on week-long coding benders, and so on. I think I will miss that if it ever goes away.
My attitude has moved from "I am failing" all the way to "I will build an empire one day." LOL -- this is better for my mental health. 😅
I try to check in with myself to see where I stand on the dunning-kruger bell curve to steer void of becoming an imbecile. I would greatly like to believe that I've made it to enlightenment phase. 😂 I think the pit of despair hits you most when you realize how vast this space really is.
Oh yes, I remember those times very well! I remember putting “very good knowledge of JavaScript” on my CV… and then later realizing I actually knew almost nothing about it. 😅
I also spent a lot of time learning and experimenting before getting my first job. But it really paid off — during my interview the recruiter looked very positively at the projects I had built.
The real skill is not debugging, but it's problem solving, it sounds the same, it is not.
Architecture is not really a copy and paste, but it's to choose what's the best approach for a given problem and how does it scale over time.
Thanks for the thoughtful comment!
You’re absolutely right that problem solving is the bigger skill. A great problem solver can be a prime minister running a government or a parent managing the daily logistics of their kids. 🙂 In programming, though, that problem-solving ability most often reveals itself during debugging. That’s where you really have to understand the system and figure out what’s actually going on.
Of course there are other kinds of problem solving too, like discussions with clients or shaping requirements, but that’s slightly outside the part we usually call programming.
And regarding architecture: how do we actually decide what the best approach is and what will scale? Most of the time by looking at what has worked (or failed) before and learning from existing patterns. 😉
Also, the title is of course a bit provocative on purpose, the idea was to spark reflection and discussion like this one. And judging by the fact that I'm currently writing the 100th comment under this post… it seems to be working. 😅
In my work, I'm doing architecture every day. I may be making things out of lego bricks, but the way they go together is what makes the actual project - that is my primary role, if I put the right bricks in the right places I have one hell of a lot less debugging to do
That’s definitely the dream scenario. If the right bricks are placed in the right places from the start, life becomes much easier.
But imagine another scenario: two senior developers start a project with a very tight deadline, so they build things quickly with the promise that they’ll clean it up later. Right after the deadline they get moved to another project and the original one gets paused. A year later two junior developers fresh after a bootcamp are put there “just to do small fixes,” and they do what they can for another year.
Then the project is paused again, and suddenly a senior and two juniors have to deliver two large modules quickly. The project grows, multiple teams join, and rewriting or even introducing something like a strangler pattern is completely impossible because the deadlines are immovable.
At that point… debugging and pure survival instinct are often the only things keeping the system alive. 😅
I kinda see your point, but I think the title feels a bit extreme. Coding itself has never been the point anyways. Nobody pays purely for our code; they pay for problem-solving. If someone can achieve that without writing code, more power to them.
That said, I wouldn’t go as far as calling everything else to "copying and pasting." As a senior engineer in the past, and now as a principal engineer, planning, architecture, code reviews, and proper execution take significant time and effort. Debugging is just a small part of what I do daily - and I do it a lot.
Regarding the idea that "everything has already been invented," there’s some truth to it, but specific business requirements in complex domains still demand careful thought. You can’t just Google those answers, and AI can only help if it fully understands the context, something that’s often impractical, time-consuming, or even restricted by company policies. The context might be so large and complex, you might not even try to explain it to AI, it won't make any difference.
Ultimately, the less time we invest in the design phase, the more we’ll spend debugging later. So building strong design skills remains crucial and arguably even trickier than coding itself, even in the AI era.
But that's just my personal thoughts.
Yes, I completely see your point. I’m actually working on something very similar right now — a huge government application where the documentation alone could probably fill several volumes of books. No context window is going to handle that. 😅
At that scale it often feels less like “programming” and more like architecture and system understanding. And honestly, the first thing I usually think about is which known pattern or architecture we can reuse, maybe adapt a bit — definitely not reinvent the wheel.
In my daily work on a large enterprise system, most of my time still ends up going into different forms of debugging and investigation, while many of the new features are implemented by junior and mid developers (with support of course). The project existed long before I joined and has a very complex history, so even if I wanted to redesign everything perfectly, that was never really an option.
The domain is also extremely complicated with tons of edge cases, so rewriting the whole thing is unrealistic with limited time and resources. We can improve things gradually — a bit like repairing a car while it’s still driving. 😅
And I suspect that’s the reality for a lot of developers working in large systems.
Thanks a lot for the thoughtful comment and for adding another perspective to the discussion!
Interesting perspective. I agree that as systems grow, debugging becomes the real differentiator for experienced developers. Writing code is easier today with AI, templates, and reusable patterns, but understanding why something breaks still requires deep system thinking. In many ways, debugging is where true engineering happens. However, I’d say great programming is a balance - strong architecture reduces future debugging, while debugging builds the intuition that makes better architectural decisions later.
Thanks for the comment! I really like the part about balance. I completely agree with that.
Strong architecture can reduce a lot of future debugging, but debugging also builds the intuition that helps you make better architectural decisions later.
Hey, congratrulation Sylwia :). Great article again!
Thanks a lot, Ben 💖😊
you are welcome :)
This speaks so clearly to my current position at work. Especially the “upgrade framework / check for bugs” line.
I continue to avoid using AI tools because it generates a lot of junior level code i have to spend time cleaning up. Id rather write code myself because i enjoy that part of the job and i get to try out new things ive read about.
That’s actually very interesting about avoiding AI tools.
Most developers I know use them quite a lot now, but I also have a friend who very consistently refuses to use them, and honestly, it hasn’t hurt her career at all. She’s doing perfectly fine without them. 🙂
My experience so far with AI has been mostly negative. Whenever I ask it a question, it outright fabricates and answer leading me down a trail that doesn’t really exist.
The tools are supposedly getting better, but I would prefer not to use a technology that’s boiling the ocean for easy answers.
That “boiling the oceans for easy answers” part is actually a very fair point.
In response to:
"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." <<< Not everything has been invented, I had to come up with a solution to transalte my code, a code refractor/translation tool, that did not exist in the open, so I combined various ideas into one. Not evereything is done yet, there are new fields to explore as technology advances.
Exactly, and I actually love playing with things like that too. Exploring new ideas and combining different concepts can be really fun.
For example, some of my WebGPU demos are in a space that’s still not fully explored yet, and even AI sometimes gets completely confused there. 😅
But unless you’re very lucky, the reality of everyday work is usually much less romantic. Most of the time we’re working inside large existing systems rather than inventing entirely new ones.
Wow, that sounds interesting, WebGPU demos, do you have a link? Besides programming, I did my masters in Desing/Multimedia, so you've tickled my curiosity.
Hahaha sure! I even wrote article about it: dev.to/sylwia-lask/why-webgpu-feel...
And I'm preparing some cool article for next week: WebGPU vs JS benchmarks. What can I say, it's totally exciting technology! (spoiler: WebGPU SMASHES JS in many cases)
I always go on about the 80/20 approach for tasks (though the exact ratio is of course relative to the complexity of the task): 80% of your time should be dedicated to thinking about how to approach the problem, what architecture/mechanics should you use, what the edge cases are, what are the ramifications, how can you ensure maximal coverage with your test cases, etc. Actually implementing it should then be relatively straightforward, especially these days with LLMs. Of course as you mentioned, the more tenured you get, the less time your job is about tasks, and the more it's about refactoring, abstracting, bug-fixing, detective-ing.
Also on LLMs, I too tend not to use them to generate solutions. From time to time, I like to see how it would approach a difficult problem just to compare ideas, if the problem is well-contained (it's been useful a handful of times), but mostly I use Google's LLM search as a contextual Stack Overflow to save time/memory: I have to first understand precisely what I want to code, then copy-paste-adjust.
I've always found it interesting when I see engineers actually type out lines of code, code blocks --- even variable names --- that are identical to existing patterns already in the file. But then my left hand is a magnet to fn-C/V 😆
I enjoyed reading that, thanks!
Thank you very much for the comment! It really expands on the idea from the article beautifully.
I have a very similar approach — for me LLMs shouldn’t write and work instead of us, but rather help us think and move faster when we already understand the problem.
In the best case it becomes a kind of collaboration: human + machine. 🙂
Debugging is what happens when engineering thinking failed upstream. Elevating it to THE skill is like saying surgery is the most important skill in medicine — but it means prevention didn't work.
The distinction that matters is between code (notation), algorithm (intellectual content), and engineering (failure mode thinking). Debugging lives inside engineering, but it's the reactive end of it. The proactive end — asking "under what conditions does this break, and who gets paged?" before writing a line — is what actually separates senior developers from the rest.
There's also a practical fix that the industry almost universally ignores: log intent, not just result. Most systems log what happened. Almost none log why it was attempted. When something fails, you know the what — you're blind to the why. A single line stating what the code was trying to do collapses hours of investigation into minutes. If developers made that one habit universal, most debugging would become almost trivial.
The developers who are best at debugging tend to be the ones who write systems that need the least of it. That's not a coincidence.
Thanks for this comment — it adds a lot to the discussion.
I completely see your point. If you are building a system from scratch and later it becomes hard to maintain, then yes, you can absolutely question the architecture and earlier engineering decisions.
But how many people in our industry really have that luxury? Most developers work on legacy systems that were built long before they joined the project, often under heavy time pressure. In those situations we can mostly try to minimize the damage and improve things gradually — rewriting the system or even introducing something like a strangler pattern is often more of a dream than a realistic option.
That’s the reality for many (maybe most) of us.
And the part about logging intent instead of just results is brilliant. I really like that idea. 👌
I fully agree that debugging is a skill.
It's just a skill we need to move away from needing! :-D
Hahaha sounds totally like principal's engineer mindset :)
Debugging is definitely a core skill, but calling everything else copy-paste oversimplifies the job. Writing reliable software also means making design decisions, understanding trade-offs, and preventing bugs before they happen.
Fair point 🙂 Of course it's a bit of an oversimplification — titles tend to be a little provocative by design.
I completely agree that writing reliable software is about design decisions, trade-offs, and preventing problems before they appear. But in practice I often feel that debugging is the moment when all those decisions get… stress-tested in reality. 😅
This resonates so much. I remember those junior days of just shipping features non-stop. Now, a 'productive' day often means I wrote zero lines of new code but finally found that one configuration typo that was crashing the pipeline. It’s less glamorous than The Matrix, but much more satisfying
Exactly! Let's leave shipping features for juniors and do something they can't (yet) 😁
hi
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.
Yes, exactly! Writing beautiful code can really feel like a form of art.
The worst moment is when you’ve crafted some truly elegant piece of code… and then a new requirement comes in and you realize you have to delete the most beautiful parts because the business actually doesn’t need them anymore. 😅
Depends how long that bug has been haunting you ;)
one thing I don't agree with is that architecture is not a copy and paste. It is a soul of your whole coding project. A proper architectural can help to save your time debug while on the flip side it just make your debugging hard and impossible
But what if the architecture was created long before you joined the project?
then you might review that architecture to understand why it designed in such way, right! It might not be right, but it will be a good start. If it is bad, then copy and paste simply just brought the bad design over, which made your debug a nightmare
The Node version story cracked me up — been there so many times. Spent 3 hours last month debugging a failing build that turned out to be a mismatch between the Node version in our CI pipeline and what everyone had locally. We ended up adding an
.nvmrcfile and a preinstall check script, and honestly that saved us more headaches than any fancy debugging tool.One thing I'd add to the "debugging as detective work" angle: I've found that the best debuggers I've worked with aren't necessarily the smartest coders, but the ones who are really methodical about narrowing things down. Like, binary search your way through the problem — comment out half the system, see if it still breaks, repeat. Boring but effective.
Curious though — do you find that debugging distributed systems (microservices, event-driven stuff) requires a fundamentally different mindset than debugging monoliths? In my experience it's almost a different job entirely.
That’s a really good point. I also agree that the most effective debuggers are often the methodical ones, not necessarily the people who write the fanciest code.
And yes, I do think debugging distributed systems requires a somewhat different mindset. In a monolith, you can often trace the flow more directly. In distributed systems, a lot of the bugs seem to live “between” services: timing issues, retries, queues, missing events, inconsistent state, things happening in the wrong order...
So maybe it’s not a completely different job, but it definitely feels like a more advanced form of detective work. 😅
It's interesting to see how different people debug. With a proper IDE and knowing how to use the debugger, you can get to the root cause far faster than someone using console.log(). Always fun watching a senior engineer log out errors rather than using the tools available to them.
Intriguing! Do you have some interesting, efficient ways of debugging?
This is a really great article that explains many things step by step. Sometimes I feel like no one else faces the same challenges as me or works late at night like I do around 1 or 2 AM, but it’s inspiring to see that you’ve experienced the same. The developer journey is kind of a magical world—sometimes we feel a lot of stress, especially when deadlines are getting close.
Yes, exactly — unfortunately it’s sometimes unavoidable in this kind of work.
I actually try to avoid it as much as possible, and I even consciously chose a job where working late like that isn’t the norm anymore (in a startup I worked at before, it happened all the time). But from time to time situations like this still appear, especially when deadlines get close.
honestly the "why is this null?" part hit me hard lol. i swear 80% of my debugging sessions start with that exact question.
the point about architecture being copy-paste at a higher level is so true tho. like yeah we pick patterns and frameworks that already exist, but when something breaks in production at 2am nobody cares what architecture you chose — they care if you can trace through logs and figure out why the websocket connection keeps dropping or why that one edge case slips through validation.
i think the AI angle makes this even more relevant now. copilot can write code but it can't debug your specific system with its specific quirks. that's still very much a human thing.
Beautifully summarized — especially the 2am production debugging part. 😅
honestly this is hitting even harder now with AI coding assistants everywhere. I've been using Claude/Cursor for a lot of the "writing" part and it's genuinely great for scaffolding stuff fast. but the second something breaks in a weird way? you're back to being a detective.
the part about architecture being "copy-paste at a higher level" is a take I didn't expect to agree with but... yeah. most of what we call architecture decisions are just patterns someone figured out before us. the actual hard part is when the pattern doesn't fit and you need to figure out why things blow up.
I think the real gap is going to be between devs who can read a stack trace and actually reason about what went wrong vs devs who just paste the error into ChatGPT and hope for the best lol
Exactly, that’s a great way to put it. And honestly, I think this is where developers who started coding before AI might have a bit of an advantage. We spent years reading stack traces, digging through logs, and trying to understand what actually went wrong instead of just pasting the error somewhere and hoping for a quick answer.
earlier I thought programming was mostly about writing lots of code. Now it feels like most of the job is reading logs, tracing data flows, and figuring out why something behaves differently in production than it did locally.
Yes, exactly, that’s very often what it looks like in practice. 😅
And sometimes the bug disappears when u start debugging it
Hahahaha totally, than I said it was just affraid of senior dev 🤣
I absolutely agree.
I'm realising more and more, that ai defenders are not good coders.
Good coders need to debug what AI can't when the context of large code base exceeds its capacity. Even 1 complex problem it has solved becomes a challenge for it not to hallicinate when combined with another complex problem. All good architecture is cleverly integrated with multiple, integrated complexity.
Also, if the codebase is small enough that ai can be used to resolve it, you don't have a competitive business because everyone else is doing it.
I value AI for learning, interpreting, breaking something down, but the real meat of coding is as you say - debugging, detective work.
Totally agree. In my main project the codebase and domain are so complex that I’m pretty sure an AI would submit its resignation after the first week.😅
“Absolutely resonates! Debugging really separates good developers from great ones. Writing code may be easy, but understanding why it fails—and finding the root cause—truly sharpens your problem-solving skills. Senior devs are like real-life detectives of software mysteries!”
Exactly — software detectives is a pretty accurate description. 😅
While copy-pasting code or using existing resources can definitely speed up development, the real challenge in programming often comes during debugging. Writing code is just one part of the process, but understanding why something doesn’t work and finding the root cause requires deeper problem-solving skills. Debugging helps developers learn how systems behave, improve their logic, and write better code over time. In many cases, even experienced developers spend a significant portion of their time identifying and fixing issues rather than just writing new code. So while reusable code and documentation are helpful tools, strong debugging skills are what truly make a programmer more effective and reliable
Totally agree — that’s a beautiful summary and expansion of the idea from the article. Thanks for adding that perspective! 🙂
Sadly that’s the reality of “growing” in the industry. As someone who loves coding and solving problems.l, as you get further in your career (I’ve been doing it 13 years now) your salary goes up but hands on diminishes. It’s such a shame the skillet you’ve honed and perfected is no longer seen relevant.
Do you sometimes have that feeling though, that when there’s a very simple task or component, you think “oh well, that’s probably something for a junior”? I catch myself thinking like that sometimes. 😅
As someone thats a low level programmer, and "been around" for a bit. I can say, debugging is 75% of what you do as a programmer. An example, you've gotta adapt a 10 to 15 year old code base to modern standards.
IT security was lax as shit. Memory safety wasn't a thing back then. Buffer overflows were the least of your problems. Tech advanced so fast, we are only now catching, even if just barely.
That sounds very familiar. Updating old codebases often turns into a huge debugging and investigation exercise.
You’re not just adding features — you’re trying to understand decisions that were made 10 or 15 years ago, often in a completely different technological reality. 😅
I became a developer because I imagined being a handsome hacker in a basement full of computers, breaking into bank systems and secret Pentagon databases with Angelina Jolie.
Instead, I debug NullReferenceExceptions and review AI-generated code. Reality hits hard. 😄
Hahaha, this might be my top comment under the article. 😄 And yes… life really tricked us there. 😅
The detective analogy is spot on. Writing code is often the easy part now, especially with AI tools. The real challenge is understanding why something breaks in a complex system and tracing it back to the root cause. Debugging really forces you to understand how everything actually works together.
Exactly — that’s the part where you really have to understand how the whole system works together. Debugging is often the moment when all those hidden assumptions in the system suddenly come to light.
Love this!!! ❤️❤️Debugging is what started me on this journey, and the problem-solving it requires is still one of my favorite parts of the industry. What I find most interesting is how transferable those skills are.
Forcing people to understand things at a deeper level is something I consider a core competency. I relate it to being old enough to survive the analog->digital revolution. I was forced to understand how the technology worked and it has paid me dividends since.
Totally agree, I know exactly what you mean.
Maybe I’m not feel old yet, but life forced me to learn computers quite early, around the age of 10. I still remember formatting the system from DOS and using floppy disks. 😅
This is what I actually aspire one day. I genuinely love solving problems and been curious since I was a little kid. I guess I have to push features and build multiple projects to actually get that highly valued debugging skills. Great read!
Yes, that’s pretty much how it works. At the beginning you mostly solve problems that appear while building features — and that’s exactly how those debugging skills start to grow. 🙂
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. 😅
Yeah, except debugging AI code's a whole other beast. You get something that works but you have no idea why, so the second it fails in production you're completely lost. Can't debug what you don't understand.
Oh, that really feels like my yesterday!
A process was failing for some but not all cases. The logs said said the fails were because the member wasn't found, despite the prior log clearly showing the member had been found.
I had a hunch, and many records to manually inspect to verify it.
The data was corrupt, and the error type highly misleading. Urgh.
We now have a new error type, along with a log telling me exactly which record is faulty, a comment in the code explaining the per-case fix, and a ticket to follow up on my theory about why the data broke in the first place.
No new features, but a huge sense of satisfaction from having solved the problem and served my client well in a way I know I would not have been able to do five years ago.
Yes, I know that feeling very well. At first you question all your life choices… and then when you finally solve it, there’s this strange kind of satisfaction. 😅
But this time no longer starting a fresh code
You just edit people work and AI code
If you junior or senior program is the same thing is going on there
That’s true — a lot of the job is editing existing code.
The only difference is that seniors are usually the ones people call when nobody understands why that existing code stopped working. 😅
"reverse engineering" lies at so much of the core of effective software engineering
Totally agree, especially in legacy projects. 😅
With the volume of code being AI generated now, I feel that the debugging skill is more important than ever.
100% Agree!!
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.
Interesting point — I think I see what you mean.
With AI generating more code, debugging often moves from small code-level issues to bigger system-level problems. In that sense it becomes even more about understanding the whole system rather than fixing a single line.
So maybe debugging is actually becoming more important, not less.
I think system design is a more important skill set
That's a great point! System design is definitely a huge skill.
In my experience the two are very connected. The better you understand the system design, the easier it is to debug when something breaks.
So maybe debugging is just system design coming back to check our homework. 😅
Yes, I agree; if you are unable to debug, you are hopeless. :D
Exactly, without that skill it’s really hard to be an effective developer. 😅
love this article!
Niceee
Hey 👋 everyone here please I'm new here and I don't really know anything about coding. And it'll be so glad to ne if I can find someone that'll take me aloobg
Very helpful
hello
yap this day's with AI the sad truth
This is a fantastic overview of AI-assisted coding. It’s something every CS student should learn early in their academic journey.
Thank you, I’m glad you found it useful! 🙂
the copy-paste comparison doesn't track tho. you at least understood what you grabbed from SO. now I'm debugging black boxes that mysteriously work—that's way harder when they break
Hahaha, a little bit, yes. But sometimes when I read code written by interns long before I joined the project, I feel even worse than when debugging AI-generated code. 😅
This is more or less what I imagined. Thanks for sharing this sneak peeks into the industry. I believe I am somewhere close to junior level and modestly good at debugging.
At the junior level in your time, have you ever wondered how to share what you knew, say about debugging? Is it like through projects and sharing your growth and challenges on socials?
So i have to just understand concept copy code and debugg.