What is rubberneck debugging?

Rubberneck debugging is something I see a lot of high achieving engineers fall trap to. Put simply, it’s the eagerness one might feel to respond to urgent inquiries in a forum like slack. I find that it tends to stifle the engineers growth, as well as diminishes the opportunities that newer and more junior engineers have to engage in public discussion.

What does it look like?

I think we’ve all been in this situation before. You’re pushing a PR for a small chunk of work that you tackled in the morning and you go to slack to clear your inbox before starting the next chunk of work.

When clicking through the channels you see an urgent sounding message in a channel you subscribe to.

Can anyone fix this P0 bug? Needs to be resolved by EOD today.

Your curiosity gets the better of you and you follow the link to the JIRA ticket. In reading it, you realize it’s a system that you’ve worked on before. The error seems interesting, and you begin to wonder what caused the bug. Your interest has been piqued, so you respond to the message saying you’ll be able to support.

51 thread messages and 4 hours later you deploy the fix which is accompanied with praise and thanks from both business and engineering stakeholders. There’s a sense of accomplishment that’s warm and cozy, though unfortunately dashed once you realize you weren’t able to tackle your goals for the day.

My question to you now is this, did you do the right thing?

Why do we do it?

Rubberneck debugging is similar to snacking in that it’s ease to complete is one of the core reasons engineers are driven to it. It’s unique however because it generally is higher impact than snacking, and often grabs an engineers attention in a public forum.

For engineers who recently made the transition into a Senior / Staff role, rubbernecking is often one of the ways in which that they stood out. This reinforcment encourages engineers to do more rubbernecking, even though the style of work becomes less satisfying over time.

I’ve seen engineers who spend 70+% of their time rubbernecking, and when a team is often unable to hit its work estimates I wonder how much of their work consists of it.

How does it impact you and your team?

Rubbernecking has the unfortunate affect of impacting your whole team if left unchecked. For you, the person doing it - negatively affects your performance on the things that are important for the team. Rubbernecking is easy to do, and takes away from the hard problems you could be working on. Hard problems that often require a deeper level of thought and longer period to complete. In rubbernecking, you avoid the types of problems that facilitate your growth as an engineer.

Separately, if has the additional concequence of robbing your team members the opportunity for visible work suited to their skillset. This kind of work is especially helpful for newer or more junior team members who have less opportunity to shine.

How do we do less?

In highlighting this issue, I’m not recommending you completely relinquish ownership of your work and the things you have helped build. However I do think for many of you it could be beneficial to examine how much of your time you spend rubbernecking, and perhaps including some checks into your workflow to see if there’s opportunity to do less.

Specifically, I would recommend you focus on the problems that only you can solve. If a request comes in, ask yourself the question could anyone else on the team figure this out? and if the answer is yes then ignore the issue and keep with whatever you were doing before you saw it.

It’s not easy, but incorperating these checks can help keep you on track with the larger goals you’re tackling - and set a good precedence for how your team does work.

If the request is something that newer or more junior employee could tackle then you can do one better, tag them and ask them to get some eyes on it. In doing so you’ll give them a task to better expose them to the codebase, and also give them some visibility which generally is less common for them.