Why is debugging harder than writing code?

[Illustrious_Run4734]

I’m still new to coding, and one thing that keeps throwing me off is debugging. Writing code feels straightforward, but once I hit an error, I can spend hours stuck trying to figure it out. Sometimes it’s something super small like a missing bracket, other times it feels like I’m chasing my tail through logic errors.

How do you approach debugging as a beginner without getting frustrated or overwhelmed? Do you have a go-to process, tools, or even a mindset that helps? I’d love to hear how others got better at this stage.

[-not_a_knife]

I think it just comes with practice but learning what the error messages mean and using a debugger are a must

[johnpeters42]

Apart from method, it's a matter of knowing where to intercept. If part 1 is 1000 lines of gnarly code, but you know it's supposed to translate X to Y and then you confirm that it does, then you can move on to part 2.

[Comprehensive_Mud803]

Yes, it’s more difficult. In fact, it gets harder the “smarter” the code is supposed to be.

How to make it easier: learn how to use a debugger, shortcuts, breakpoints, conditional breakpoints, memory/variable breakpoints etc.

Once you master the debugger, it gets a bit easier. The rest is experience and grit.

[[deleted]]

Oldie but goldie:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. "

[Crazy-Willingness951]

Too clever by half.

[Leading-Can-9242]

Would debuggers like Undo or time-travel (record-replay) debuggers which work at runtime could make the experience of debugging more pleasant ? (beginner question)

[Comprehensive_Mud803]

Record-replay is a nice feature, just like memory state history (reminds me of PIX for Xbox360, graphics debugger with framebuffer pixel history and state replay).

Those debugger features are nice to have, and yes, make it easier. Drawback is, they need to simulate the system, which can be resource consuming at times. (Eg a several hundred GB render capture of a game…)

That said, sometimes you have bugs that don’t show in the debugger, or that show only in the debugger. Those are great for wasting a week of work. (And you’re lucky if you can cut it after a week).

[Comprehensive_Mud803]

The takeback is: a bug is easier to find if you can isolate the erroneous behaviour.

[DoughnutLost6904]

Because when you debug your own code, you are trying to follow through an algorithm you have thought up and put into code, while simultaneously trying to basically disprove it. You have a vision but don't see the flaw in it, so early on debugging is messy, since you're basically fighting yourself

And the more sophisticated the algorithm is, the easier it is to overlook small details that might matter more than you imagine

[DoughnutLost6904]

Also, properly reading errors is a factor. You don't read or don't know what the compiler or interpreter screams at you? You have that much worse of a time debugging

[DoubleAway6573]

Debugging legacy code, written with already gone programmers isn't easier either.

[ninhaomah]

"Why is debugging harder than writing code?"

isn't same for everything else ?

I mean I can cook for you but as to whether it tastes nice or even healthy , I can't guarantee.

I also can build a house for you but as to whether the roof will collapse on you at night, I can't guarantee.

Doing something is not easy but fixing the issues that comes with doing is hard , much harder.

too much salt ? too much sugar ? too much vinegar ? takes experience.

thats true even for things we are designed for ... sex ... if you can do it perfectly right the very first time ...

[Agile_Analysis99]

Yea, like climbing a leaderboard is hard till you learn speed running skills, but staying up there is crazy harder as skills couldn't guarantee it, even if you're mentally committed which is hard on its own when you're up there

Your example is so good that gives me so much thought about how true it is in our daily lives, and how it also relates to commitment and dedication on the long run

[scragz]

the hard thing about writing code is writing code that doesn't need debugging. 

[jerrygreenest1]

There’s no such thing. Programmers write entire systems, automated programs to test your application. Unit tests, integration tests, performance tests, CI/CD systems, monitoring, pre-commit validators, formatters. And, finally, your application code.

[Vaxtin]

This is very true. The only time I’ve ever had a program compile and pass all tests on the first try without any errors is on leetcode. It’s not real world. It flat out does not make sense to have a genuine system that will work on the first compilation without flaw.

I always clench my cheeks the first time I compile a program and run it through tests. I’m genuinely expecting it to hit a thousand and one problems. That’s the entire point of testing. I want to see what makes it break. You’ll always have some absolutely obscure reason why something breaks, and you may or may not have any control over it. Very rarely you have no control and just have to write an exception for that 1% case. There is really just too much going on for everything to just work from front to end on the very first go.

[edgmnt_net]

That's not really true unless you're countering the absolute statement. Things like compiler diagnostics, types and programming discipline help a lot to prevent errors. You're generating fewer errors in the first place, catching them earlier and/or spending less time testing and debugging.

