Is there any way to get faster at solving bugs? I've just had a warning from my boss [closed]

Question

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 actually 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 demoralised and feel so marginalised 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?

---

Update: I had the review. I have been put on a 3 month 'employee development program' (of the type mentioned by Dunk ). Not sure whether I can turn this around. But even if I do have to move on, I've learned a lot from this experience.

Another Update

It's now about 6 weeks since the first review. My advice to anyone facing the same situation is to be humble enough to take criticism and learn from your mistakes. And to not be afraid to look dumb. Ask loads and loads of questions. Let people know you're trying to learn and keep asking until you understand. But be prepared for it not to work out. I'm constructing a portfolio of code ... as well as giving it my best shot.

Yet another update

I am hesitant to put this on here, since I'm concerned that I will not be able to refer future employers to my stackoverflow profile... But anyway, it might be of interest for someone reading this question, but I actually lost my job a few weeks ago. I'm in the midst of brushing up on all the skills I need to - I've taken a lot from the advice given here.

Answer 1

Many answers have questioned your boss' methods/tactics/metrics/etc. But that is beside the point. Maybe you ARE slow. Every room of developpers 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:

1. 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.

2. 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 fast (or, rather, really slow). 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?

3. 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 under-water 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, dude, (friends, church, healthy new habits, etc) and make use of it to ambulate yourself out of the whirlpool.

4. 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 recieved 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!

Answer 2

Your boss may be correct: you may be "underperforming" (more on that in a minute). But it may not be just your level of competence that's to blame. I don't think it would be a reach to suggest forces outside your control are causing you stress, which is having a negative effect on your performance.

Let's have a look at a few of the reasons your boss may now be bringing this up:

Culture and Politics

There may be forces beyond your control requiring your boss to now voice his concern. It's important to understand the system you are working in. Your job is to make your boss look good. The only way to do that is to understand the pressures he/she is under.

Ability

It's possible that ability is not up to par, as you say he openly stated. Here is what I would do in this situation:

Get specific feedback from your boss on how he measures performance. Are you not closing as many bugs as person X? Is there a set number of bugs you should be solving? If you are working alone then you need to make sure that the people measuring your performance are measuring it fairly and not based on some preconceived idea.

If your performance is slow and based on a real gap, identify that gap and put a detailed plan together with your boss with the aim of closing it.

This review is also a good opportunity to bring up the fact that you are not happy. It's good that you've identified that you don't love this job. But figure out why. What part of your job do you like and what don't you? It might be that this job isn't for you...

Answer 3

Some work environments are unworkable. I've seen environments in which no one could survive (save for those who were in at the beginning) because so much was undocumented and questions were so vehemently discouraged.

You really need to be honest with yourself regarding the expectations and the resources provided to help you to meet them. The problem may not be you.

You mention that there are people doing similar jobs to yours who are, I presume, not having difficulty, but that have 5+ years of experience to your 2. How do you feel in comparison to your peers? Are they rockstars who entirely outclass you (in this respect), or are they just like you? Perhaps they just got to know the system when it was more simple... You mentioned having 8 years programming experience before this line of work. How did you do there? If you did great, then that should tell you something.

The part that struck me is the bit about your describing yourself as being in the dark with respect to all the bugs that come your way. It could be that the code base is so vast and uncharted that the expectations may not be reasonable.

For you to have made it as far as you have means that you have done something right and have something going for you.

Bottom line, I think, is that you need to feel good about yourself and about what you are doing. And if that means moving on, then so be it.

Better to move on than to have a job ruin your life.

Answer 4

First, note: this answer may only apply to certain regions where it is illegal to dismiss an employee without severance. That said...

This could be a case of Constructive dismissal and which is illegal.

The tactic is to demoralize and lower the self-esteem of an employee until they quit the job. It's a way for the company to save money by not having to pay severance, or solve the problem of having to confront the employee and fire them.

He wants to talk to me about why I am so slow and why my bug fix rate is so low.

This fault is very ambiguous. It's impossible for either side of the party to claim the other is wrong. You took a month to fix one bug. So what! This places you in a defensive position, by having to present facts to support your claim that a month was required. Given your current skill, experience and knowledge as factors. As an employer it's the employer's job to manage the time and efforts of his employees. The employer must be the person engaging in the risk associated with having the bugs fixed. Not the employee. He always had the choice to assign the bug to someone else.

If you are a contractor, and it states in your contract that will be responsible for the fixing of bugs, then it's a completely different story.

