How do you deal with the emotions of not being the one to find the cause of a bug?

Question

I've had a couple of occasions where I've been trying to find the root cause of a bug. These are bugs that might originate with the code or server configuration but their effect is quite broad so might involve networking and/or concurrency issues so cannot be covered solely by better tooling.

I've spent several days on a problem and been looking in the right areas of code or problematic data and then testing theories against those but not quite joining the dots. When I put it out to to the wider team someone has come in and spotted more context pretty quickly that then joins the dots and solves the problem.

I find it difficult to deal with this emotionally because my ego tells me I should have solved it. And I think other people on the team must think less of me for not solving it. My rational self tells me that this is a learning opportunity and I did what I could i.e. tested theories and discussed with other people.

I think I should document what I learnt. I also continue to read technical books. Are there other ways of dealing with this practically?

NB: for context my experience in the last few years has been focussed on high availability / high demand services but prior to that it was not, so it might just be a case of learning each time, writing it down and moving on.

Answer 1

Welcome to my workday. Some issues are easy, some are tough, some you find immediately, others take weeks. I understand your stress as I suffer it as well. It's not fun to get up every daily and say yeah, I'm still on that bug, no progress.... You feel kinda stupid after 2-3 days.

Here's my personal formula for getting over it.

1. Keep notes. Write down your theories (comment on the ticket) and how you're planning to test them.
2. Ask for help. Speak with your teammates / lead and get their input, so they all know it's a complex issue, and no one doubts you when you can't solve it. _{Hint: They don't doubt you anyway. It's just what I tell myself}
3. Know when to kick it upstairs. Document your theories / findings and ask your team or Scrum master, this time formally, for help.

Answer 2

Don't worry about it. Different people have different backgrounds, different ways of analyzing and investigating problems. People have different experiences and one problem might be similar to a different one they've solved in the past.

What can you do about it? Be happy that it got found, and see if you can learn from the other team member what thought processes went behind resolving this issue.

Use this as a learning experience, not an experience where you're "less good" than your team members. Don't forget that you're most probably better at something else, which is why you add value to the team.

Answer 3

This is an issue that you need to address.

Feeling that there is something wrong when anyone but you solves a problem, or anyone but your turns out to be 'the best' in some particular circumstance is an emotional issue that is going to cause you problems in later life if you do not address it.

Reacting like this is going to cause you problems, from unnecessary stress as you strive to compete with anyone and everyone (some of whom may be inherently better than you at whatever you are competing at) to a failure to appreciate the genuine efforts of others, to an actual failure to cooperate as you strive against your colleagues to be the best.

Answer 4

I wouldn't lose any sleep over this, especially if no-one is questioning your ability. Quite often when debugging you can get so deep down one path that you lose perspective for other issues. This comes from being so focused on the investigation. Sometimes stepping back, or having someone else take a look, brings a new perspective and the bug is identified. This is not a weakness, it is a common occurrence for developers.

The is a debugging strategy called Rubber Duck Debugging which can be helpful. Sometimes a real person can stand in for the duck and help view the problem from a different light. In the end it is about fixing the bug and having the team move forward. Sooner or later you will be the one solving someone else's bug. So don't feel guilty now.

Answer 5

When I put it out to to the wider team someone has come in and spotted more context pretty quickly that then joins the dots and solves the problem.

I find it difficult to deal with this emotionally because my ego tells me I should have solved it.

It seems that your primary internalized reason for doing this is work is so you feel accomplished among your peers, rather than solving the problem at hand. This is an attitude that there is little room for on a technical team.

If you genuinely primarily cared about about problem solving, you would be happy that someone found the solution, and would have no issue that it wasn't you.

Make sure your human emotional/societal needs are being met outside of work so that you don't have this need during a debugging session.

And I think other people on the team must think less of me for not solving it.

This is likely you, reflecting your own thoughts. At the very least, being bad at debugging doesn't make you a bad person... just a bad debugger. (And, I'm not saying you are a bad debugger... nothing in your question actually indicates that.)

We have these sorts of emotional reactions for a reason, but none of that is helpful when it comes to logical thought and pragmatic problem solving in engineering. Don't let your mind default to this. Spend the time doing things that will help you understand these problems in the future, such as:

• Fully understanding what went wrong
  Do you fully grasp what went wrong from a technical perspective in the situation in front of you? If not, use this as a great learning opportunity to fully understand all the connected systems where the problem occurred. You'll be good at spotting similar things in the future.
• Understanding biases in debugging
  Did inspection of unrelated systems, or overweighting the importance of certain facts blind you from other information that lead your co-workers to find the issue sooner? It's very common to get tunnel vision when debugging, especially on a system you actually know very well. A complex system may throw symptoms to a complex problem you've seen before, but really the root issue may by someone tripping over a power cord in a data center.
• Remove all emotion while working the problem
  Break everything down as problem/solution. Bisect issues rapidly, test hypotheses, don't make assumptions, and find that you don't have time to worry while you're working the issue. If you remove the stress and human nature out of your debugging work, you'll be more effective and will hopefully find that you had nothing to worry about in the end. Also, don't hesitate to hold your manager accountable for this same thought process. A manager who stands around your desk to put emotional pressure on you while you're fixing something critical is a manager who just caused the solution to be 4x slower, at least. Tell such a manager to leave, bluntly.

Finally, after the problem is solved, do remember that we are all human and embrace the success/failure of what you did. But, do it in the context of the problem itself, and don't bring your self-worth into it. If you want to get down on yourself for something, do so for not being able to remove emotions from things that require no emotion. This is a skill that takes a long time to learn, and is very difficult for some. If it's troublesome for you, that's okay, it may just take more practice.

If you still have doubts, bring in a box of donuts tomorrow for your team. All small squabbles will immediately be solved. :-)

Answer 6

With more experience comes more wisdom. It's likely the other person has had a similar problem before.

There's also the real issue of being "too close" to the problem. You've been staring at the same thing for so long, you can't even see the missing semi-colon, for example. I've worked on things for hours, only to realize I needed to replace the equals sign with a colon, because it was a difference context. And vice versa.

How do you not feel bad about it? Well, at first you do feel bad. That's simple human nature. You have been programmed by schooling, parents, retail sales, and lots of other things to believe you need to always have the right answer the first time. The "real world" doesn't work like that, especially when it comes to computing. The average programmer fails more times than they succeed. This comes from the simple idea that you only succeed at a task once, but you can fail at it many multiples of times and in many different ways before it finally works. And even then, there's probably a better way to do it. (I can't even type this answer without having to correct my spelling and grammar.)

The longer you do this type of work, you'll realize that it's not your failing, it's just another experiment in not being 100% correct. You learn to brush off your failures and keep going. I find that when people point out something I've been missing, I'm relieved. I no longer have to beat my head against the problem. I sometimes still feel stupid for not noticing the extra comma in my List, but I fix the issue and forget my mistake. I try to just remember the solution, so I don't make the same mistake again.

As a junior, I've found solutions that seniors couldn't. I've completed tasks in 1/4 the time others have. I've also spent days trying to figure out why my JSON doesn't work, when I should have been using " instead of '. Grrr!

I've been learning programming for over 25 years and have been a professional for around 7 years. I'm still learning. I learn new ways to perform functions, write cleaner code, how better to debug code, and how what I think works best doesn't matter to some people.

The key is to not beat yourself up for "failures", since they likely aren't actually failures. It can take a while to learn how not to take it personally, but believe me, it's usually not personal. Even when someone blames you, it's probably their ego you've just insulted rather than it being your fault. Well, unless it really is your fault, but that's not the case this time.

And sometimes you just need a little sugar intake to make you feel better. Eat a cookie and calm down a little. Yum, chocolate chip..... ;-)

Answer 7

It helped me a lot to understand that how long it takes to find the root cause of a bug is often just depending on chance and luck.

There are so many different reasons for bugs and there are many different tools and technics to track down bugs. Imagine someone comes into an office and tells there is something wrong with a server. Often the description of the issue is quite vague.