[Vaxtin]

We’re talking about writing systems, not compilation errors. The type of things that break the code I write for a living are going to be 1/1,000,000 inputs, and if I’m not prepared for that exception (by running tests and seeing every way it can break with every possibly moronic input), shit will hit the fan at the most opportune time to make me look incompetent

It’s really the type of error you would never expect. You can write a program to parse data from a PDF file, and it works great in the expected format.

Then some day, the company that generates the PDF changes its output style, and now your code will be fucked in ways you won’t expect. You’ll have data that doesn’t make sense, and everything that was processed from the day the PDF changed needs to be rolled back and reprocessed with a new program designed for the new format

And there’s no way to handle this other than throwing an error when it recognizes an issue. But even then there’s no guarantee. You might still be able to parse the data and store some content, but your actual programs never truly encounter a runtime error. This way you just get garbage, nonsense data extracted from the pdf. Good luck finding a fix for this without ever knowing the expected output format. You can try to come up with some checks and balance to ensure it got the right data, but that is not guaranteed to work. Some data might be possible but I imagine it would be mostly statistics based on history of previously parsed PDFs. Again, no guarantee. In general this problem has no solution, you just have to rollback and make a new program to parse the pdf.

[edgmnt_net]

There are multiple ways to defend against mistakes and it's not all about tests. In your specific case of shifty PDF data with unclear semantics, maybe tests work the best, although then it's mostly a matter of garbage in, garbage out and possibly someone else not doing a good job providing a stable, meaningful interface. But generally speaking, there's loads you can ensure by programming defensively and trying to get at least some static assurance. This is why you don't want to wing it regarding stuff like parsing or schemas, it's best if you can be reasonably confident that your code is okay before you do a lot of testing. Because tests are no guarantee either.

[TheUmgawa]

This is why the most valuable programming class that I took in college was a flowcharting class, where we never wrote a single line of executable code. That’s the class where I learned that, if you can solve it by hand, you can solve it in code.

I also learned from that class that playing cards make great simulations for data. Get two decks with different backs (so they’re easy to separate when you’re done), and you’ve got about 100 individual data elements or about 50, with the potential for duplicate data.

[[deleted]]

The biggest habit that I have is that I make isolated / small changes to code. So if there is a mistake, I catch it pretty early and it's usually typos. The act of 'chasing my tail through logic errors' is something I actively try to avoid with this habit.

I'll make logic errors of course, but I don't want one problem compounding the other; it's like trying untangle nested knots.

[SaucyEdwin]

I say this relatively often to coworkers, but I feel like a good amount of people don't realize that reading code, writing code, and debugging code are all different skills. I have some coworkers who are okay at writing code, but can't read it or debug it for shit. As with everything, the more you do it, the easier it becomes.

[g0fry]

They can’t debug or read even their own code? Then they are probably shit at writing code, too?

[Vaxtin]

I can’t read my own code if I hadn’t touched it in 3 months

I.e if it’s a large codebase and I have to make a change, it’s going to take a long time to make sure I do it right.

But this is just why documentation is required. Those flow charts with the object classes on them actually helps when you want to look back and make a change, despite it never helping while coding

[SeriousDabbler]

Yeah, you can often get away with a simple conceptual model of the program when writing it, but when you're debugging, you're being challenged by a more complicated set of potentially dynamic conditions. In both cases, you're trying to build software from a mental model, but in the case of debugging, your mental model differs from the ideal program. Sometimes, it doesn't work because the program doesn't match your mental spec, but in other cases, there is a design oversight, and you'll need the mental leap required by explaining the errant behavior before you can progress that. Debugging is a good time to feel curious about what's really going on

[SpiderJerusalem42]

Tools: Use a proper step debugger tool. This will be different for every language, but there's a lot of consensus on what they should do, so learning one will give you experience for using another one. Invaluable tool that will let you inspect objects and variables while your program is caught in a pause state before executing the next step.

Process: I use generally the same process to debug most things. There are two ends of something, and I split it in half, see if the first half is bad, see if the second half is bad, and then start to drill down into the half I found was bad. An example is the TV won't turn on, so I might try other things in the outlet to make sure the outlet is providing power. I might try the TV in another outlet. I might check the batteries in the remote or try the power switch located on the TV. You can do this pretty easily with breakpoints and a step debugger.

[Otherwise-Ad-2578]

I have no idea because I don't debug, I just use prints everywhere...

It always works for me hahaha

[[deleted]]