Is it wrong for the employer to complain that you are taking too long? Absolutely not, but he can not hold you accountable for it, and he can not fire you for it. He can say to you "We have no more bugs that require your skills, and you are placed on leave," but they must tell you the moment a new issue comes up that you can fix. Otherwise, they must terminate with severance. What he can not do is give you work you can't handle and then complain about it. I think this is illegal.

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

There is a big difference between taking a job you find hard, and your employer giving you work that is too hard. If you feel the tasks assigned to you were done to discourage you from having a career with the company, this could be illegal.

I've actually 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.

This is why I think you've found yourself in the middle of a constructive dismissal. They aren't happy with you so they pile the crap on you until you leave.

And I think I've become so demoralised and feel so marginalised that I've lost a lot of the fire that I had at the start of the job.

An employer is responsible for providing a safe and positive work environment. Without more information (most likely personal) it's difficult for outsiders to say what is really going on here. Ask an employment lawyer for a free consultation. They will be able to tell you if you are being played.

References

I'm not a lawyer, but did Google some documents discussing the topic of Constructive dismissal which are worth reading before you enter your review on Monday. The main point here is to watch out for a reduction in salary, humiliation and sudden changes to your career with the company.

Relevant facts watch out for:

• Failure to properly support an employee during difficult working conditions
• Excessive disciplining of an employee Imposing a change in the employees place of work at short notice
• Imposition of a reduction in salary or wages

Legal Q&A: Constructive dismissal

Reasons to claim for constructive dismissal

Wikipedia

elements of a constructive dismissal

Answer 5

Perhaps you are being compared to one of the original programmers of a project. I know that as the original developer of one of the projects I work on, I have a tremendous advantage when fixing bugs in it. I don't think it is because of lack of documentation, it is just that I can intuitively leap to potential problems because my brain knows all of the code.

If you're being compared to that, then you just aren't going to measure up. It is always going to take you more time to come up to speed with the project and you won't know where all of the potential interaction points are.

I read your comment about not finding out about tools and tricks other programmers are using to solve problems. Perhaps for your next bug fix you need to try pair programming. This can be incredibly useful. Take turns driving the keyboard. Do a lot of talking.

You can use a notebook or a whiteboard to chart out function paths, threads and lock lifetimes, and mark where you observe various bits of behavior and where you can insert new probes.

Solving these kinds of low-level threading problems can be really hard and I have a lot of sympathy for you. I've had to analyze several gigabytes of log files before to spot a two-line problem. And you know what? I stared at that for days before I asked for help from a junior engineer who'd been an intern the year before, and he came up with a new approach and spotted the problem in an hour. So, after you put some time into a bug, get some new eyes on it. It can help a lot!

Answer 6

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.

Answer 7

While you may love programming and solving problems, there may be the question of how well are you applying what you are learning to other areas. Are any of the last dozen or so bugs you've fixed similar enough that what helped you fix one was useful on another? This is part of looking back over what you did do and how long did it take to get that done. Just an idea to consider.

Secondly, I'd look over how are you doing your work. Are you getting interrupted regularly and so as you try to fix bug A, you get told that bugs B and C are higher priority? Consider carefully what kinds of changes in how you do your work may help you here as that is likely part of what your boss is going to want to know.

I have had some work places tell me that they didn't like how long it was taking me to get some of my work done. Course these were those places where if I got one thing done, 5 new things would be dropped in my lap and thus it was easy to be overwhelmed. While I may no longer work there, I didn't have a good solution for how to get my attention down to a few things so that I'm not feeling like I'm trying to master 1,000 things all at once. If I can know a few key things to get done and how my work will be judged, then I'm much better than if I have a "to-do" list that is a mile long and no one seems to care if I get parts of it done. Thus, it could be that there is a cultural component to this within the organization though I would be careful about asking for things here to change. I remember one work place I asked for more frequent feedback and ended up getting micromanaged until I was terminated because I wasn't keeping just to what was on my list of things to do.

Answer 8

After two years on the job, it should be obvious to everyone (you, your boss, your colleagues) as to where you stand. I.e., 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.

Answer 9

Don't struggle alone unless you have to. Recruit colleagues. Get them to help on bug hunts. Ask them about their thought process and tools. Perhaps mention this in your review as part of your plan to improve. If everyone around you is doing better on this system, maybe they know something specific?

Answer 10

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.

Be aware that in any non dysfunctional company things don't happen on this order. If your boss is concerned about your performance, he should set short term goals, and talk about your results to find out where the problem lays.

Instead, he decides to give you a negative review, then find out why. Sounds like he is not willing to involve himself in the problem, and he just want results in the table.

