musings about technology and software development..

When to bug someone for help?

Let's imagine a hypothetical scenario where a group with whom you have a dependency on assigns a bug to you, telling you it is not their problem.  And, let's also say that you had little familiarity with this code.  Would you:

  A) Spend an hour to generally understand the code, and then try to debug what was wrong?
  B) Spend an hour to generally understand the code, and then find someone to explain the specific problem to you?
  C) Find someone to explain the specific problem to you, then spend an hour to generally understand the code?
  D) Twiddle your thumbs until someone with a more vested interest in this problem takes it over from you.

I think the answer is, it depends.  All too many of us go with Option A, simply accepting ownership of the problem.  Sure, you will learn the most by debugging everything yourself, but it will take the longest amount of time.  Often times, you don't care about learning about this code and just want to hack through to find a reasonable fix.  This approach would only be appropriate if you want to own this code long term, and the debugging time is essentially a time investment.

Researching the issue first will allow you to absorb the most when you finally do talk to the expert, since you will actually understand what he's talking about.  But talking to the expert first will save you ramp-up time, and has the additional benefit that they may realize they can fix it in less time it takes to explain it to you, and just fix it themselves.  I feel it works best for cross-group collaboration to do your own due diligence first, except in cases where time is critical.

Finally, there are times when even thumb twiddling might be appropriate.  Sometimes, the bug is sufficiently complex that you need the issues surrounding it to bake before you can tackle your own problem.  Sometimes, time is the only way for the other group to see the light.  Sometimes, time will cause the genuine priority of the bug to emerge, when it is weighed against other issues for possible postponement, and stakeholders protest.  I find the right things usually happen when they are being addressed by the people who care about it the most.

Welcome ..

I am a dev lead at Microsoft, which means I write some code and lead a hardy group of engineers writing cool features.  I expect to write about software, engineering, technology, and the like.. but I intentionally named this blog "null or empty" because there's a 50/50 chance the blog stays exactly that.  The name is a reference to the commonly used .NET api, String.IsNullOrEmpty().  Anyways, let's start with a comic:

If you can relate to this comic, hopefully you will be able to relate to this blog.