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.

  • 170
    Do let your boss know that it was real nice of him to save the up for your review instead of mentioning it when he noticed it was a problem.
    – Blrfl
    Commented May 10, 2013 at 17:09
  • 13
    Maintenance programming requires a certain kind of person. Maybe it's just not your thing. Likewise, new development requires yet another kind of person. You talk about discovering tools/tips/tricks. How many of those tools have you created for your own use? If the answer is none, then I really think you are not a maintenance programming type of person. If you've been shuffled around between multiple projects for lack of performance then take that as a clear message that you aren't qualified for the position you are in. Go find something more suitable to you.
    – Dunk
    Commented May 10, 2013 at 19:24
  • 40
    If you have to guess that you're being shuffled around because of your performance, management is doing something wrong. Likewise, if the first you hear of your underperformance is after 2 years, management is doing something wrong. Commented May 10, 2013 at 20:42
  • 32
    @Bee:Typically, once someone gets a poor review, it is time to leave. They may put you on an "employee development program" but I don't think I've ever seen anyone recover once they hit that stage. The easiest time to find a job is when you already have one. So if I were you I would be updating my resume and start looking elsewhere, very soon. You should also be very careful with the type of job you take. 7 years experience still leaves options. Once you hit 10, companies are going to expect expertise in particular areas. Pick an area you like and are good at. Oops just saw you hit 10 already.
    – Dunk
    Commented May 10, 2013 at 20:43
  • 8
    Not enough to be an answer, but regarding "way to get faster": You state it's a domain you're new in. Could it be that you're way of fixing is too much trial and error, not really knowing what's going on "deep down"? In such a case, learning the basics thoroughly will make you better to spot the potential issues.
    – Matsemann
    Commented May 11, 2013 at 9:33

16 Answers 16


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!

  • 2
    what a brilliant answer. i think all of your points are applicable to me ( and regarding #1, well perhaps I am less intelligent, i hear that there's different types of intelligence - so maybe that is related to #4. maybe I'm a numbskull embedded linux dev but maybe I'm better at web stuff ... and now I think about it, this actually might be realistic ). anyway - you are very perceptive.
    – user90636
    Commented May 17, 2013 at 7:55
  • 14
    3 and 4 are bigger (for programmers) than most bosses can imagine. If a programmer has low morale, he/she can't concentrate on work. For a programmer, morale is momentum and momentum is everything.
    – TimG
    Commented May 28, 2013 at 15:14
  • 7
    Excellent answer. Debug yourself is a great phrase, btw. I wish I could upvote you a second time just for that.
    – Kyeotic
    Commented Sep 1, 2013 at 19:25
  • 2
    Your "it would follow" doesn't work in point 1 since the friendship paradox models relationships between two people as a simple bidirectional edge between two vertices in a graph, whereas a graph of who is "smarter" than whom would have to consider a vast array of other factors, not to mention that rules of transitivity do not apply. I do agree with points 2,3 and 4. In the case of the OP I think his boss is a douchebag who suffers from the dunning-krueger effect. Commented Oct 7, 2013 at 20:00
  • 1
    programmer, debug thyself. love it :) good answer also. useful to me, not because I am in that situation, but because I can see now how to avoid it. +1
    – jammypeach
    Commented Apr 24, 2014 at 9:55

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.


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

  • 2
    that's a great answer. I have some thinking to do about why I am not enjoying this job. Mainly it's the log files that they give us to accompany bug, i have come to loathe them more than anyone else - I start off always completely and utterly in the dark with any bug they give me. I think it's this 'in the dark' feeling that I hate.
    – user90636
    Commented May 10, 2013 at 17:33
  • 4
    Unless one has experienced a similar issue on that same project, most people start off "in the dark" when they get a new bug. Then based on the symptoms, you figure out how to recreate the issue, which should give ideas on where to start guessing on the cause of the problem. You continue step by step. Nothing magical, nothing to hate. You say you hate the log files. Did you create yourself any tools to automate analyzing those log files? Ignoring the fact that the log files should be useful, if they weren't it wouldn't be long before I created a tool to help analyze them for me.
    – Dunk
    Commented May 10, 2013 at 19:32
  • 1
    @Dunk yes I did create a tool to parse the log files in various ways. I found out afterwards that someone had already created one a year or so ago.
    – user90636
    Commented May 10, 2013 at 19:47
  • @Bee:Your creating a tool shows some initiative required. Doesn't anyone give you an overview of the development environment when you transition between projects? If tools exist then it would sure seem like the project lead should have let you know about them.
    – Dunk
    Commented May 10, 2013 at 20:34
  • @Dunk re overview - nope. My first team lead showed me a particular tool - but did not indicate that it was useful for fixing bugs of a specific kind or that it could translate to other projects. When I was moved to this new maintenance project no one talked me through the dev environment - I just had to ask around. It was only after struggling to build my own tool that I asked a colleague and he mentioned how I could use the original tool. (NB this is a different tool than my previous comment ).
    – user90636
    Commented May 10, 2013 at 20:53

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.

  • 2
    I've seen teams in my professional career that are exactly as you have described. The code that they maintain is vast and cryptic, and information about how it works is jealously guarded. New team members are intentionally left to their own devices, and end up transferring to save their careers. Commented Sep 1, 2013 at 3:22

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.


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


elements of a constructive dismissal

  • 11
    It's not illegal to give negative performance reviews, but they do have to be objective and agree feasible criteria for work and support you.
    – pjc50
    Commented May 10, 2013 at 19:12
  • 9
    I thought, maybe I'm overreacting, when I posted that answer, but reading your post it resonated with my own experiences. Bug fixing is not something that can be measured with a performance context. I've spent 3 months once to fix a single bug. Usually, the smart guys are the ones who get the hard bugs.
    – Reactgular
    Commented May 10, 2013 at 19:13
  • 9
    I'm down voting as I see no evidence you're a lawyer and claiming to give out legal advice. Also, if other employees are fixing X bugs on average per month, but the OP is fixing X / 10, that absolutely is objective and reasonable.
    – Andy
    Commented May 10, 2013 at 20:06
  • 7
    @Andy thanks for sharing why you downvoted. I agree that bug fix ratios are an indicator, but what is objective about telling someone on a Friday that they have a negative review coming the following Monday. Other than to tactfully make them sweat it over the weekend. Is it not safe to assume that the desired outcome would be that the employee doesn't show up Monday for the review? Would that not classify as constructive dismissal? I hope I can change your perspective, because constructive dismissal is an on going problem in our industry.
    – Reactgular
    Commented May 10, 2013 at 20:14
  • 7
    There is no way a judge would rule that this is constructive dismissal. You can hem and haw over the letter of the law, but this type of law is there for cases when an employee is being harassed or abused, an actively hostile situation. Based on what the OP is saying, they were informed that they're getting a negative review because s/he's not stacking up against peers as far as bug fix rate; that's a tough situation to be in, but hardly hostile and certainly not illegal. Perhaps the boss could have been more tactful, but feedback does not have to be constrained to official performance reviews
    – pdubs
    Commented May 10, 2013 at 21:22

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!

  • 3
    This is a fantastic response. I'm very impressed. Commented May 15, 2013 at 10:11

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.

  • 4
    "Debugging is twice as hard as writing the code in the first place." - Brian Kernigan (father of C, UNIX)
    – TimG
    Commented May 28, 2013 at 15:05
  • 4
    @TimG: And like every other programmer, Kernigan was underestimating the difficulty. Commented Aug 31, 2013 at 21:30
  • Wow, I'd like to point out, that this is a really tough question and I'm really surprised to see such a good and insightful answer here. Thanks.
    – maksymko
    Commented Sep 2, 2013 at 5:38

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.

  • 2
    ended up getting micromanaged until I was terminated - Well I have just looked at your SO profile and you've clearly bounced back from that, so I find your response heartening. I am going to talk about your first point on Monday - I am receiving bugs from very disparate areas.
    – user90636
    Commented May 11, 2013 at 10:47

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.

  • 2
    yes this is not my code - it's a vast sprawling embedded system, first architected 10 years ago. I think you are right about the patterns - I need to go back to basics.
    – user90636
    Commented May 11, 2013 at 10:55
  • 1
    @BeeBand it would be good to know how you've got on. Hope things work out. Commented May 31, 2013 at 15:20

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?

  • It would be interesting to know if BeeBand has done this already. Reading through the comments and answers it seems it is quite an unfriendly environment. Commented May 15, 2013 at 10:10
  • 1
    Well, I can sympathise with that. I know what's is like to be in a company where the dev team is snowed under with work. Fortunately, though in my case I work with some great colleagues and we look out for each other. Is there anyone you can pair with? Time spent training you and helping you become more productive will pay off for everyone. From the sounds of things you do care and are conscientious so your firm would benefit from keeping you. Commented May 16, 2013 at 15:44

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.


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

  • 1
    The biggest problem with concurrency is that it is a lot easier to write bug-free code than it is to fix bugs in buggy code. Especially if the code is almost correct. And bugs are usually not in one places, but distributed about many.
    – gnasher729
    Commented May 16, 2014 at 14:26

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.

  • I am currently reading it on your recommendation.
    – user90636
    Commented Aug 31, 2013 at 10:16

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.

  • Presumably, it's measured as issues closed/unit of time. It might be reasonable to say "well, some bugs take longer than others", but unless the OP is working in a particularly difficult part of the code and everyone else is doing easy stuff, that's probably not going to hold water.
    – Caleb
    Commented May 10, 2013 at 21:55

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.


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


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.