Don't aim to solve bugs faster. Aim to evaluate your own ability, check how your colleagues work, how they know what they know, and be aware that this is not an ideal company.

As for practical tips, I use code snippets, and my own mediawiki to take notes. I always have in mind what books to read next, and what direction to go to continue my learning. Learning is the path to a better job and a happier life.

Answer 11

First, a confidence boost:

Why suffer? You can easily find a job where they will think you're "god" just because you can do Linux embedded anything, regardless of your bug fix rate.

Anyway, it's impossible to set a time limit on hunting a bug. Bug hunting is a skill, no doubt, and efficiency in it is highly valuable.

You might be missing some basic trick that others know about, which makes you slower.

For instance, if you and I are working on some Linux middleware, and I'm using Valgrind to find memory corruption problems and data race conditions, whereas you're only relying on gdb and printf, I will probably kick your butt, even if you're smarter than me.

Also, how is your understanding of concurrency? If you've been developing for ten years, but most of that experience wasn't with multithreaded code, that could be a problem.

You should study multithreading in detail: more than just knowing how to use the API's, but really "get" it on a deep level. If you're doing multithreaded programming, you should be that developer who can look at a codebase from a mile away and spot scenarios of race conditions, deadlocks, priority inversions, starvation ...

Answer 12

I recently read the book Working Effectively with Legacy Code and it's given me a significant boost of confidence when tackling an issue in any codebase.

If the code you're working with is anything less than perfect, I think this book would be of help. I've found that a lot of the time in order to fix a bug, I need to first refactor the surrounding code in order to even understand it, and then once I understand the code, and hopefully make the code testable, tracking down and fixing the problem is less of an ordeal. (Sometimes I even rewrite the code just to understand it, but then revert my changes to reduce the risk of introducing new bugs. Then I insert my bug fix. That technique is based on a trick from the book.)

I think my suggestion only addresses part of your issue, and somewhat indirectly, but the book is worth reading no matter what, since working with legacy code is an inevitability for any developer.

Answer 13

Ask your superior what is your speed of fixing bugs and what's the team's mean speed of fixing bugs. More important, ask him how is the speed of fixing bugs measured...

This is kind of metric isn't really a metric; if it would be, it would be even more unreliable than LOC (although measuring different stuff). And without a proper measurement there is no reason accusing you of anything.

Answer 14

Recognize that you work WITH employers and/or customer NOT for them. Do not hesitate to mention that in the interviews, just to set the record straight right from the start.

You are a professional with much invested in your small business, namely yourself.

You are willing to work while there is a Union of Interests propelling you out of the rack each day.

If that propulsion is not there for a length of time, then move on.

You are wasting your time and energy on a bum employer that does not keep your interest going/skills updated/assignments challenging and/or interesting for you to work on. That is Management's job. Other than that they are pure overhead.....

Keep your passion going, as that is the key.

Answer 15

I've been in similar situations because I was afraid of asking for help. Judging by what you said in this comment...

"But what's frustrating is that there are certain tools/tips/tricks I only found out after being there a year and a half. I've been shifted round from team to team ( I guess cos I was underperforming ) and I'm discovering these 'hidden' tools every so often."

...you may have had the same problem I did. Debugging is as much a craft as writing code that doesn't require as much debug in the first place. Watching other devs work through a debug problem can be highly educational. Ask them for help when you're having trouble sorting something out. Especially if you're covering ground that you haven't before. And do so ideally before it's time to panic because you're not getting anything done.

That said, I do agree with the comments that management was doing something wrong. If somebody is struggling with something, they should be getting help with that before the negative review fun begins. Hell, if anybody on a team is struggling and never gets help I'd say every member of that team is doing something wrong (although that could be a direct result of people watching their bug fix rates overly closely).

Answer 16

What's missing from the OP is any mention of a repeatable process or method that's being followed to resolve bugs.

So, first, document the process that you follow. Be sure to document what each step in the process is meant to achieve.

You can outline the process as having tasks like this:

1. Be sure you understand exactly what the issue is that is being reported.
2. Try to reproduce the issue.
3. Start breaking down the problem into smaller pieces
4. Think of possible causes of the problem.
5. Test those hypotheses

It would be helpful to know if the bugs have existed for a long time, or are being introduced with recent changes. If the bugs have been introduced with recent changes doing code reviews and/or just reading the code that people are creating can help.

I think that if you can clearly define the problem, for example, "I have trouble thinking of hypotheses to test when trying to resolve bugs" then you can get more focused advice.