I have been working on a new project. The project works like this: The end user can access a webapp using a link and he can add multiple systems on his network and manage that particular systems details. My part involves the front end and the webserver, which is done in python. My python actually communicates with another project which is entirely done in c & c++. The c/c++ project is the main app which does all the functionality. My python sends the user request to it and displays the response from it to the user.

I am very familiar with my work and I will finish it soon. Since that's not much work in it. And I am a person who loves to work. I spends most of the time in office and only go home when I feel sleepy.

The c/c++ app is managed by another colleague who has 5+ year experience and can do things much faster than me, but he never does it. May be he doesn't like to do it. His app crashes often when my python communicate with it or returns wrong values. It's full of bugs. Since my app depends on it, I am having a hard time building it. Instead of fixing the bugs, he asks me to slow down my work. He asks me to tell manager that my work needs a lot of time. He is asking me to fool the manager and even forcing me to work slowly like him.

During project meeting, when manager asks him about the bugs he says that he fixed everything and it works fine. Since he is my colleague, I couldn't tell anything to the manager. I obviously need to have a good relationship with my colleagues more than my manager, since most of the time we will be with our colleagues, not with the manager.

I am not able to tell the manager anything regarding this, since if manager asks him why, then he may think I complained about him to the manager. And he keeps on lying in the meeting. And since he fixes the bug slowly, it even slows down my work. Now I thought of working on the front-end part of my app and finishing it off so that in the mean time he can make his project stable. Now he is asking me to tell the manager that my front end part require a lot of work and I may need more and more time, simply so that he can drag the project down. And the sad thing is our actual manager has gone to the US, so we have a temporary manager and this guy doesn't know about the project much, so the c,c++ just fools him.

Can anyone suggest me how I deal with this? I wanted to finish off the project soon. How can I make him work even by maintaining a good relationship with him?

Responses to comments:

If he's really deliberately misleading the company, you should report him to management.

I am new to this company and the other guy has been there for many years. And I have just started knowing my colleagues. If I directly go and complaint him, I don't think so I can make good relationship with my other colleagues. Even he has the power to mislead them. I am not telling he is a bad guy, he can do the work, but he is not doing it.

Doesn't your company have any kind of bug tracking system ?

Here actual bug tracking system isn't there. The company tries to finish off the project as soon as possible and gives it to the QA. And then fixes the bugs reported by QA.

This is why companies should give employees stock / options or some sort of ownership. That way you can literally tell the guy "You are costing me monetary growth... don't you want to make money also?".

The company has the stock options they have given me a 2500 share, mostly he too would have got some more.

Seniority does deserve some benefit of a doubt. You really need to speak to him first and try to understand the problem. He may be out of his depth, you may be able to help him, there could easily be variables you are unaware of. It may be hard now, but you could easily make the situation a lot worse by jumping the gun.

I even does it, first his app wasn't handling multiple requests at a time, he was using a queue to handle the requests I sent to him. I even suggested to him some of my ideas on it. He said he already had these ideas, and will be executing them. His explanations was: "Everything require certain time to do and this is a project which may need two years to complete and we are asked to finish it in two months". I used to have a hard time coding during first few weeks because of this bug. But now he fixed it. But he is using a single queue for a user requests and that is now slowing down the app, since it processes one request at a time.

What is QA doing this whole time? Why aren't they reporting/confirming the status of the project(s)?

The manager is the person who decides when to give to the QA. As of now it has not yet given to QA. He said we should give it by this month end.

  • 6
    How do you know that the C++ guy is faster than you? He could be naturally slow.
    – Job
    Commented Aug 16, 2011 at 19:24
  • 3
    Commenters: comments are for getting clarification to the question and for linking to related resources. If you agree with one of the answers below, up-vote it. If you have a better answer, leave it as an answer: don't leave it as a comment. If you'd like to discuss the topic of this question with others, please use chat.
    – user8
    Commented Aug 18, 2011 at 19:09
  • 1
    @Job there's an assumption that seniority means better coder which isn't always the case.
    – user7433
    Commented Jun 25, 2013 at 19:24

16 Answers 16


