My situation is as follows, I am an entry level programmer having been assigned my first real project.

I'm supposed to be part of a 3 man team which develops a new part of the application, the others being a fellow new employee I was partnered with during the training and a senior programmer who trained us.

The problem is that during the first stages of the project the senior was pulled into other projects and we juniors had to do things as we knew (it's a new technology for the firm, and that's why we juniors were "apprenticed" to this senior).

And we made mistakes in the code, in our workflow and we didn't progress at a good speed.

What is causing me stress and trouble at the workspace is that I feel I'm being singled out for errors both we juniors did.

My junior colleague works only part time due to still being a student, yet our supervisor only comes to check the code when he is away and I end up taking the blame for shared problems in the code and his own problems in the code.

There's only so many times I can say "This is X's area of code, but I'll try to fix it!" then fix it,eventually I just silently note down the problems whether they are in mine/his/shared and get to fixing it.

Yet I am the face the supervisor sees when the code is found faulty and I'm right now solidly established as the "slow and sloppy" worker.

To add insult to injury after fixing the errors in my and his code, I still put in the hours to add new features to the project. These features get tested first and problems are found. Meanwhile, my colleague's work sits there untested, accumulating fixes I already figured out, resulting in work which seems faster and more error free than mine.

How can I explain my point of view without looking like I want to throw my colleague under the bus ?


Just wanted to add some clarifications, yes we are using source control for the code, but using the blame command to show the errors in my colleague's code raises the same problem it shows that as a programmer my code is not uniquely flawed yet it marks me as the coworker who is trying to share the blame.

  • 3
    Is this code in any kind of version control repository? When fixing issues, simply log the revision where the original error was made - a look over the logs (and using something like svn blame) should highlight who was responsible for errors - unless you are pair-programming and/or using the same credentials.
    – HorusKol
    Commented Jun 11, 2014 at 23:57
  • If you found any of our answers helpful please star it so we can help others in the future.
    – Philip
    Commented Jun 13, 2014 at 0:17

4 Answers 4


I suggest simply taking note of the problems and fixing them. You are the full time employee and a code base is a shared responsibility. There is a method of fixing the bug without being blamed for it.

I would listen to the manager and say you'll take care of it. Honestly; before adding new features I suggest fixing as many bugs as you can - bugs derail projects quickly.

Assuming you're using the DCVS or some form of source control the managers can track whose code is whose. They may just be telling you about the problem because you're the main employee. Look at it as an exercise to test your managerial skills and delegate tasks down to the intern.

If QA is finding the bugs in your code - be ok with it. That is QA's goal. Programmers tend to do a base test and assume something is "good enough" and ship it. This is where new programmers fall into a bit of a hole due to academia being more of "proof of concept" and less defensive (production) coding. Learn to extensively test your product - especially for negative or bad input, not just the "good" input.

Another suggestion is to improve some aspects of your coding practice. I was in a similar situation as an intern programmer.

If you're both "new" to this and he only works part time I encourage you to try Pair Programming. That way you have collective ownership of the code base and the problems are both yours and you won't be able to assign blame to him.

Overall; stay positive! Try to avoid excuses and take as much constructive feedback as possible. Even if you're fixing his mistakes you're still becoming a better programmer. You're gifted with a tremendous opportunity to prove yourself and the first few months as a programmer are rough and humbling; I know you can pull through!

  • +1 for : " You are the full time employee and a code base is a shared responsibility."
    – Luke
    Commented Feb 14, 2016 at 23:38
  • +1 for defensive programming and extensively testing your work yourself. When I read I still put in the hours to add new features to the project. These features get tested first and problems are found. in the question I was wondering why problems are only found after the code is checked in... Commented Mar 4, 2019 at 13:23

A good strategy for you is to think about this from the point of view of your manager and your customer (the one who will use the code your team is creating).

Your manager is in a risky situation. Think of it: a new technology stack, one junior full-time employee, one junior part-time employee, and his more senior employee abruptly reassigned. From your manager's perspective, this looks like potential trouble.

It's possible your manager is giving you extra attention simply to do his best to avoid disappointing your customer. If so, who could blame him? He's doing the right thing.

Can you have a conversation with him where you establish some common cause?

"Sir, I feel like I'm falling behind on my work because the two of us are still learning, and because I have to spend a lot of time debugging and integrating our part-time colleague's work as well as my own. What can I do differently to help make sure this project succeeds even though it's just the two of us working on it?"

See how this goes? (1) You state the problem from a business and management perspective. (2) you express understanding of a team development process (3) You ask for advice. Managers LOVE IT when employees ask for advice. He will surely be happy that you see the problem from his point of view.

Don't be overly worried about bugs in your new code. All code has bugs in it, and the good news is that your development process is finding your bugs.


Don't worry about how your colleague is perceived. Take this opportunity to get the credit for fixing everything that needed to be fixed, it will only make you look better for taking it in stride and just getting it done. Don't worry about the quantity of bugs at this stage. Every bug that qa finds is a free learning experience for you, and money the company saved by not having the problem in production. Given that your colleague is not full time, it is highly likely that you will be looked upon to shoulder a greater burden, which is a GREAT thing at the beginning of your career. This is an opportunity.


To a large degree, welcome to the world of work I'm afraid. Things aren't "fair" and if you keep on complaining on that basis you will perhaps trade the mantle of "sloppy and slow" (is this what your senior colleague has said, or a label you are applying to yourself because you're taking their oversight personally?) for "complains all the time" which is worse. Instead of worrying about blame you need to take charge of fixing the root cause of the problem. It sounds like you and your fellow junior are overwhelmed and not managing time well yet.

Do you have bug tracking systems? Can you implement one (even if its just a spreadsheet)? Can you take responsibility for noting all the bugs and then assign the ones that are down to your co-worker back to them to fix?

Using a tracking system, and sharing it with the senior dev when they mention faults should start to push back against the negative impression others may have of you. Also speak to the senior dev and (without getting into 'blame games' talk about what their expectations are of you as the person who is there all the time vs. the one who is not, and also what their expectations are for producing new code vs. fixing bugs with old code.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .