Last week I was stuck on a coding problem on some code I wrote a while back but that contained a nasty bug that had been intermittent and hard to pin down.

This particular application I had written myself before I had a team in place, so I was the only one that knew the codebase. Over the weekend I thought about the best way to keep tackling this problem and the solution I came up with was to involve another person.

This may seem like a no-brainer to some of my astute readers but here are some reasons why it wasn’t my first thought:

1. No one else knew the codebase
2. Pulling them into this problem meant pulling them off their own projects
3. It was a bug I had caused, so surely I was responsible for finding it and fixing it.
4. It’s probably a small, stupid bug and I will look incompetent to my peers/staff if I need help fixing it.

To me, at the time, these all seemed plausible reasons to keep tackling the issue myself. Problem is that I wasn’t getting anywhere. I was actually costing my company money by spending more of my time on it. It was unproductive and not effective.

So I asked my colleague to look at the problem. And then the magic started happening.

He cloned the repo and immediately ran into problems. Bundling wouldn’t work (this was a Ruby/Rails app). The README on starting work on the app was out of date. There was no solid database seed file. A whole slew of issues just getting the app bootstrapped onto his machine. Embarrassment turned into an opportunity to make the app better, document things better and making it easier for new devs to come onto a project.

After an hour or so he started to look at the initial problem. It was a JavaScript bug and adding console.log statements strategically started to highlight some issues. He sat at my desk and whilst I wasn’t paying 100% attention as he was still in discovery mode, I was hearing the frustrations and questions. Eventually I gave him my full attention and we tried a few things and solved the problem together. We high-fived each other, commited and deployed the fix.

At my work we try and pair at least once a week. Either on something challenging or to check out new techniques. Rarely do we do it when we are stuck on a bug. I think this example has shown how good it can be to get another set of eyes onto your code, either through pairing or pull-requests.

As a manager of a project, it can sometimes be confronting to get a colleague or team member to review your current or older code. You are meant to be be the guru. You are meant to help them. But you know, we all have rough days. Sometimes we don’t write our best code. Sometimes we can’t see the cause of a particular bug. Asking for help is the right thing to do.