How to fix bugs (and influence people)

I work on a large team with a lot of dependencies and fairly tight deadlines.  I wanted to share some of a few techniques for fixing bugs quickly.  Maybe this is all common knowledge but I’ll share it anyway.

  1. Trade bugs. It’s not very efficient if you and another dev to be modifying the same code at the same time.  Swap bugs with your teammates to define clear ownership.  Sooner is better than later.
  2. Fix areas, not bugs. Don’t just fix one string on a page, fix all the strings on the page.  If a validation check was missing in one API, it is probably missing in other APIs too.  Proactively look for related bugs assigned to other people and take them on.
  3. Kick off a build every night before you leave. I have known people who scheduled jobs to do this automatically.
  4. Pipeline your work. There is a lot of idle time spent waiting for builds to finish, deploying, etc.  Fill that time with something useful by switching over to another bug.  My pattern is usually to repro the bug (stepping through the code), code the solution, then do final testing.  So I like to work on three bugs (actually three sets of bugs, see above) at once:
    debug  code  test
          debug  code  test
                 debug code  test

    Sometimes there is a fourth step – “think” – for more difficult bugs.

  5. Write tools. Sometimes it is a big pain in the ass to work through the product to repro and fix bugs.  Sometimes building simple tools can really help your productivity, for example a simple winforms app that mimicks a more complicated client application.  I have written command line apps that talked to webservices in the past.  Once you build the tool, let your teammates know.
  6. Unit test and refactor. Try to think about how you can build a strong foundation of unit tests that are easy to add to.  Unit tests prevent regressions.  Also, once you have confidence in your unit tests you can fearlessly refactor code if you notice lots of bugs in a certain area.
  7. Schedule uninterrupted time for yourself. It’s hard to work effectively in 15 minute chunks.
  8. Don’t break the f***ing build. That slows down the whole team.  If you notice a blocking issue, jump on it immediately even if it is not your area.  You will learn something in the process.

Author: natebrix

Follow me on twitter at @natebrix.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s