You're in a bad situation, I wouldn't want to be in your shoes. It's unlikely that you could to sort it out without getting into conflict with your colleague.

This is what I would do:

  • Don't become his partner in crime. Refuse to lie about the status of your project or his project.

  • Implement (in your spare time if necessary) bug reporting to your application, so all bugs are sent by email to your coworkers and to your manager. If the bug is caused by his application, make it visible in the email (put [XYZ APP BUG] in email subject or something).

  • Maintain a bug database (besides sending bugs by email). You can say that its primary purpose is tracking your bugs, when in fact you'll be tracking mostly his bugs. Among other things, it should track how long it takes to fix specific bug.

  • Have all inter-process communication with his app covered with tests ("when I sent you this, you should return me that" style). You could set up a cron task which runs these tests every day and if they fail, email is sent to everyone.

Basically, try not to waste your time arguing with him about bugs and focus on your work instead. If his app is broken and thus you can't work on your app and manager doesn't do anything with it - well, that's a management problem and you're covered with bug database, emails and test reports.

However, watch out and don't underestimate him. Long-time slacker like him might have a trick or two up his sleeve. He can turn whole team against you or something, but that depends on your specific situation and it's kinda out of scope of this question.

  • 45
    +1 to emphasize that the questioner should never lie about the status of his project. Commented Aug 16, 2011 at 18:02
  • 6
    I was going to suggest a cattle prod but Lukas' suggestions are better! Commented Aug 16, 2011 at 18:21
  • 9
    +1 for 'watch out and don't underestimate him. Long-time slacker like him might have a trick or two up his sleeve'. He really must have...
    – amyassin
    Commented Aug 17, 2011 at 10:45
  • 3
    @Brian, I believe these technical solutions can resolve the relationship problem. Note that the colleague is 5 years senior and allegedly pretty capable developer. Ashin on the other hand is a newbie, so he doesn't have much leverage. In this case it's better to stick to hard facts rather that talking about the problem with colleague(s) and possibly manager. If it's word against word, the manager will probably trust the colleague - or not, but he can't afford to upset him anyway because he might be valuable to company (maintaining legacy systems etc.) Commented Aug 18, 2011 at 17:08
  • 3
    To add to the inter-communication point, fake the external (c/c++) system as well. You have your project, he has his, so don't let his project not being done yet stop yours. Fake the expected results from his service for your application, and write a test that compares the two. I believe Martin Fowler has a good article on that practice, and I can definitely recommend it.
    – cthulhu
    Commented Aug 19, 2011 at 21:34

I'm going to throw in a slightly controversial view: You say that you are working as many hours as you can stay awake. So maybe he's not being particularly unfair to say "you're making me look bad and I'm actually working as many hours as I'm willing to." Maybe he's been there and done that and maybe he burned out. I promise you that you will if you keep that up.

Go out for a drink with him one night and see if you can't build a better personal relationship on which to base your professional. Maybe by his agreeing to put in a bit more and your agreeing to put in a bit less, you can both work together much better.

If I were you, I would also be very careful of this whole "my work, your work" attitude. Between the two of you, you have a product to get out there and this cannot possibly be good for that product, which in turn is not good for either the company or the customer and they pay for both of you to work.

