
My boss just gave me a warning. Is there a way to get faster at solving bugs? - shawndumas
http://arstechnica.com/information-technology/2013/08/my-boss-just-gave-me-a-warning-is-there-a-way-to-get-faster-at-solving-bugs/
======
sjwright
Blogspam. Original content here:
[http://programmers.stackexchange.com/questions/197675/is-
the...](http://programmers.stackexchange.com/questions/197675/is-there-any-
way-to-get-faster-at-solving-bugs-ive-just-had-a-warning-from-my)

~~~
seanmcdirmid
Ars republishes good SE articles from time to time. It is not about link spam,
but rather about promoting SE on Ars, and vice versa. I think this approach is
quite reasonable.

I don't think they give a f*ck that someone on hackernews happens to notice it
on Ars rather than SE.

~~~
eropple
It really is pretty much spam. It's pageview-bait at its finest. (And that's
one of the main reasons I've filtered Ars's non-forum stuff, I've been a
subscriber there for years but I'm not giving them pageviews for bad articles
anymore.)

~~~
seanmcdirmid
Ars writers have been very honest about their use of pagination. Sometimes, I
guess it is to get more hits, often its just a way of breaking up the story
and to reduce page load time. If you are a subscriber, don't you get access to
PDF or something like that?

I find Ars to be one of the better web publications out there. Until theverge
came along, I would say they were bar none the best.

~~~
001sky
_often its just a way of breaking up the story and to reduce page load time_

It's 2013. Articles are text. This is silly.

~~~
seanmcdirmid
Articles are text with huge images. Believe it or not, a page still loads
slowly for those of us in 2nd world countries behind great firewalls. Also, I
think pagerank still takes page load times into account, so putting everything
into one giant long page would actually hurt their google rankings.

------
jiggy2011
It tends to be easier to fix bugs that you caused yourself. You see something
blow up and you can think "yea, that's because I did thing X in Y to achieve
Z".

So it's possible that the other programmers are actually just causing more
bugs than this person, jumping in to band aid a fix and maybe causing another
bug in the process.

This sort of whack-a-mole looks very productive on a bug tracker.

~~~
klibertp
Yeah, reading this question I started to feel anxious about my own employment.
I am almost afraid to go to work on Monday.

We have quite large code base and my colleague and I are the only people
developing it - and all the original devs left long time ago. I spent last
three weeks chasing down a very peculiar race condition, which in theory
couldn't happen. Finally I discovered a bug, mostly by accident, in one of the
in-house libraries the project uses. It was unexpected to say the least,
because I was told many times over that "the library code is ok, check your
own". It took me another week to fix the bug, because it was really complex
and even "less my own" than the code of the actual project.

In the same time my colleague fixed a multitude of bugs (mostly in our,
"fresh" code) and implemented three new features.

Which means I should get fired... Hopefully, I won't - our boss is a technical
person, a programmer with many years of experience, and I believe he will be
just happy that the bug finally went away. But, you know - what if he retires?
What if I find myself managed by someone who doesn't know the difference
between wading through thousands of lines of code and years of accumulated
cruft, deprecated apis and inaccurate or completely missing comments?

I think the OP should - he did this already, as he wrote in the second update
to the post - just find a new, better job. The environment and management
which only watched him struggle in silence and then fired him make no good
place to work.

~~~
jbjohns
If you're so fearful of your job you should quit right away. It's not healthy
to live like that.

~~~
klibertp
That was a bit of sarcasm. Sorry I didn't make it clearer.

------
WA
There's clearly one very easy fix that nobody seems to have mentioned so far:
Communicate in a better way.

I found that the overall performance of a programmer is very hard to judge
from the outside, especially from less-technical managers. But managers are
there to allocate resources and _track progress_.

Tracking progress is the most single crucial thing for them. They want those
tickets closed and they don't care about the bug. They don't understand that 1
line code might take a week and at other times, you do 500 lines of (easy)
code in a few hours.

Getting a negative review could mean from the manager's perspective: You don't
_appear_ to make much progress. The solution then is not necessarily to become
faster (although that might be an issue as well), but to learn to communicate
in a manager-oriented way.

This could be a very simple status update email once per day and a summary of
progress once a week. Don't communicate _weakness_ ("I'm very slow at this"),
but _problems_ and their _solutions_. E. g. "The multi-threading task was
implemented in a very inefficient way before. Occasionally, it leads to errors
that are very uncommon and thus hard to trace. I'm working on it and I have an
idea for a good solution that will increase performance as well, but it might
take a bit more time."

Or turn the task back to him: "I can't reproduce the error in a reliable way.
Could you please provide test cases / test data that lead to this error?"

These might be some more or less contrived examples, but you get the gist.

~~~
dvanduzer
I'm going to read the rest of this comment about the "very easy fix" of
communicating better, and then edit my reply if I think there's anything else
to say.

~~~
mikevm
> I'm going to read the rest of this comment about the "very easy fix" of
> communicating better, and then edit my reply if I think there's anything
> else to say.

I'm going to reply to your comment, so that in case you will say something
worthwhile in your future edit, I could edit my reply to your reply if I think
there's anything else to say.

~~~
dvanduzer
I was quite honest about what literally happened there.

If you truly believe that learning to be a better communicator is extremely
easy, why would you need to state that prior to several paragraphs of
explaining how to be a better communicator?

Ask any educator about the effectiveness of lectures beginning with "X is
easy, just follow these 5 weird tips!"

Either the 5 tips are trivial, or you were lying about it being easy.

~~~
WA
Becoming a better communicator surely requires practise, but there are some
very easy steps that produce instant results. Short daily status emails and/or
weekly email status reports are EASY and yet it isn't done by all developers.
This is waaaay easier than improving your skills on debugging multi-threaded
systems. The latter is definitely a noble goal, but will fail short if you
don't even write that stupid status report once in a while.

And yes, these tips are utterly trivial but nonetheless important. Do you
write status report emails?

~~~
dvanduzer
I do write status report emails, but that kind of communication has operated
very differently at every different organization I've worked in.

I'd assume the department responsible for debugging kernel driver bugs is far
less interrupt-driven than the operations-oriented departments I base my
experiences on. The common thread though, was usually about prioritizing
between the work we already roughly understood how to do. The more common
communication failures were about coordinating and scheduling. But when you're
doing something specialized enough as debugging multi-threaded embedded
drivers, and you have a specific metric like bug closure rate, then all of
that information is already captured in the bug log.

The _first_ response in the Ars thread says that keeping detailed notes for
yourself is both a powerful tool to help you learn, and also a tool for
communicating in very specific ways with the rest of the department. One
reason better communication isn't a "very easy fix" is that multiple people
are involved, and you can't just force everyone to pay attention to all the
relevant information already available.

Alternatively: I worked on a small development team / startup with daily
stand-ups that would tend to last 15 or even 30 minutes. Not a single person
in the room ever seemed to know what they were going to say prior to opening
their mouths. No amount of "leading by example" seemed to convey the concept
that summarization is the most important feature to communication in _daily_
status meetings.

~~~
WA
Thanks for sharing your experience.

------
sybhn
Precarious position to be in when you have to clean up after others, and these
'others' are not pro-actively helping you out, or have no incentive to do so.

Every software company - or so it looks from my anecdotal experience - has one
of more of these positions. It seems to be more rampant in larger companies or
companies carrying a lot of legacy code.

Nonetheless, I've seen this pattern consistently in QA and Rel-Eng groups
where the impossible expectation of delivering quality out of incomplete and
poorly designed products.

It's also funny that usually the ones building new things - vs fixing /
delivering things - are the ones getting the highest compensations.

------
aufreak3
_Technical_ : The "break out the notebook" is close. Use the scientific method
in your debugging. By this I mean form hypotheses about the bug and test them
... rinse and repeat. The important bit here is that you keep track of the
hypotheses you come up with and the way you tested them. This track serves as
proof of your work that you can ask for a co-worker to examine for its
effectiveness. You don't need to do all the hypotheses testing yourself if
your hypothesize about some part of the system that a colleague is more
familiar with. No shame in asking for help here, even if it is repeatedly
denied.

 _Managerial_ : Ask how to improve. Are bugs being prioritized properly? If
some level of management is not involved in prioritizing bugs, ask them to
take and look and prioritize. It is not enough for you to think "hmm .. no
hurry to fix this bug for the next release 'cos its a very obscure case and
there are these other important ones to tackle first."

 _Self management_ : If you're overwhelmed by many bugs and are zombied about
where to begin or touch next, just pick whatever looks the easiest to fix and
fix it, irrespective of priority (and loop that). This at least gets some
momentum going. A management that expects bugs to be fixed exactly in the
prioritized order is ignorant. That's not how systems fail. What might be
thought of as trivial might turn out to be very significant, and vice versa.

------
nnq
I think there is an interesting generalization of this question:

 _How can one get better at debugging in general?_