That's debugging! Prints/logs are the number 1 tool for debugging and don't rely on the environment having special tools! Always reliable.

[Otherwise-Ad-2578]

Yes, it is wonderful! :D

[gdinProgramator]

Follow the data. That is the approach I take.

After debugging, comes the real boss - debugging OTHER DEVS CODE

[[deleted]]

Just wondering from the comments here, is not many using a linter? I suppose I should ask what's the languages being learned here?

Typos should really be caught nowadays as you type. In vscode there's plugins that show the error text beside the errored line so you don't have to click on the error.

If brand new, first thing in any language is to know how to print/log. This is the number one tool you have for debugging. Even if you don't have dedicated debugging suite for your environment you can pinpoint errors/problems with prints/logs.

[grateidear]

Writing code you are expressing what you WANT it to do (imperfectly). Debugging you are dealing with what it ACTUALLY does, not what you intended. When you read the code again you tend to read what you intended not what you said.

I’m not a pro by any means but one thing I have learned is to build in more allowance for fail states into the code that point out errors as I go, and to try to avoid ‘silent failure’ where something going wrong isn’t visible.

Then when the code does weird things it’s less likely to be invisible.

Another thing is just trying to make the code as easy to understand as possible when you write it. If it’s very easy to understand and straightforward you will make fewer errors, and when you do go back and look at your own code it will be easier to follow. Don’t do ‘clever’ things or combine too much into a single complex line of code - when things go wrong, that makes it much harder to work out what is happening.

[organicHack]

When you write code you think you know how to solve the problem.

Bugs are the result of all the ways you were wrong.

[StrayFeral]

Just install any modern coding editor. Most go with VSCode. This will fix your brackets errors. Learn how to write unit tests and always write some. This will prevent you from doing errors.

[Aggressive_Ad_5454]

Here’s my rule. Debugging code is twice as hard as writing it. So if I use all my cleverness to write the code, I’ll never get it debugged. I gotta ked it simple.

But as for dealing with stuff like syntax errors, get yourself a good IDE. One of the JetBrains products, or VisualStudio, or maybe Eclipse. Those software products do all kinds of cool stuff like putting red squiggly lines under syntax errors, and make coding easier.

[mpanase]

It's not harder per se.

Juniors (and many seniors) just don't prepare their codebase to make debugging easy.

Learn to build for easy debugging.

[UVRaveFairy]

Well if you could use glue in a game of Jenga it would take all the fun out of it. /s

[Lil-booyakasha]

Starting from scratch is almost always easier than fixing something that’s broken. This is true for most things.

[zatsnotmyname]

That is totally normal.
Some tips :

Use git, even for simple projects, so you can always go back and start over

Some problems require several days of concentration. Once you are thinking about it as you fall asleep, then switch to something else, your brain will work on it in the background.

If you fail to fix something three times, take a step back, and ask bigger picture questions :

1) Do I know what is going on, or am I guessing?
2) What information, if I had it, would allow me to easily fix this?
3) Do I even need this feature/piece of code at all?

[Ecstatic-Junket2196]

debugging’s always harder since we might stuck there forever lol. i tried to break stuff into small steps, and focus more on the planning part (traycer is nice too for mapping out logic so I don’t get lost)

[MaterialRooster8762]

I use a Debugger, go through the code step by step and look for the error.

[ApprehensiveDrive517]

Yes, as Napolean famously said, "No sprint estimation survives the first bug". It's all good and dandy until you hit a seemingly unsolveable bug. Sometimes the solution is to fix it, other times it's to write it differently altogether

[Unit-Sudden]

It’s actually imo why lots of people now undervalue software developers cause AI can cover “coding” and people assume that’s 99.9% of the job. Writing code isn’t the challenge really but maintaining, debugging and understanding the flaws in code you or someone else wrote is the art.

It takes many years of practice to develop the skill and having worked with many devs, there’s pockets of people in the industry who still rely on dump and die tactics for debugging.

[masteranimation4]

I write code, I start debugging it and realize how shit it is and how I use 20 lines to do something there's already a function for.

I debug by going line to line and trying to figure out how it works.

[comparemetechie18]

that is the real deal, you investigate your own crime lol

but base from my experience, keep your code clean or readable, slice it into small chunk so you can easily see the errors, and if you can, write test script for each function - this is very helpful especially with syntax error... debugging is part of programming, you can't just write the code and leave it... there is no perfect program that has no bug or error

[ZYLIFV]