• Someone might try to reproduce the bug on the server or on his local development machine first.
• It might be helpful to look into the servers log files and analyze them.
• Another developer might dig into the source code and read it line by line.
• Or you might have an exception notification tool that shows might point you into the right direction
• An then there is the developer who just worked in that area of the codebase in the last week or who just read a blog article about some weird bug in an external library the day before.

There are so many different ways who to search and how to find bugs. Sometimes one or the other way might faster or even more obvious. But finding a bug in a shorter time than others is just good luck.

I am sure you would have found the bug too. It would have taken just a bit longer. You went in the wrong direction, but that is normal and just fine. Because only after you found the bug you know what direction was the right direction.

It is just a bit about gut instinct and a lot about being lucky.

Answer 8

For me, however this makes you feel, the answer is the same.

Get used to it.

I Refer to this as tired eye syndrome, and I've talked about it with all of my team members.

Whenever someone has been puzzling over a problem for any length of time and I pop in and solve it in a few min and they look about to kick themselves, I remind them that the exact same thing happens to me.

Never underestimate a fresh pair of eyes; whether it's you taking a break, or a new person with a new perspective. Make a habit of involving team mates when you've been stuck on a problem for a while. Getting help from someone with more experience is great but, that said, I've asked less experienced developers to look at my code plenty of times where it's paid off and I've dug developers with far more experience than me out of many holes. Sometimes, you can get so wrapped up in a problem that you can't see what's right in front of you (just google "Code Blindness").

Two pieces of advice to expediate the process of getting used to this:

Take breaks - often, and for a while, ideally working on something else that clears your head

Bug each other - ask someone to look at what you're working on - "Am I missing something here or what?" has saved me many hours of pointless muddling - and equally, when a coworker starts swearing at their screen more than usual, ask what the problem is. Often times, you (or they) will solve the problem just by having to explain it (why so many developers have a rubber duck) so time taken to explain a problem is almost always worth it even where they (or you) can't help.

Answer 9

What helped me the most was when I started to be on the other side of the conversation more often, and realizing how frequently I only could find the answer quickly because of a fluke of timing.

I can't tell you how many times I've struggled for days on a problem, finally solved it, then a couple weeks later someone asks for help on a very similar problem. In other words, your coworkers aren't generally smarter than you, they just have a head start.

Also, a big reason why I end up with a head start now is that I ask for help more quickly, and move on to the next thing. That means rather than struggling for a long time on a problem that someone else could help me solve quickly, I spend most of my time working on problems that my coworkers don't know how to solve yet either.

Answer 10

I think what might help you overcome this is a subtle adjustment in your attitude towards the projects you work on. You said that you're unhappy when you don't find the root cause of a bug. This suggests that you feel a sense of personal ownership over the code you work on.

In contrast, I've found it helpful to think about the code as belonging to everyone on the team. There is no code that I wrote. As soon as the code leaves my brain and is typed out in my editor, it's code that we wrote. If someone points out a way I could have written it more cleanly or correctly, it's not an attack on my code, it's a chance to make our code that much better. And when a bug is found, I don't waste any time worrying about whose code produced the bug, or who ultimately fixes the bug. It's a problem in our code, and it's a win when we fix it.

I've found this really does help me have a much happier experience when coding! It means that when someone else breaks something, I don't spend any time looking down on them. It's as much my responsibility as it is theirs, and I'm happy to dive in and fix it with them. It means that when I break something, I don't sweat it too much myself! I know that my coworkers have the same attitude I do, so we're all free just to get the problem resolved without pointing fingers.

It means that when I finish a difficult project, like fixing a thorny bug, I don't get an inflated ego. It was a project that we needed to accomplish, and we all win now that it's finished. And when a teammate finishes an impressive piece of work, I don't get jealous or try to downplay their success. Again, it's a victory for us, and I can congratulate them and take pride in working alongside them without worrying about comparing myself to them.

If you adopt this attitude, then when you spend a long time trying to find a bug only for someone else to solve it quickly, you won't feel bad about not solving your bug. You'll be happy that the team solved the bug, and you get to be a part of that victory too. If you're part of a healthy team, your coworkers already have this attitude and aren't looking down on you for not racking up points. They're happy you're pitching in to help with the bugs to the best of your ability.

Answer 11

You are part of a team, and the team has just scored! Rejoice!