However, I still agree with the other views that you need to revisit the importance of your relationship with your manager and you need to be careful of trusting your colleague. I'm just saying that maybe, just maybe, you need to look at your own actions as well as his.

  • 44
    I agree that working until you get sleepy is counterproductive. No one should work more than 40 hours unless it is a crunch time and certainly not on a regular basis.
    – HLGEM
    Commented Aug 16, 2011 at 18:40
  • 36
    Do consider that if you work 12 hours and he works 7, and you can't advance if he doesn't advance, you might be the one that ends up looking bad. After all, you needed 12 hours to do what the guy just did in 7! So maybe instead of you slowing down or him speeding up, you should ask for an extra project to spend the extra hours on, while you're waiting for him to do his part. Surely there are other things you could be doing/learning/documenting?
    – Konerak
    Commented Aug 16, 2011 at 20:14
  • 4
    This is great advice for ashin. He can (should) of course defend himself with good unit tests, good documentation, CYA type stuff, but as humans we are in this together. Stretch and find a way to approach your colleague - work with him and not on him. Don't be so narrow with "yours" and "mine" if you don't have to draw that line. It might prevent solving this between yourselves. You will have to learn to be open and flexible so why not do it when you aren't overloaded and see if you can make this work without manager involvement. That will surely get noticed without your ever saying a word.
    – bmike
    Commented Aug 16, 2011 at 22:40
  • 9
    +1 for srs. I realize the format is answer the question that was asked, but everybody seems really happy to trashtalk party B after hearing one side of a story that involves at least three people. Maybe party B's output level has been completely satisfactory and in line with his level of compensation for years until new guy who likes to stay at the office 12 hrs and talk about how undedicated everyone else is showed up?
    – Affe
    Commented Aug 17, 2011 at 1:21
  • 16
    @Ashin: Seriously, I understand that early-career desire and I'm not looking to quash it. But I warn you that it does, eventually, lead to burnout and that's not a pleasant thing to go through. Even if you spend your spare time on personal projects, that will help. But someone told me when I started this career that I needed some hobbies outside of coding. I laughed and dismissed him - why would I want to do that? And I paid for it later.
    – pdr
    Commented Aug 17, 2011 at 6:29

Keep records. Document every error you get when communicating with his side, when you asked him to fix and when (if ever) he did it. That is the only way I know of dealing with this situation. So when your manager comes to you asking why things are not progressing you can clearly show without being seen as a whiner or a bad colleague.

  • 5
    E-mail records are especially handy for this. I always follow-up every agreement with an e-mail and always notify when I'm done via mail as well.
    – Pelshoff
    Commented Aug 16, 2011 at 17:23
  • 5
    @Pelshoff - absolutely. Even if every person is in a single room send email documenting your requests and follow ups with cc to the manager. Commented Aug 16, 2011 at 17:25
  • 16
    He asked you not to inform the manager in front of the manager? If he asks you personally, tell him you will do it after clearing it with the manager. Another thing - NEVER give the slightest impression that you are complaining. Always word it in a way that shows you simply stating the facts, nothing more, nothing less. Commented Aug 16, 2011 at 17:40
  • 3
    The problem is that you as an employee have a responsibility to yourself to make the company succeed. And if the company succeeds it should mean that you succeed (raise, bonus, benefits). This person is hurting the company and thus indirectly hurting you. Stand up for the company and yourself :)
    – Pelshoff
    Commented Aug 16, 2011 at 17:51
  • 3
    @Ashin: He can ask you not to cc the manager, but that doesn't mean you must comply. Does he have any authority to do anything if you continue to CC the manager? Also, you can use the BCC feature so he won't know that the manager was CC'd. Commented Aug 16, 2011 at 18:38

I'd like to point out another possibility that hasn't been raised. You say that he wants you to slow down your work. Do you mean literally he is saying "work less hours" or that he is saying "write some tests, test this more, write some documentation" and other things you think will slow you down? I have seen new people run around writing code for 16 hours a day and then complain of bugs in the code they're calling when in fact they're passing invalid parameters, they're not checking return values, and so on. I can't rule out that your co-worker is thinking these things.

The next time you are in a meeting and he says all his code is fine, say "oh, good, the thing I told you about an hour ago, where it blows up when I call XYZ with a date that's not a working day, is fixed now?" One of three things will happen:

  • He will lie, and say there is no such problem, you will say "there is so! We discussed it! I emailed you!" and the whole thing will come to a manager's attention
  • He will tell you that in fact, that isn't a bug in his code, it's a bug in your code, because you're only supposed to pass working days, and you will soon find out what he's been thinking but not saying
  • He will say "no, that one you just told me about I'll deal with today, but everything else is good." If he says that, just thank him for now.

You may learn that your long days of fast coding are not producing good code, and someone (your manager maybe) might translate for the other developer to explain to you what the issue is. Or, you may learn that you are working with a lying snake who will make you look bad to protect his cushy position. Bringing things out into the open can't really make that worse. Or, you may just get enough movement from him that you can stand it, without getting caught up in the politics.

  • 1
    Yea during my starting stage he used to tell that the error is since i didn't pass the correct arguments. And so i created a log in python which will log an info before and after calling his methods. And i will log the arguments i passed and the return status i got. And when again he told me this. I showed him my log file and thus he started fixing his bugs one by one. But the sad thing is he knew it very well , may be he thought of fixing it later , or may be he is not at all testing it. he is just giving out his methods.
    – ASKN
    Commented Aug 16, 2011 at 19:05

What you have is a political problem. First your manager's opinion is far, far more important than you seem to think. This guy is blaming you for the delays and you are letting him. You are the one who will get fired if someone is thrown under the bus. As far as the manager knows, you are the one who is incapable of doing the work in a timely manner.

Protect yourself in any way that you can, through bug tracking, emails etc, but DO NOT go along with pretending this is your delay not his. Never give the boss a fake status report, it will come back to bite you. Tell the boss the truth about the problems you have (and show proof) with his code not working.

This person who is asking you to slack so he doesn't look bad is a snake (well that's an insult to the snake community (subtle Firefly reference), sorry to all the actual snakes out there). He will do anything at all to throw you under the bus instead of him. Do not trust him.

  • 4
    I second this. Bug tracking software is vitally important here. It sounds greedy, but you should never, ever lie to your boss to cover up his faults. This sounds like a very dangerous situation, so be careful about it. The emails with manager CCed is a good idea. And he can ask you to not do that, but you're well within your rights to ignore that, and/or reply to the email and CC your manager on it again, refusing to follow his lead. Very painful for politics, but shows the truth of the matter like nothing else. Commented Aug 16, 2011 at 18:24
  • 1
    +1 for the first paragraph. Also the OP says he wants good relationship with colleagues which somehow implies plural, but is mostly concerned with this unfair guy. Now he's working with that guy, tomorrow other co-workers will be working with that guy and get the same treatment. Addressing the situation will be beneficial to all those other colleagues in the long run.
    – sharptooth
    Commented Aug 18, 2011 at 6:28
  • "Tell the boss the truth about the problems you have (and show proof) with his code not working." But what proof? If the manager doesn't know the project on code/components level then you can't just show him code. In addition, I'm afraid coming to a meeting with the boss with printouts of exceptions will seem like I've too much of "covering my butt" attitude.
    – maayank
    Commented Sep 11, 2011 at 14:01

First and foremost:

Since he is my colleague, I couldn't tell anything to the manager.

You absolutely can and should make sure your manager knows the truth, even if your co-worker is lying to his face. If you don't want to say anything in a meeting with all 3 of you in the room, that's totally understandable. But you should at least pull your manager (the real one, not just the temp) aside and let them know that your work is almost done and is waiting on bug fixes from the other developer's end before the whole application is ready for prime-time. Don't accuse your co-worker of lying, but don't sit there and let your boss operate with incomplete information.

Report your statuses honestly. If your work is being held up by bugs on another developer's end, document that you've found bugs in the C/C++ and have reported them (please tell me you're using some form of documentation that leaves a paper trail).

In the meantime, go ahead and wrap up your work, and let your boss know when you're done. If your manager wants to know why the rest of the project isn't up and running yet, you can refer him to the other developer, and maybe mention that it's probably very complicated/large/requires a lot of testing/other developer is very busy/etc. If you know C/C++, you can offer to help on the main application logic to get things moving with that as well. Yes, you'll be doing the other guy's work, but it makes it clear that you're the employee working hard and being productive, and the other guy isn't, not to mention making you even more valuable to your boss. It may even put some pressure on the other developer to step things up and get them done quicker.

  • 5
    Maybe his software is an order of magnitude more complex than the Ashin's. Taking the hard line with a colleague you have to work closely with but havent bothered to get to know is anti-social, counter productive and very unprofessional.
    – hplbsh
    Commented Aug 17, 2011 at 2:51
  • 3
    The one pays your salary is your company and not your colleague.
    – Rudy
    Commented Aug 17, 2011 at 3:17
  • @lttlrck i agree with you , his app is more complex than me. But its an existing project . Like our company has an existing standalone app written in c&c++ which does the same work. And now they have planned of building it on the web so that user can directly use it without installing. And so as far as i got to know at my initial stage from him and the manager that , they use the same code of the existing project slightly modified and in addition exposing its classes & methods to the python using boostlibrary.
    – ASKN
    Commented Aug 17, 2011 at 4:51
  • 3
    @Ashin k n, the fact that his part of the application is an existing project doesn't necessarily imply that his task is easier than yours. Few applications initially designed for desktop use only require slight modifications to expose them as services (e.g. via a web interface); the changes are often more substantial unfortunately. When dealing with legacy code to change the way it's used entirely, a slight change can quickly lead to a number of unwanted side-effects, even in applications that weren't too badly designed initially. It could explain his more cautious attitude, appearing as slow.
    – Bruno
    Commented Aug 17, 2011 at 12:13
  • 1
    +1 for If you know C/C++, you can offer to help on the main application logic to get things moving with that as well. Commented Aug 18, 2011 at 10:33

There are a number of issues at work. Be aware that:

  1. You are making assumptions about the motivations of other people
  2. You are coloring facts with opinions.
  3. Outsiders (anyone else) are not aware of the history and are not aware of your frustrations with your colleague.
  4. You may look childish if it appears that you are playing a "gotcha" game. Your colleague can probably play it better - after all he still has a job doesn't he?

Therefore, when presenting the status of your project:

  1. Do not mention the other person.
  2. When reporting errors or issues with the code - not the developer. Say "The call to method FooBar() is returning 1 when it should be returning a 2". Then any issue is not a personal attack, you are just talking about code - not people.
  3. stick to the facts that you have proof for.
  4. If your colleague gets defensive or hostile, ask questions. "I don't understand why you think that I should do _ "
  5. Be oblivious to social slights or innuendoes. Pretend you don't get the personal attack.
  6. Get lots of sleep the night before any status meeting, so you are mentally nimble.
  7. Document, document, document.
  8. Don't be shy about asking this guy to help you with some interesting problem, he might take to you if he feels that you respect him. This is about building rapport. (note this is not sucking up - this is something else )
  9. Be prepared to leave if you have to, so that way you are not needy or emotionally trapped. This will help with keeping your head in meetings.
  • 4
    So far, one of the best plans out here. I would only add "go out and smell the flowers" since the "working until I feel sleepy" part sounds scary. Commented Aug 17, 2011 at 19:41
  • @Leonardo -- thx :-) I agree. Work/life balance and all that but sort of beyond the scope of the OP's question.
    – Pat
    Commented Aug 18, 2011 at 0:30
  • +1 for When reporting errors or issues with the code - not the developer
    – Ubermensch
    Commented Jan 14, 2012 at 9:15

"I am a person who loves to work. I spends most of the time in office and only go home when I feel sleepy."

This is not healthy and cannot be expected of colleagues, unless you are compensated to the point of being able to take years off for the inevitable burnout. (Something like >10% ownership in the company or above $200k a year). Maintaining expertise to get to the point where he can develop very quickly takes time. Some of your time should be devoted to developing expertise.

"The c/c++ project is the main app which does all the functionality. My python sends the user request to it and displays the response from it to the user. ... May be he doesn't like to do it."

Python is a more agile language than C/C++. His app seems to contain all the functionality; your app just the UI. More likely than not, these are not equal in difficulty. He may not be producing code quickly; but quality coding is much better than quantity coding. You very well may have unrealistic expectations for how fast he can code in the hours he's willing/expected to work (typically ~40 hr week; and remember if he's been there for years, he's likely accumulated other tasks like managing others or help maintaining older projects that take up a significant part of the work week).

Don't lie for him; but again don't criticize him either. Talk about how his system is great; granted it needs more work until its finished. Give your manager an accurate status update without naming names/assigning blame. Write a mocked-up version of his system that conforms to the same standard that his system should conform to. Make sure your system works perfectly with your mocked-up system with an automated test suite. Then your system can be finished (e.g., it syncronizes perfectly with the mock-up), even if the live system is still buggy.

Then you can write a automatic test suite for his system being called externally that conforms to the agreed upon standards. E.g., test than Foo(1,2,3) gives back a response of "Bar 4 5 6". This could help him identify bugs and speed along his development (and doesn't need to mess with his code). Once those things are done, you'll be able to move on to another project/task (such as helping him with the C/C++ parts).


As others have mentioned, behaving professionally is the single most important thing for your long-term career. And honestly, as long as you behave professionally, you'll be in pretty good shape, no matter how those around you behave.

In this situation, there are a couple of considerations you need to take into account.

First, you need to understand that you are responsible for your program working to the desired specifications, by the given deadline. If your program interoperates with someone else's program, you are also responsible for making sure that that other program also works by the same deadline. To put this differently: If the other person misses their deadline, then you have also missed your deadline, even if your own part of the project was on time. In management terms, this is called owning the inputs.

You have correctly noted that when your colleague declares in a meeting that his program's bugs are fixed, that you can't immediately declare him as incorrect to the manager (your manager would see that as "throwing your co-worker under the bus"; a very bad career move). Others, on the other hand, have pointed out that it is unprofessional not to declare the true state of the project to the manager. Both sides are completely correct.

So if it's bad to contradict your colleague in front of the manager, and it's also bad to not contradict him, then what do you do?

The answer is actually pretty simple: You need to talk to your colleague well before the meeting with the manager, and let them know that at the upcoming meeting you're going to need to tell the manager about the troubles you've been having with their program, and that it's impacting your ability to deliver your side of the project on time, and whether there's anything you can do to help them address the troubles you've been having. You need to have this conversation at least two full days before the meeting where you will tell the manager, and preferably a full week in advance.

In most cases, just telling your colleague that you're going to have to list their program as a risk at a particular meeting will get them motivated to address the problems you're having, and you never have to talk to the manager at all. In others, where the problems are more schedule-driven, the colleague will often agree with you, and the two of you can go to the manager together.

I've never had a colleague who didn't either fix things up for me quickly or else agree with my concerns, when expressed this way. But if it did happen, by giving your colleague advance warning you'd still be in a better position when talking to the manager. Since you talked to your colleague and tried to work out a solution on your own, and warned them well in advance that you would need to raise the issue at this meeting, your colleague won't be surprised when they do, and the manager won't think that you're simply trying to shift the blame.

Do please remember that when you express your concerns, either to the colleague or to the manager, that your concerns are about your colleague's program which is returning bad data (or whatever else it's doing); these are measurable things which can be verified and fixed. Your concerns are not about your colleague being slow or undedicated; these are not measurable things, which may or may not be true, and which are unlikely to be fixed by bringing them up in a meeting in front of the boss.

  • 3
    +1 for stressing that "behaving professionally is the single most important thing for your long-term career".
    – Skarab
    Commented Aug 18, 2011 at 9:06
  • 1
    +1 excellent answer - definitely the best I've seen here yet. A human solution to a human problem. No mention of aggressive bug trackers etc ;-)
    – TrojanName
    Commented Aug 18, 2011 at 12:00

What bug tracking system are you using? I would have expected that at least to highlight where bugs are not getting fixed in due time. Where your code is waiting on input from the other layer, the delays should be highlighted in project tracking documentation. Is this not happening either?

It sounds to me like there is inadequate project management here. You need to a) track the bugs that are affecting you and b) follow up discussions in writing.

Your colleague should not be asking you to inflate your development time to cover his lack of will. At some point, this is something which will have to be addressed with your manager. As things stand, you are covering up for your colleague and that will almost certainly backfire.

  • 2
    Bug tracking system isn't there. The company tries to finish off the project as soon as possible and gives it to the QA. And then fixes the bugs reported by QA. I should even suggest the manager to start a bug tracking system that can solve many issues like these , i hope so.
    – ASKN
    Commented Aug 16, 2011 at 18:21
  • How is QA reporting the bugs - via email? I mean, if you were desperately stuck you could do something so simple as an Excel spreadsheet before going to the trouble of implementing a full bug tracking system.
    – temptar
    Commented Aug 16, 2011 at 18:25
  • 2
    Exactly. Covering up for colleagues can never actually really get you ahead in a company, or at least not in any company with even meager management teams. Commented Aug 16, 2011 at 18:25
  • @temptar - QA reports via email and they even logs the bugs some where also , am not so clear about it , since i been here for just 3 months & this is my first project going on. yea as you all said let me keep records by myself and let me keep my manager informed about this via email. Thanks for the suggestions
    – ASKN
    Commented Aug 16, 2011 at 18:35
  • 2
    @Ashin, you might want to look into Trac or Mantis as those are free bug tracking systems that are relatively simple to set up and use.
    – Tangurena
    Commented Aug 16, 2011 at 19:51

