I am putting this question to C++ programmers because: a) Only a C++ programmer can judge the technical merits of the examples; b) Only a programmer will have a feel for the temperament of another programmer who writes code like this.

HR and the directors are aware there is a problem simply because they see evidence in the field. It's my call whether we give the programmer in question more time. Many of the errors are at a very basic level - my question (to programmers) is whether someone who professes to be a senior C++ developer should be given a benefit of a doubt based on samples of their current code. Non-programmers - even people outside C++ programming - can't make any judgement on this.

For background, I've been assigned the task of managing developers for a well-established company. They have a single developer who specialises in all their C++ coding (since forever), but the quality of the work is abysmal. Code reviews and testing have revealed many problems, one of the worst being memory leaks. The developer has never tested his code for leaks, and I discovered that the applications could leak many MBs with only a minute of use. User's were reporting huge slowdowns, and his take was, "it's nothing to do with me - if they quit and restart, it's all good again."

I've given him tools to detect and trace the leaks, and sat down with him for many hours to demonstrate how the tools are used, where the problems occur, and what to do to fix them. We're 6 months down the track, and I assigned him to write a new module. I reviewed it before it was integrated into our larger code base, and was dismayed to discover the same bad coding as before. The part that I find incomprehensible is that some of the coding is worse than amateurish. For example, he wanted a class (Foo) that could populate an object of another class (Bar). He decided that Foo would hold a reference to Bar, e.g.:

class Foo {
    Foo(Bar& bar) : m_bar(bar) {}
    Bar& m_bar;

But (for other reasons) he also needed a default constructor for Foo and, rather than question his initial design, he wrote this gem:

Foo::Foo() : m_bar(*(new Bar)) {}

So every time the default constructor is called, a Bar is leaked. To make matters worse, Foo allocates memory from the heap for 2 other objects, but he didn't write a destructor or copy constructor. So every allocation of Foo actually leaks 3 different objects, and you can imagine what happened when a Foo was copied. And - it only gets better - he repeated the same pattern on three other classes, so it isn't a one-off slip. The whole concept is wrong on so many levels.

I would feel more understanding if this came from a total novice. But this guy has been doing this for many years and has had very focussed training and advice over the past few months. I realise he has been working without mentoring or peer reviews most of that time, but I'm beginning to feel he can't change. So my question is, would you persist with someone who is writing such obviously bad code?

  • 15
    If you already saw that he was writing bad code, why have you let him write his shit during 6 months without supervising him ?
    – BMN
    Jun 26, 2013 at 14:18
  • 4
    IMO, when you see someone doing bad job for a while, you CAN'T let him work alone even if it's only debugging / repairing. If it is your will to keep him into your company, you HAVE TO supervise him and AFTER see if you still get bad results from him. Letting him work alone during 6 months without looking at him is IMO a bad management.
    – BMN
    Jun 26, 2013 at 14:37
  • 3
    @user94986 Then if you spend time with him, explaining him that his habbits are bad, you should keep an eye on him, and if nothing changes, don't wait 6 months to speak to him.
    – BMN
    Jun 26, 2013 at 14:51
  • 4
    If he doesn't think that memory leaks are a problem, there is no sense to teach him how to avoid them and give tools assisting with this. The main problem may be that he incorrectly understands goals and requirements for the product.
    – maxim1000
    Jun 26, 2013 at 15:41
  • 2
    This question appears to be off-topic because it is about what is effectively HR legal advice which is problematic for us to provide at best.
    – user28988
    Jun 26, 2013 at 20:44

8 Answers 8


My advice would be to confront him about this particular example and see what he says. If he denies there being anything bad with the code, then I'm afraid there is little you can do. If he accepts that he made a mistake (even if he's defensive about it), then at least there is room for improvement. If you accept the time and effort on improving him, then you or a senior programmer will need to sit him down and code together until all these tendencies are flattened out (be prepared to dedicate this person for at least 1 months time).

A bad programmer, I can usually work with, but a programmer who can't improve, I cannot.

  • 12
    +1 for "A bad programmer, I can usually work with, but a programmer who can't improve, I cannot."
    – user4234
    Jun 26, 2013 at 16:08
  • Yeah, also, I would let the guy know it's pretty serious. It sounds like he hasn't been told or hasn't acknowledged that there's a problem for years. Come to the conversation ready to point out examples of stuff he shouldn't have done and how it impacted the quality of the app. If he's still not willing to fess up to a problem with his code, I'd probably let him go. And I probably wouldn't give him a lot of time to get his act together if he did. You definitely need to underscore that his future at the company is at stake and that he's lacking in a pretty critical skill for a C++ dev. Jun 26, 2013 at 16:11
  • @ErikReppen I agree, but I also think programmers can be the most stubborn types of people on earth. If you push too hard, he may deny any problems with his code simply due to being defensive. I think it's important to emphasize the gravity of the situation, but I would still try to sympathize with him "I happened to notice this little mistake. Did you happen to catch it too? Do you suppose you made this same mistake in other areas of your program?"
    – Neil
    Jun 26, 2013 at 16:20
  • @Neil The only way through a wall of stubborn is a kick in the ass. And I speak from experience as the stubborn ass side of that equation. That said, if it's the first he's heard of there being an issue with his code, yes, I'd go a little softer but it sounds like they've tried to communicate an issue at least once before Jun 26, 2013 at 16:24
  • @ErikReppen Maybe, but you risk that he shapes up just to get you off his tail. At that rate, you might as well say "Shape up, or you're fired." At least this approach finds out if he's conscience of his errors.
    – Neil
    Jun 26, 2013 at 16:43

So my question is, would you persist with someone who is writing such obviously bad code?

No. I would fire any professional C++ developer that lacked the basic understanding of memory management.

If it's someone coming from Java or C# or something I'd give them some lattitude, but this is pure incompetence.

  • 9
    I can't understand how this answer can be upvoted. Firing someone is not a matter that should be taken lightly. Jun 26, 2013 at 18:39
  • 3
    @FlorianMargaine - Sure, but this seems like a clear cut case. How much is this employee costing the company in lost sales due to memory leaks or security vulnerabilities? How much in lost time to testing/fixing this crap? How much in having the OP babysit them? How much in having other programmers' suffer from his mere presence? Unless the employee has an absurd amount of domain knowledge (or blackmail), there is no way that replacing them is more costly.
    – Telastyn
    Jun 26, 2013 at 20:43
  • 1
    @FlorianMargaine, This type of employee is who doesn't get fired enough, it cripples the company in difficult to fix technical debt. It says in big red lights, "They don't care, so why should we?". Know what the employee you really want would say? "... but i do care, so I need to go to a place that does". The bad ones already didn't care, so they remain at your office. You MUST remove people who hurt productivity, more than they contribute. This isn't a choice taken lightly, however it really is a clear line, failure to act is a clear action. Jan 13, 2018 at 17:38

We can't answer the broader part of your question. Namely, should you retain or fire that employee. Firing an employee is difficult, but that's a decision outside the purview of a community like this.

You updated your question to restrict answers to C++ programmers. For my background / qualifications: I cut my teeth in C, and I can code in C++, C#, and Java. And I like to chase race conditions between threads because I think it's fun. Yes, I "get" bit twiddling.

Your answer and decision wraps around this: Whether or not someone can change depends upon the individual and if they want to change.

But let's start with some questions of you:

  1. Have you asked him about the code and the example you mentioned? What was his impression of the review?
  2. Did you give him specifics during those 6 months about understanding memory manipulation and making sure his code didn't have memory leaks?
  3. Were you providing reasonably frequent feedback during those 6 months to indicate whether he was making progress or not.
  4. Did you explicitly call out that his old way of coding was no longer acceptable in new code?

You need to make sure you can say yes to all of those questions. If not, there's still a burden of proof upon your part for communicating with him.

His response to your recent review is going to be the most telling part.

If he's been trying, and shows some signs of progress then maybe you need to review your mentoring process. If anything, maybe you need to consider pairing him with a more experienced programmer so he can get some immediate feedback while he's making design decisions. I'm not a fan of pair programming, but it can be very useful in a case like this. Continually sending him off to make more and more revisions to old code isn't always a practical route for learning.

If he hasn't been trying, then you need to understand his motivation better. Did he not understand that he needs to try harder? Does he just not care? Are there other areas on the team where his skills would be a better fit and he's more interested in that? If he didn't care to try, then you need to understand why.

From there, you'll know whether he wants to change and whether he can change. No desire to change is equivalent to not being able to change. If there's desire and a degree of progress, then strongly consider changing how you are trying to rehabilitate him.

  • 1
    +1 for "Continually sending him off to make more and more revisions to old code isn't always a practical route for learning"
    – Bill
    Jun 26, 2013 at 20:44
  • +1 for the last paragraphs. Progress achieved by someone versus effort invested in guiding that someone both need to factor into any judgement of performance. Jun 26, 2013 at 20:56

I'm afraid his bad code is not the only problem in your team.

  1. Who reviews his code? Why did he slip away without a warning for accepting code with memory leak vulnerability?
  2. Why didn't stress tests find this problem? Do you use them? If yes, then why aren't they working?
  3. He was left unattended for a long period of time. Why?
  4. He's not using the tools you gave him. How did you motivate him to start using proper tools?

You say he's been in the company for the extended period of time. Firing such a person is rarely a good idea (unless he's a Wally-type of employee). Their knowledge of client needs, products you own, etc. is often much more valuable than the code they write.


  • move him to QA to let him learn what to avoid
  • pair programming with someone who can point out his errors
  • extended QA effort on his code
  • make him write stress tests, if he sees his dev machine crashed after creating and destroying 10k of objects maybe he'll learn
  • a few/all of them above :)

Making a decision to fire anyone is a hard decision for anyone to make. Your situation though is compounded by several factors:

  1. It appears that this developer has been in the company for several years
  2. The developer writes all of the companies C++ code
  3. It appears that before you no one ever discussed the level of poor code with the developer
  4. As a new manager you have no idea of who/what the developer knows in/about the company and what the political ramifications of firing the developer are

That said you have spent the last 6 months showing the developer the error of his ways and his new code has not yet improved.

At this stage you really need to start some proactive management so that within 3 months you have

  • A decent C++ programmer who knows what he is doing


  • Terminated the developer.

In order to do this though you need to sit down with the developer, explain what is wrong in writing/email, explain how the developer can improve and very very clearly state that if there expected improvement does not materialise then he will be terminated in 3 months.

You also need to be very clear that the improvement is expected from this point on for the rest of his employment with the company and not just for the 3 moth period!

You should also inform your own manager and the HR Department (if any).

During this process you will have to actively manage the developer and review tasks/code every 1-2 days and ensure they are up to scratch, detailing those that are not and explain what can be done to improve them.


Either you haven't been clear about how seriously you take his poor workmanship (i.e. it's possible he sees what time you've spent with him as an option if he wants to improve rather than an absolute necessity), or he has an incredibly bad attitude that's unsustainable. If it's not already clear to this developer that you're considering his position over this issue, then it needs to be spelled out (assuming your leadership are ok with your authority to terminate). The shock will hopefully bring about change.

The employment decision has much wider implications than just this guy though, you need to consider the impact upon the team. If his attitude is allowed to prosper, it can provide either resentment from others or have others feel that this sort of thing is ok too. From the team's angle though, it has to be absolutely clear that if he did go, it was for the right reasons and he had ample opportunity to improve.

One gem I picked up on a course years back is the fact that people with technical knowledge that others don't have can lead management to give them slack. It's bad for the team. You may be fearful of losing the only c++ developer, but they can be replaced. Obviously there are inherent risks if he knows the released products well, but often I've seen people with seemingly irreplaceable product/technical knowledge replaced more easily than anticipated. Teams and organisations can often fill in gaps that initially appear tough to fill. Of course if he doesn't have c++ skills or organisation specific knowledge that you think will be tough to replace, there's much less of a problem!

  • 1
    I suspect this guy woud be absolutely flabbergasted to find out that his manager is thinking of firing him. Some people you just have to hit over the head with a plank and flat out tell them that they have to improve or they will be fired.
    – HLGEM
    Jun 26, 2013 at 17:06

Of course you should not. Remember, this is not a charity, you are exchanging money for work. If he isn't holding up his side of the deal then like any transaction I'd stop paying.


If you want to give him a chance, develop a standardised test that gathers metrics on memory leaking. Monitor his progress on a weekly basis, insisting on seeing the code that he changed, and look for improvement. If he can't manage at that point, sack the useless invective.

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