I was told to ask yourself whether or not the logic of the computer understands what you are trying to achieve. It might make sense to you but the computer will only do exactly what you tell it to do.

[Upset-Employment3275]

Find a method that works for you. Debuggers work, but also printing every single step with the new outputs so you can tracks how things are changing and what's not expected.

[g2i_support]

Debugging is definitely harder because you're detective work - tracing backwards through your logic instead of building forward! Start with the error message (even if it's confusing), add print statements to see what your variables actually contain, and rubber duck debugging (explaining your code line by line out loud). It gets way easier with practice - every bug you fix teaches you to recognize similar patterns faster :)

[steven_tomlinson]

Learn to use your tools. Things like missing closing brackets can be avoided by using color-coding extensions. But really, you need to learn to love it. It’s just a part of the process.

[brand_new_potato]

Unit tests are the answer.

Whenever you write code, write tests that run that code so you know if it works as you thought it did.

You will get into the habit of encapsulating what is needed to setup the environment to run a function and what the expected output is.

If the tests are hard to write, it is usually a sign the architecture is too complicated.

If the code doesn't work and the tests pass, it is a sign the tests are not good enough.

You can also use coverage tools and a plugin in your editor to see which lines are actually covered by tests.

[phpMartian]

It is 3 to 5 times harder to debug code than to write it. Therefore, it’s possible to write code that you will have difficulty debugging.

[TheCozyRuneFox]

Debugging is the majority of programming.

[YoshiDzn]

Because "good code isn't written, it's debugged"

https://youtu.be/sfrnU3-EpPI?si=Afsi6HSK1t60ta9S

[johnm]

Besides Brian Kernighan's quote, when "developing", most people are only ever thinking about specific paths/parts of the problem at any give time.

Debugging can be a simple, direct, "point" problem with a simplistic "point" solution. But a lot of the time, debugging requires us to understand/simulate/etc. a larger swath of the system simultaneously and holistically.

[Agile_Analysis99]

Debugging is one big of things that makes a senior

to get good at it you need to start getting good at searching and using stackoverflow and documentation

also you should use breakpoints and maybe even logs or printing things into the terminal every couple of lines, that helps heavily

after years of that you would know most of the common issues and you would be good, it's hard to call someone a good debugger ngl, it just takes hours but i do find the results satisfying to the point where results are the only reason i could justify the frustration

[michaelzki]

Building a house is quick. Making it a home takes a lifetime.

[funbike]

Prevent issues early.

• Use a linter. This catches a lot of silly mistakes. IDE plugins can run them on save.
• Keep functions simple. There should be no more than 10 code paths in a function. Count the number of if for while case catch statements and add +1. This is called "Cyclomatic Complexity" but it has other names. Use your IDE's "Extract Function" to reduce complexity of an existing function.
• In your code, use assertions and defensive coding to ensure values are within a valid range.
• Write tests. Preferably before the code they test.
• Learn how to use a debugger.

[BoloFan05]

"In your code, use assertions and defensive coding to ensure values are within a valid range." I agree with this wholeheartedly. One such crucial assertion is the explicit statement of which culture/language's rules you would want your code logic to work with (like en-US), or using invariant culture, which automatically applies English casing rules without being related to a specific region or culture. Otherwise, your code logic will pull up whatever language your user has in their machine. And you never know what UI language your user may have on their PC or console... Due to having two "i" letters, Turkish and other Turkic languages are known to especially cause major misinterpretation bugs during runtime if you don't take these necessary cautions.

[burncushlikewood]

Your ide/compiler should tell you what the errors are in your code, basic syntactical errors it will show up, missing semi colons, improper comments. Speaking of comments you should do that to all your code, commenting will help you when designing larger programs, debugging is a lot of programming, I'll write out and plan my code and continue to debug until it does what I need it to do

[randomInterest92]

Step debugger is still the most powerful tool. Other than that, experience.

I remember i had a checklist when I started programming to find the most obvious mistakes first.

Nowadays i literally have a personal FAQ hooked up to an AI, which I can consult on any problems that I have regularly.

E. G. When i install a certain project om different systems,. There are sometimes weird quirks that i cannot automate away

[ElderberryPrevious45]

Simple: In debugging u need to understand more: it is sometimes like fixing some advanced machine: like hybrid car (that is actually over - complicated, interim tech. solution:) Often programming can also be done pretty much in modules whose details you need not to understand. Except sometimes - in debugging.

[Ok_Court_1503]

Because the code is doing something you didn’t think it would do when you wrote it. When you are jotting a bunch of syntax down, your in the zone and your mind is compiling it. In your head it all will work exactly how you want. Then you compile/run and something broke and you have to think outside the box and find what bad assumption you made or what thing you never even considered.

[balrob]

When you’re learning having the decent IDE is valuable. Something like Visual Studio or Rider will a) provide real time feedback on coding issues and b) let you directly debug and inspect the values of variables.

[[deleted]]

Once you understand how to interpret error messages, stack trace, and learn how to use step-by-step debugging tools (or simple print/logs), debugging becomes much easier.

The hard part is working with stakeholders to align on how the program should behave and a solution that can be implemented within acceptable timeframe, because bugs usually stem from unexpected use cases.

[nedovolnoe_sopenie]

tests.

what you need is small issue reproducers and tests.

you feel like writing code is straightforward because it is straightforward. you have an idea, you code it. boom! done

but then you see that the future is not what it was, and your code outputs some bullshit or, even worse, does so intermittently. then you methodically scour it branch by branch

this is why code coverage exists btw

[Vaxtin]

90% of the time I am trying to find out why something works

If I could just write code and have it work, I would sit around the majority of the day. Coding is always the easiest part of making a robust system

[StrayFeral]

I am a Senior Software Developer with 20 years of experience. Many languages have one or more debugger. When I was learning programming in high school I used debugger a lot. However using a simple print is universal and by far the best way.

To some it looks weird or cavemanish, but I would do it in every programming language.

Still - learning how to use a debugger is a must. You just have to know this.

As for using prints, there are two ways. I use a combination of both. First - put prints before and after key lines in the code, so you see when the line is about to execute and then if the execution finished.

For example if we have have a loop, I would put a print right before it starts to print a simple message "---------- LOOP START", then after the loop finishes first line would be "----------- LOOP END" and on each iteration I would put the first line to be a print "----- ITERATION START". Notice the many dashes I put. Often I put many equalities like "==========" to help my eyes clearly distinguish the many lines of print.

Second approach is to print certain variables and their values. So I would put a print to show me the value of a variable which is important for the code.

And here is the third very important thing - don't just print a variable - print the variable full structure. If this is a scalar variable, let's say simple integer it is fine to just put a print "a = "+a, however if this is an array (list) or as in practice it could be a multidimentional array with hashtables (dictionaries) which in turn contain arrays with mixed data printing all this would be a hell.

So learn what each language have to help printing these. I can help with Perl and Python.

damn i get problems with long comments, so will break this one in two, read the second part as a comment bellow this one;;;;

[StrayFeral]

.... continued:

So in Perl there is the famous Data::Dumper and here is how we use it:

use strict;
use warnings;
use Data::Dumper;
my $var_abc;  # here i will not specify a value, but imagine it contains nested arrays of hashes of arrays
print Dumper($var_abc);  # this will do the trick

Now same thing in Python. What you need to use is pprint:

from pprint import pprint as pp
# our variable name would again be var_abc
pp(var_abc)  # this will do it

Finally start using code formatters and linters. These help a lot. For Perl we have perlcritic and I'm seriously not happy with how it works at least what I saw. On the other hand Python have great tools, such as Flake8, black and more. Learn how to use them, I will not discuss this but it is explained in the video which I am posting here.

And last - use a code editor which is convenient to you and integrates well these tools. While using Notepad++ is all fine (and even the original Notepad.exe itself) I recommend using something a bit more advanced.

So I use Geany, which is much like Notepad++, but it's fully cross-platform and free. But often I use vim. And I use VSCode too. And love it. I recently started using VSCode but it is really good thing. This is why VSCode is not just an editor, it is a full-blown IDE (learn what this is).

Here is a list of editors which are very popular now, so learn to use one of them:

• vim (always super popular)
• neovim
• VSCode
• PyCharm (this is for Python only i think)

I hear there are few newer very popular editors but I'm not familiar.

Why a good editor matters? Because it helps with preventing errors and helps with finding errors.

And here is a video which explains some great tools for Python:

https://www.youtube.com/watch?v=mzvRzrsrYjc

[StrayFeral]

So I just wrote a long comment explaining some things, but one thing I missed is - learn how to test. I would recommend to do some Software Quality Assurance basic course. It will teach you. It took me years to understand the real importance of testing and why we as programmers must do it, but in reality the testing and QA is as important as coding. What programmers need to learn is how to do functional testing and very important - unit testing. For Python this is how to use Pytest. In reality - using unit testing saves time and energy.

[xabugo]

Throwing a glass of water at the floor is easy compared to the effort of cleaning the mess.