Nothing wrong with sticking up for a collegue, but for someone to expect you to lie to your boss on a daily basis has to go. I could not respect him as a person and would have no desire to have this person as a casual acquaintance. He wants to be an enemy, bring it on.

How can you argue delays on the application layer because of the front end? That's why you do this so they can be separate. What's next, he has even more delays because someone wants to build a mobil front end?

Get your work done. Document any issues you're having with a failure on his app. And then GO HOME! I don't care if you're sleepy or not. Find some friends worth having.


I've just read "The Clean Coder" by R.C. Martin (Uncle Bob). The main point of the book is that programmers in general don't get much respect because they are not behaving professionally. That means mainly that they don't communicate effectively with management about the status of the project.

Lying is certainly a very very bad form of communication. Your colleague is being extremely unprofessional and so are you. You both are doing nothing good to improve the perception of programmers.

I would advise you to go right away to management. However, I have gotten in trouble in the past for having been too "honest" (in some unrelated situation), so I'm not sure you should take my advice. Also, as many have pointed out, maybe your perception of the situation is not as accurate as you think.


It's difficult and unreasonable to estimate the relative effort and complexity of another project if you aren't familiar with the code base. You say his code is error-prone, but it could be in great shape with all of the remaining issues at a very high level of abstraction... Problem is, that is the only code that your front end needs!

Or, maybe he's a bad employee and taking the company for a ride. I can't say, and you may not have all the information you need to know with confidence, either.

I'd suggest a midway tactic. Next time you meet, bring some details of a major bug in his code that is affecting you. When he says everything is fine, politely say there is one outstanding issue that's blocking your progress.

Politically, saying it like that let's you assert that he's not quite correct, while still giving him an opening to play dumb and not be put on the defensive.

Your manager should ask at the next meeting if it's fixed. If not, the pressure falls on him to fix one bug. If it is fix, say thanks, it's working great now, and you found a new blocker. If you want to be especially nice, say you ran into it shortly before the meeting.

You're not lying, per se, nor are you taking sides. You're playing politics by calling attention to problems and letting your colleague save face if things are really not proceeding all that well.

It's tempting to just talk to your manager, but don't forget which one of them you have to work with the most.


Pat's answer was great. I agree 100%. Don't go sneak a meeting with the boss. Either take it with your colleague between 4 eyes or do it with all 3 of you. But Pat's suggestion to focus on the code issues and not on people is the right way to go.

Btw, 40h/week is enough dude. You need to keep your motivation high!


Ask for some else to help you both in integration testing. The person shall be able to say where the issue occurs. As temptar pointed out i wonder why there is not even an excel to track the issues! since there is no tracking, its like every time th other guy is escaping in saying everything is fine as of now! it doesnt work out that way!

Its your module if you need to get it done you need to raise the Red flag on whats causing the delay on ur side. Experience in MERE Years has nothing to do, its just the knowledge and thats what your manager should be insisting on. As said even i feel there is a poor management of project happening here.

  1. Showing initiative by requesting additional tasks and asking how you can add value to the organization is the best way to earn trust.

Your manager might not be technical enough to figure out who is slowing down the project, but they are probably smart enough to recognize that a developer who is actively seeking out new tasking is breezing through their current tasking. This will lead to a conversation where you can make it clear that you are waiting on bug fixes from others on your current tasking. Frame the discussion in terms of how you can add additional value to the organization by efficiently using your free time, not how your colleague is being too slow with his bug fixes.

Not the answer you're looking for? Browse other questions tagged or ask your own question.