(My context is that I know there are two types of programers:

Type 1 programmers, what I call "starters, imagineers and architects" \- great
at starting things from nothing/scratch/blank-piece-of-paper or at completely
rewriting and (re)architecting an existing piece of software, but horrible at
fixing/debugging things, and

Type 2 programmers, what I call "uberhackers and master fixers" \- great at
finding bugs (and either fixing them or exploiting them for good or evil) and
at fixing and understanding existing systems, but horrible at starting things
from scratch, like they totally "mindfreeze" if you put them in a blank-piece-
of-paper situation and desperately search for something that already exists to
adapt for solving the existing problem, even if nothing really fits well, or
in the end they start but with a very hacky badly-architected design that
degenerates into a mess that only other uberhackers and master fixers can use
and understand.

And _I know that I am a Type 1 guy_ , but _I really want to get better at Type
2 tasks._ )

~~~
stinos
I think you're generalizing too much yourself here, there is no distinct line
between the two types you mention. I know enough programmers that are capable
of doing both things you mention pretty much equally well, this seems
especially the case for those with >10 years of experience. This is already
indicated by the description of the first type as being able to "completely
rewrite and (re)architect an existing piece of software": that imo implies
being able to "fix and understand an existing system" as you describe the
second type. If you program long enough, you should be able to both start from
scratch and hack into existing code. Unless you're just not good enough or
have some weird split personality :]

~~~
nnq
...you're kind of right, I know that I am getting better at what I call "type
2 tasks", but I'm desperately looking for any shortcut that will allow me to
_get better at it faster_ :) (I don't have > 10 years experience)

------
altero
Just give your boss what he wants. Optimize for metric "number of bugs
solved". Fighting back costs way to much energy and is usually useless.

I have been in similar situation before. I joined team with absolutely un-
maintainable code. Build process took 1 hour, was semi-manual and involved 3
machines. This was mission critical application, but management rejected any
sort of investment into maintainability. We made QA builds only once a month,
because it was too tricky to test and verify entire app.

I fought back and cleaned worse mess in my free time. I automated and
virtualized build into single machine. I wrote 'sort of' integration tests to
automatically verify build. At end we even had continuous integration.

But it was not me who benefited from improved productivity. Number of closed
bugs in UI skyrocketed. But I usually do hard & sneaky concurrency issues,
which were still hard to fix. At end I was marked as 'unproductive' and
eventually quit.

------
ryan-allen
Troubleshooting is a skill like any other, and naturally different programmers
have different aptitudes with all of the skills.

I think that you need some kind of troubleshooting aptitude to be a
programmer, but the reality is that the variance is quite significant. In a
land where not all bugs are created equal this multiplies the results people
get.

I think it's OK to acknowledge weaknesses, and to hand-off certain tasks to
those who excel at them, i.e. "Rod is a gun troubleshooter, let's give this
one to him".

The whole agile idea of spreading the tasks around equally is such a naive
practice, and a great way of wasting customers and employers money. In a world
dominated by so called best practices we're just going to suffer these kinds
of results ad infinitum.

Maybe you just suck at solving bugs? Maybe you are amazing at feature
development and UI design. Great! Do what you're good at.

------
erez
Once reported/found, study the bug, reproduce it, debug it, and try to
understand as much as you can about it, but once you get stuck, even for a
couple of minutes, take all that you have found about it, form a simple, clear
way of presenting this problem to someone else, contact that person and
deliver the explanation.

From here it's collecting three things, answers to future questions, better
understanding of the system, and more efficient ways of finding out about a
bug. These three complete each other and would help you reach faster either
the solution, or the question to your colleague/friend/support
person/IRC/forum/other.

------
amberes
May I offer some practical advice?

You do have extensive logging, especially around the buggy code? Do you have
source-level debugger that shows your variables and that can step/trace
through code?

These are the 2 tools that I have found most indispensible when squashing bugs
in the past. Somehow source-level debugging seems to have disappeared from the
developer's toolbox the last couple of years. I am told you don't need it
anymore as you can write tests (???).

~~~
reginaldjcooper
Supporting your suggestion; I find that GDB is the best weapon in my arsenal.
I am also fond of assertions that end the app and squawk loudly if a
constraint is unmet.

------
jbjohns
A job is not a marriage. If you start having problems respond by looking for
another job. A job that gives you lots of stress or makes you feel bad is not
good for your health or well being. And I would normally advise against trying
to "fix it" as well. That process itself is always stressful and rarely
results in anything except recommendations about how _you_ can change.

The only thing the OP needs to get better at is giving interviews.

------
graycat
Sure, have the code better organized and documented with good test buckets at
each level of integration. And when that approach is widely taken by
supervisors who ask such questions, a person can get rich selling cast iron
umbrellas to protect against the giant flocks of flying pigs.

------
keithg
I would ask the boss to sit down with me and give me some guidance and advice
on how to improve.

------
virtualmachine
unit testing!

------
amerika_blog
He's just pressuring you to work longer hours. That's cheaper for him but
abusive to you.

