This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 100+ Q&A sites.

BeeBand asks:

I've just been told by my boss that I will receive a negative performance review on Monday. He wants to talk to me about why I am so slow and why my bug fix rate is so low.

I love programming and solving problems but I actually do find my job really, really hard.

I've been a programmer for about 10 years. But this is my first multithreading embedded Linux job—I've been here 2 years and it's obvious to everyone that I'm still struggling. And I think I've become so demoralized and feel so marginalized that I've lost a lot of the fire that I had at the start of the job.

Has anyone ever been in a similar situation, and how do you go about increasing your bug fix rate?

See the original question here.

Break out the notebook

Zack answers (13 votes):

One of the most common management dysfunctions in this industry is not understanding that debugging is intrinsically difficult. I've got nearly 20 years of experience and I still regularly have to spend a full week finding the one-line mistake that makes the program crash one time out of fifty. And then, if my manager doesn't understand these things, they hassle me for taking a week to change one line of code.

What can you do about it?

Take notes as you debug. Just always have an editor window open and write down your stream of consciousness. It doesn't have to make sense to anyone but you. You may find that this helps you debug faster, but it also means you have something concrete to point at to demonstrate that you weren't playing Nethack all week.

Compare notes with all your coworkers. How long does it typically take them to fix bugs? Do their bugs stay fixed? How often do they change one little thing and find themselves buried under a pile of cascading consequences? The answers to these questions will give you some sense of whether you're really struggling relative to the rest of the department.

Make friends with the QA people and the customer support people. They are the ones with the best idea of how important the bugs are. Often this has little or no correlation with how difficult the bugs are, so you can game the system a bit and try to get assigned all the high-importance, low-difficulty bugs. (This isn't really cheating. A well-organized team always goes after those bugs first.

If your boss hasn't been giving you adequate feedback on your performance for two years running, that is a problem to first bring up at this performance review, and then when you get given the runaround on it, to raise with your boss's boss. Be polite, and especially don't let them see how angry you are, but get specific criticisms in writing.

Look for patterns

chrisaycock answers (6 votes):

After two years on the job, it should be obvious to everyone (you, your boss, your colleagues) as to where you stand. You should never find out that you've been doing poorly only once a year; an ideal work environment will provide continuous feedback.

Anyway, regarding how to debug multithreaded code: you haven't mentioned whether this is your code or someone else's. There are some new debuggers and static analyzers that can handle concurrency. But really, knowing the patterns will be your best bet since you'll know what to look for.

If you understand how critical sections and race conditions and deadlock work, then you'll be in a better position to spot things that are unexpected. If you see "communication" between two threads without condition variables, or if resources are mutexed without a particular order, or if a local variable is declared static for no apparent reason, then you've got a potential bug! So learn the best practices of your domain and you'll be in a better position to judge when something is out of the ordinary.

Related: "How to reduce number of bugs when coding?"

Self-reflection time

kmote answers (11 votes):

Many answers have questioned your boss' methods/tactics/metrics/etc. But that is beside the point. Maybe you are slow. Every room of developers has to have one that's slower than the rest, right? (That's just straight set-theory.) So let's assume that's you. The answer is, WHY are you slow? (Clearly that is the question you have to answer before you can solve your stated question of how to get faster.)

There could be all sorts of reasons, but here are some possible explanations to consider:

You are less intelligent than they are. It's possible, right? (Studies have shown that we ALL are less-popular, less-interesting, and (it would follow) less intelligent than our friends.) So maybe you are just slow-brained. Then again, in your case I think this is unlikely. A quick glance of your StackOverflow profile shows that you have a history of asking intelligent questions on a wide range of topics. So you're obviously a thinker and probably a good one at that. You're spread too thin. That same SO profile of yours shows that your questions cover a very wide gamut of technologies over these past 2 years (graphics, Web, Python, C++, C, Linux, embedded, threads, sockets, etc). Personally, I know that when I have been put in the situation of having (or wanting) to delve into a multitude of different streams, I find myself swimming up-current really slowly. Perhaps what you really need here is focus. And maybe a healthy dose of prioritization. Is there anyway you can relegate the less-important pots to the back burner and turn up the heat on the main dish? You're not having fun. When the fire dies down, the steam engine is destined to decelerate. You admitted in your post that your morale has taken a severe hit lately. Unfortunately you've been swallowed into the sucking vortex of self-reinforcing negative harmonics—a force that can destroy bridges. It's an all-too-familiar spiral: difficult task -> stress -> missed deadline -> more stress -> poor coping mechanism -> more stress -> procrastination -> more missed deadlines -> criticism/gossip (real or imagined) -> yet more stress. You get the picture. This rarely leads anywhere useful. Take a lesson from my days in white-water rafting: When you get sucked underwater by a circulating current on the back-side of a class-4 rapid, your life-jacket will not buoy you back to the surface. The best strategy (though non-intuitive) is to find the bottom of the river, and walk out of the riptide. So my advice to you is: find some ground (friends, church, healthy new habits, etc) and make use of it to ambulate yourself out of the whirlpool. You're not in your zone. Michael Jordan made a pretty lame baseball player. (OK, he was still better than me, but definitely a minor-leaguer.) Maybe "multithreading embedded Linux" just isn't your gig. But software development is an exceedingly wide field (as you well know; cf #2 above). Is your company broad enough that your can find another niche? In my last job I was hired as an embedded SW dev. (I had no experience in that realm, but I told them I was a "quick learner.") I quickly sank like a stone. But I kept working hard and kept looking for problems that I did know how to solve for them. As it turned out, I was gradually able to migrate into new responsibilities at which I could shine, and for which I eventually received considerable commendation. So maybe you need to re-brand yourself.

The point is: if you're slow, there's a reason. But, hey—you're a software engineer, dude! Debug yourself!