You were not the final person on the ball, but you made the final pass. When you described the problem to the team, you gave them exactly what they needed to solve the problem. You did good!

Answer 12

A lot of these answers are really great. Focus on the teamwork is truly critical here. And the learning curve really never stops, on any project.

I've been in my current position for almost 3 years now. I often felt the same as you at the beginning. I stalled on a bug, searched for hours/days on, only to see someone else point me in the right direction after 3 minutes of checking in on me.

But as time goes by, and bugs come and go, I'm more and more able to be that person myself. As I grow more knowledgeable about the project, I have more and more opportunities to help my colleagues the same way they helped ( and still help ) me.

So that's my advice. Try to put yourself as often as you can in a position where you can be the helper. It won't matter that people have to help you, if you know for sure that there will soon be an opportunity to do the same for them.

Answer 13

my ego tells me I should have solved it. And I think other people on the team must think less of me for not solving it

It's really good you've reflected and identified the beliefs behind your feelings. You're developing good self-awareness skills there. It might be worth pushing that process a bit further. Why do you think you should have solved it?

• Is it just ego — thinking you're the best bug hunter there is, who will find the cause of every bug in short order?
• Do you feel like once you've been assigned a bug, it's your responsibility to solve it?
• Do you feel like you wouldn't have been assigned the bug if you weren't best-positioned to find the solution

Once you feel like you've identified your feelings and beliefs, the next challenge is to try to think about them differently. This isn't easy either! But once you're clearer about the roots of your beliefs, you can try to come up with other ways to think about the situation (asking other people is okay here too!), and see if they ring true too. For example, respectively:

• I'm not the best bug hunter the world has ever seen, and that's okay. There's only one spot for best, and there's literally millions of programmers in the running. I still have considerable expertise and experience, I'm diligent and persistent, and I make sure to learn from each bug.
• I don't have to fix every bug myself. We're a team, and our goal as a team is to further the company's goals. We do that quicker and more efficiently when we use a small amount of time to share tricky bugs, in case someone else has some insight that can solve it more quickly.
• The managers assigning work don't know what the cause of bugs is - if they did, they'd already be solved. There's no way to know who's best-placed to fix it in advance, so if I'm struggling to pin it down, it makes sense to ask other people.

At the risk of being too on-the-nose, the whole process is a bit like bug hunting. You start by examining your possibly-complicated feelings and beliefs, to understand what's currently happening. You use a bit of creativity and lateral thinking to come up with some different ways to think about the situation. Hopefully you end up with a system of feelings and beliefs that works a bit better, and is a bit more robust.

(You'll also probably, at some point, feel like a complete ground-up re-write in a different framework is the answer. We call that a mid-life crisis :) )

Answer 14

It's a team game!

This is very similar to what I find myself reminding a kids sports team that I help out coaching - just because you didn't put the [ball/puck/quaffle] in the [net/hoop] doesn't mean that you are not part of that score. The actions you took before the team scored contributed to the result.

You colleague will have been able to come in and state that:

a) Bob spent several days trying to track this down, so it is unlikely to be any of the obvious things that they would otherwise have to rule out.

b) It's likely to be something a bit more ridiculous.

They are not starting from the same point that you did, but rather building from where you left off.

Answer 15

I also have that team member that comes by, takes one look at what you are doing and solves the problem in 5 minutes that you were struggling for a week on.

What helped me emotionally a lot was to realize that even that guy isn't some god who can do everything. He is just very good at what I'm not good at.

Every member of the team has different strengths and weaknesses. The important thing is to find your own strength that can be utilized by your team. For me I found that 2 of my strengths were underrepresented in my team: code documentation and testing. So nurturing those strengths gave me something to be proud of and something I could help my team members with. And it balances out my weaknesses in difficulties reading other peoples code and being slow when debugging code.

So try to stop comparing yourself with others. Find your own strengths (it may take a while, but that's ok), be aware of and accept your weak spots. Nurture your strengths - this will allow you to give help to your team members. Try to get better with your weak spots, but accept that you can't be good at everything - get help from your team members in these areas.

Since emotions are not rational, this may take a while to get better. It is a process.