I'm Drew Town a web developer and systems engineer in Colorado. Always learning, traveling and exploring. Sharing updates, trials and tribulations in tech and life.
This is the easiest and best thing to do. Let your brain work away from the screen. The amount of problems I've fixed by not working on them for a bit is staggering.
Hello! I'm Seniru - a person who is trying to understand what the world is. I like pizza and coding and I find myself as a patient, self-confident and a systematic person with a strong desire
Make a cup of coffee > Explain the problem to someone else > Have a mid-sentence brainwave > Run away back to desk and fix in seconds > Have existential crisis about why that took so long
I think this summarizes my usual process for debugging tricky problems:
When working through various scenarios, make sure to carefully document each step. Make sure to alter only one thing at a time and check all possible combinations of things that may be causing the problem.
Break the problem all the way down to its fundamentals - sometimes that may mean starting from scratch and adding code bit by bit until the problem manifests itself.
Take a break: It's amazing how new ideas can come along when you're taking a walk or are in the shower!
Research: Look for answers online
Ask for help: Ask someone who may be able to help, either online or in person
Workaround: Is there some way to solve the problem without attacking it directly? Maybe there is a way to solve a slightly different problem that will still produce the desired results, or at least get close enough to get past the current bottleneck.
Start asking questions: Why am I doing this? Am I happy? I can't solve this, I'm an impostor. I better work with wood or open a bar..
Oh, that was a typo! Great, keep coding
Ask someone else too look at the problem with you. Sometimes they will see something you didn't since they don't have a ton of assumptions on how it will work.
Stop locally and restart from the simplest working context.
It's almost like performing a git bisect.
0: disable/comment almost everything so that you have the simplest context;
1: test if the context behaves like it's supposed to behave;
2: if it does then re-enable/uncomment half of the things back and GOTO :1;
3: if it does not, then if the problem is self-evident, fix it and RETURN 🥳;
4: if it does not, you already know that the things just restored are responsible for the issue. You can pinpoint the issue even further by disabling/commenting half of the things you have just restored and GOTO :1;
The key point here is that you waste a few minutes in order to get to :0 but avoid wasting several hours finding a bug that is probably way above the context you're looking at.
It can appear vague but it's a debugging process that can be performed in a wide variety of contexts, not just source code.
I always start with asking myself "What assumptions am I making about what's happening?" Most of the time this leads to me realizing I don't understand how something is actually working and that my assumptions created some false understanding. Bugs on computers are almost always deterministic at small scales. So, if you can dive far enough down the abstractions you can find the bug.
If you dont want to leave your train of thoughts by leaving the desk/computer (yet):
Use the help provided by rubber duck (can also be a text editor or colleague if you prefer):
Explain everything you did so far, as you would need to in a stack overflow question or thorough bug report.
In most cases I do that, the missing piece get's obvious.
If you have the patience to write it down and it doesn't help you can of course ask that question here or somewhere else, or file that bug...
And then when returning to it with an empty head, I sometimes start from scratch again depending on the issue.
Also breaking the problem down in separate tasks, and logging everything along the way. And when things are split up properly, comment out everything and try each function by itself.
Been using your debugger all throughout? Try some dumps - even just to confirm what your assumptions are. The inputs really are in that range? This particular function returns what I expect?
Dumps didn't work? Static analysis. Write out the branching. Look for things that seem overly complex or too easy - try and rephrase them in pseudo code and, again, confirm your assertions.
Still no idea? Run through it backwards. What needs to happen so you get the expected result? What would have to happen to produce the result you're seeing?
Break the problem down. Talk to someone else about it. Take a walk around the building.
Essentially: change your frame of mind and reference. Work a different angle until the suspicion kicks in - the tiny moment of "wait... Surely it can't be that!"
Keep at it no matter what, but try to get rest before next session.
We had a bug once that took 1.5 years to determine the root cause.
And we had another one, where the vendor of the software told us after a year of reporting the issue, they could not find root cause. The main reason on this one was that nobody knew how to read a system dump trace which was our only way to show them the error.
Something I heard from a mentor in a coding school five years ago.
Ask yourself:
Could it be simpler?
The number of times that I have lost hours of awful rabbit-hole coding when it was just a typo. Or my server wasn't running. You wouldn't believe it. This advice applies for me time and again.
I keep morale up by reminding myself I've made it this far coding, no bug has destroyed me (yet).
Have a break.
If it's late or you are tired, go to sleep.
If it's time to eat/drink (or your body is need of it) then get away of the keyboard and eat/drink.
As someone who has been a solo dev on a lot of projects, just having a second pair of eyes on something is invaluable.
Keep in touch with devs that you trust so that you can send a snippet, preview, etc. and get their opinion.
It's kind of like a puzzle sometimes: you can keep staring at the same pieces for all eternity, and a friend could walk into the room and see the piece you've been looking for right away.
Take a break, walk, cycle, sleep, come back tomorrow :-)
But when it's mega urgent or you're super fanatic and determined to "just solve it" then following this advice is hard.
An alternative (well, one of the many alternatives) is to "google it". It continuous to amaze me how many problems can be solved in that manner.
To optimize this work on your "vocabulary", the more words/synonyms you know (and the more "background knowledge" you have), the greater the chance of finding something - use a certain generic term and you'll often find nothing usable, but use a more accurate term or focused synonym and it's frequently "bingo".
I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety).
Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.
Explain to the duck what your code is supposed to do, and then go into detail and explain your code line by line.
At some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.
Note: In a pinch a coworker might be able to substitute for the duck, however, it is often preferred to confide mistakes to the duck instead of your coworker.
Start a draft question on StackOverflow (or similar). That’s my last resort, because it forces me to run through a mental checklist along the lines of:
Really make sure there’s no duplicate question out there (with an answer 🤞🏼)
Write a concise explanation of the problem (helps understand the problem better if you can explain it)
Look for evidence other people will eventually ask for (i.e. logs, print screens, reproduction steps, etc)
Continue to work on the draft by asking yourself follow up questions others might eventually ask you (i.e. “have you checked the config file?”, “have you read the man page to look for other options available?”, etc)
After double/triple checking the draft and still not finding a solution, post the question (internet strangers help each other everyday)
Feel guilty for not doing enough research, so you keep trying and might even solve the problem on your own after coming back fresh another day, if the question hasn’t been answered yet (I wouldn’t recommend the guilt part but that’s just usually me at this point)
Dev by profession and hobby. Not a ton of time for hobbies these days though! Mom of two young kids. Also really into dog training (agility, nose-work, advanced obedience, etc) & reading fiction. 😃
I'm always astounded by how often something that seems impossible on one day ends up being ridiculously easy the next day. The human brain does amazing things when you sleep on a problem.
I'm a software developer based in Newcastle Upon Tyne, England. I've got a wide range of experience in companies of varying sizes and cultures, and in roles of varying degrees of responsibility.
Leave you desk. Have a break. Discuss the issue with your colleagues. Try again. Repeat until I figure it out.
Also if not urgent switch to another task and get back to it later.
Turn off the computer and go for a walk.
This is the easiest and best thing to do. Let your brain work away from the screen. The amount of problems I've fixed by not working on them for a bit is staggering.
Yes, this is one of the best thing to do.
Also if you get stuck like for 20 minutes, ask a friend for help.
Good answer, sometimes time can give you the solution
Sleeping works too! And video games.
Make a cup of coffee > Explain the problem to someone else > Have a mid-sentence brainwave > Run away back to desk and fix in seconds > Have existential crisis about why that took so long
This so much. There's just something extra about talking to a person instead of a duck.
And the face-palm moment that inevitably follows 😂
This always works for me too! I try to explain the problem like ours the first time I’ve ever seen it.
I think this summarizes my usual process for debugging tricky problems:
When working through various scenarios, make sure to carefully document each step. Make sure to alter only one thing at a time and check all possible combinations of things that may be causing the problem.
Break the problem all the way down to its fundamentals - sometimes that may mean starting from scratch and adding code bit by bit until the problem manifests itself.
Take a break: It's amazing how new ideas can come along when you're taking a walk or are in the shower!
Research: Look for answers online
Ask for help: Ask someone who may be able to help, either online or in person
Workaround: Is there some way to solve the problem without attacking it directly? Maybe there is a way to solve a slightly different problem that will still produce the desired results, or at least get close enough to get past the current bottleneck.
Start asking questions: Why am I doing this? Am I happy? I can't solve this, I'm an impostor. I better work with wood or open a bar..
Oh, that was a typo! Great, keep coding
Ask someone else too look at the problem with you. Sometimes they will see something you didn't since they don't have a ton of assumptions on how it will work.
Stop locally and restart from the simplest working context.
It's almost like performing a
git bisect.0: disable/comment almost everything so that you have the simplest context;
1: test if the context behaves like it's supposed to behave;
2: if it does then re-enable/uncomment half of the things back and GOTO :1;
3: if it does not, then if the problem is self-evident, fix it and RETURN 🥳;
4: if it does not, you already know that the things just restored are responsible for the issue. You can pinpoint the issue even further by disabling/commenting half of the things you have just restored and GOTO :1;
The key point here is that you waste a few minutes in order to get to :0 but avoid wasting several hours finding a bug that is probably way above the context you're looking at.
It can appear vague but it's a debugging process that can be performed in a wide variety of contexts, not just source code.
I always start with asking myself "What assumptions am I making about what's happening?" Most of the time this leads to me realizing I don't understand how something is actually working and that my assumptions created some false understanding. Bugs on computers are almost always deterministic at small scales. So, if you can dive far enough down the abstractions you can find the bug.
I highly recommend a cup of jasmine tea w/honey & meditation sess.
If you dont want to leave your train of thoughts by leaving the desk/computer (yet):
Use the help provided by rubber duck (can also be a text editor or colleague if you prefer):
Explain everything you did so far, as you would need to in a stack overflow question or thorough bug report.
In most cases I do that, the missing piece get's obvious.
If you have the patience to write it down and it doesn't help you can of course ask that question here or somewhere else, or file that bug...
Take a break. I either:
And then when returning to it with an empty head, I sometimes start from scratch again depending on the issue.
Also breaking the problem down in separate tasks, and logging everything along the way. And when things are split up properly, comment out everything and try each function by itself.
Try a different approach.
Been using your debugger all throughout? Try some dumps - even just to confirm what your assumptions are. The inputs really are in that range? This particular function returns what I expect?
Dumps didn't work? Static analysis. Write out the branching. Look for things that seem overly complex or too easy - try and rephrase them in pseudo code and, again, confirm your assertions.
Still no idea? Run through it backwards. What needs to happen so you get the expected result? What would have to happen to produce the result you're seeing?
Break the problem down. Talk to someone else about it. Take a walk around the building.
Essentially: change your frame of mind and reference. Work a different angle until the suspicion kicks in - the tiny moment of "wait... Surely it can't be that!"
Keep at it no matter what, but try to get rest before next session.
We had a bug once that took 1.5 years to determine the root cause.
And we had another one, where the vendor of the software told us after a year of reporting the issue, they could not find root cause. The main reason on this one was that nobody knew how to read a system dump trace which was our only way to show them the error.
Something I heard from a mentor in a coding school five years ago.
Ask yourself:
Could it be simpler?
The number of times that I have lost hours of awful rabbit-hole coding when it was just a typo. Or my server wasn't running. You wouldn't believe it. This advice applies for me time and again.
I keep morale up by reminding myself I've made it this far coding, no bug has destroyed me (yet).
Turn your computer off, scream, get some coffee and listen to music until you solve your problem.
Have a break.
If it's late or you are tired, go to sleep.
If it's time to eat/drink (or your body is need of it) then get away of the keyboard and eat/drink.
Other solutions include:
Take a break. Do something else.
Rewrite the whole module (if you have time). Also, make use of git so that you can revert you code.
Ask for help! (And not on SO...)
As someone who has been a solo dev on a lot of projects, just having a second pair of eyes on something is invaluable.
Keep in touch with devs that you trust so that you can send a snippet, preview, etc. and get their opinion.
It's kind of like a puzzle sometimes: you can keep staring at the same pieces for all eternity, and a friend could walk into the room and see the piece you've been looking for right away.
Take a break, walk, cycle, sleep, come back tomorrow :-)
But when it's mega urgent or you're super fanatic and determined to "just solve it" then following this advice is hard.
An alternative (well, one of the many alternatives) is to "google it". It continuous to amaze me how many problems can be solved in that manner.
To optimize this work on your "vocabulary", the more words/synonyms you know (and the more "background knowledge" you have), the greater the chance of finding something - use a certain generic term and you'll often find nothing usable, but use a more accurate term or focused synonym and it's frequently "bingo".
Try Rubber Duck Debugging technique:
Start a draft question on StackOverflow (or similar). That’s my last resort, because it forces me to run through a mental checklist along the lines of:
Close all tabs in your text editor, get a cup of tea then it pops in your head out of no where
Step away, take a walk, go to the gym, or talk your process with another dev.
go to bathroom!
Grab a rubber ducky and talk to it :D
Rubber Ducky Debugging
Give yourself a while, let it where it is, do something else! I always press window+L & go out!
Throw all your plans and ideas. Start fresh. Start from basic. A walk to toilet might help
I'm always astounded by how often something that seems impossible on one day ends up being ridiculously easy the next day. The human brain does amazing things when you sleep on a problem.
Taking a walk!
Walk away; slowly & quietly.
I usually take a break, and then after sometime I start debugging it 😂
Rubber Ducking does the trick for me. Though it’s more a colleague than a rubber duck most of the times.
Usually I take break.
I just try to relax, take a deep breath and again start with very small debug steps.
Another thing I try out is take a break and browse through Twitter or Instagram and start out fresh again.
Go for a walk.
Then start thinking about potential scenarios that might cause the failure.
Then try to prove your hypothesis
Go home for the day, by a long chalk. Easily the most effective debugging technique is a change of perspective.
Come to it the next day. The answer sometimes miraculously comes to me in my dreams.
Cry yourself into oblivion.
Sorry I haven't had coffee yet, Ben
If it’s after 5pm shut the computer off go to bed early.
Sleep then rubber talk it
I usually watch a movie and play vids. Just do something other than coding. You would be amazed
Turn off the computer and CONSOLE yourself
Ask for help.
keep searching on Stack Overflow hahahaha, phewwwww
I tend to write the whole code again and be miserable :)
Leave you desk. Have a break. Discuss the issue with your colleagues. Try again. Repeat until I figure it out.
Also if not urgent switch to another task and get back to it later.
Switch to another project or take a break.