I had a co-worker leave our company recently. Before leaving, he coded a component that had a severe memory leak that caused a production outage (OutOfMemoryError in Java). The problem was essentially a HashMap that grew and never removed entries, and the solution was to replace the HashMap with a cache implementation.

From a professional standpoint, I feel that I should let him know about the defect so he can learn from the error. On the other hand, once people leave a company, they often don't want to hear about legacy projects that they have left behind for bigger and better things.

What is the general protocol for this sort of situation?

  • make you can make a blog post about it if it is otherwise interesting enough – ratchet freak Jun 12 '12 at 15:18
  • 14
    I would say leave it alone. Your collegue likely does not care what has happened since he left. You owe him nothing by telling him by his mistakes, since his mistakes going forward, are not your problem. – Ramhound Jun 12 '12 at 15:24
  • 6
    Submit it to codinghorror.com. Don't name him, but include enough details for him to identify it as his work when he reads it. – user16764 Jun 12 '12 at 16:45
  • 3
    Did anyone else look at the OP's profile to make sure it wasn't them? Or was it just me... – Adam V Jun 12 '12 at 20:06
  • 4
    @user16764 - I think you mean The Daily WTF? – LeopardSkinPillBoxHat Jun 13 '12 at 1:02

You don't hunt down a former collegue to tell him he made a mistake. You may tell your friend that he made a mistake.

Whether he is a friend or a former collegue is up to you.

| improve this answer | |
  • 38
    Moreover you may rib your friend repeatedly about his mistake--but again that depends on how close a friend he is... – Bill K Jun 12 '12 at 16:42
  • Very profound and concise answer! I wish I could give you more than a +1! – MathAttack Jun 13 '12 at 2:00
  • +1 Seems we think the same way. But you explained it much better. – Fabricio Araujo Jun 14 '12 at 18:14
  • Not just the most popular reply, but the one I was leaning towards when I asked the question. Thanks! – noahz Jun 14 '12 at 18:38

Do nothing.

  1. Contacting someone purely to tell them they screwed up but we fixed it, is unprofessional and no matter how hard you try is unlikely to ever be received positively.
  2. Talking in depth enough for a conversation to be remotely useful about code to non employees is bad regardless of potential NDA issues.
| improve this answer | |

If you're under an NDA, then it's a big no-no to talk to someone outside of your company about any IP-related issues, whether they're former employees or not.

If you're not under an NDA, I'd venture to say that he/she won't care.

That aside, was that person disgruntled? Was it something that could actually have been intentional?

| improve this answer | |
  • NDA or not, I'd hazard a guess that unless this is some basement startup, there's an employee manual and somewhere in there is something about improper conduct, such as airing the company's dirty laundry, that would result in disciplinary action and/or termination. – BryanH Jun 12 '12 at 15:08
  • 1
    I don't think the NDA issue would be much concern if the person you are talking to wrote the code in the first place...the only thing you are disclosing that he didn't know before is that he made a mistake. However, I'd only ever bother telling a friend, not some random colleague I barely knew, or more likely hated. – CaffGeek Jun 12 '12 at 17:31
  • 1
    Wouldn't the former employee still be under NDA? – BlueRaja - Danny Pflughoeft Jun 12 '12 at 19:28

With a mistake that simple, odds are good if it bothered the coworker, they probably realized the issue a couple days later while musing about it. I know I've gone home from work and realized "....crap, that algorithm is totally flawed, I'll have to redo it tomorrow" while unwinding and reminiscing about my day.

| improve this answer | |
  • 1
    I wish I could shut off the brain when leaving. – CaffGeek Jun 12 '12 at 17:32
  • 1
    @Chad I don't, I do some of my best work in the car to and from work. However when I go to sleep... – daramarak Jun 14 '12 at 7:46
  • 1
    @daramarak You sleep? I just enter a subconscious coding state. ;) – Yamikuronue Jun 14 '12 at 12:53
  • @Yamikuronue, haha, nice. I have to remember that phrase. – CaffGeek Jun 14 '12 at 13:35

This co-worker is your FRIEND which you continue to have close contact after the leaving? If yes, talk about that if/when you are taking beers on the bar.

Otherwise, why bother?

PS.: On the NDA thing, what is the secret here? Mr X is the one that wrote the code anyway and if the leaving is recent, the software continue on the same level of disclosure.

Things would be different if this talk happens 3 years after the leaving and you tell things that he wouldn't have to know except for you...

| improve this answer | |
  • WRT NDA, there would be a secret. Could noahz trust the former colleague not to tell everyone that noahz violated the NDA? That's noahz's big secret. – emory Jun 13 '12 at 1:06
  • If is just a colleague, why bother talk about that at all? A close friend that switched jobs is another story. – Fabricio Araujo Jun 13 '12 at 19:54

It depends upon how this person left and your relationship to him/her.

Also, what do you care? I see that you want to help him "learn from the error," but are you really? Are you going to show him the logs* and the stack trace*? Are you going to show him the steps you took to diagnose the issue? Are you going to show him the source* so he can see where the problem was?

If not, then you are probably wasting his time and yours.

*Are you going to get in trouble for disclosing company assets/data to a non-employee?

| improve this answer | |
  • 2
    In this case it's as simple as "you called Map.put(K,V) and never called Map.remove(K) or Map.clear()" - and possibly a follow up discussion about what sort of cache implementation / configuration to use. – noahz Jun 12 '12 at 15:05
  • 6
    @noahz - It sounds like an honest mistake. I would argue not even a mistake worth talking about. The more interesting question is the reason your process failed to catch this bug before it was published onto a production environment. – Ramhound Jun 12 '12 at 15:23
  • @Ramhound - that's a completely different question entirely. I.e. "how do you develop a high-availability, high throughput system on a shoe-string budget?" Do you just fold your arms and tell "the business" no? – noahz Jun 12 '12 at 15:32

If you do decide to tell him be sure that you tell all the reviewers of his code too! They're equally responsible! To me it sounds like you didn't get on with this guy and want to have a dig at him. Let it go, he's unlikely to care.

| improve this answer | |

Probably Not

Seems mostly pointless to me, whether friends or colleagues. And, in some circumstances, possibly harmful to them, to you, and to your relationship with them.

We all make occasional mistakes.

In fact, the only factor that would make me want to tell said colleagues is this: is this a mistake that I know they wouldn't usually do / a situation that I know they would know how to handle?

If the answer is yes, there's no need to bug them as there's probably no educational value for them, so I don't see a duty to inform them. If you run across them one day or plan to have drinks on their last day and you have a good rapport with them as peers and fellow professionals, sure, you could mention it, more to feed some friendly or harmless banter than anything else.

If the answer is no, then there might be an obligation (wouldn't call it a "professional" one, though) to reach out and help them understand their error.

Keep it Civil

Most people don't like criticism about their job in general, developers/programmers even less so, and departing programmers would probably have even a lower tolerance. Why take the risk of annoying them, and giving them the impression that they leave on a bad note?

Sure, if they were bad employees throughout, this doesn't apply, but if they were otherwise sufficiently skilled fellow progammers, I don't see why I would go out of my way to emphasize their mistakes, except if I can be sure we can both laugh it off. Again, assuming they wouldn't learn much from it and just be mortified that they left that behind.


From a different approach angle, if they have left the company, it really depends on your contract and on your company's security policies. You may not be allowed to take about the code (or other things, for that matter) to former colleagues.

Think Positive

Finally, I think that the only situations where I reached out to former colleague to discuss a codebase they left behind were:

  • to request a confirmation on something shady while researching a particular area of the code,
  • to congratulate them on some bit of code I found particularly masterful and that would have made my life worse if it weren't there,
  • to share the good news of a successful launch with them if they left before it happened (or similar big announcements relating to a product they used to work on).

Learn From Their Mistakes

What you can surely do is point out the error to the rest of the team, to ensure it doesn't happen again with the remaining members. No need to point to the actual error in SCM or to the author, it's not a blame game.

It's outside the scope of the question, but I'd still point out that you should make sure to fix the error, document its origins, impacts, and resolutions, and implement a test for it to not show up again, if possible.

| improve this answer | |

It may not be legal to tell someone. Unless the code is open source, let sleeping dogs lie.

| improve this answer | |

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