13

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?

Improve this question
8
  • make you can make a blog post about it if it is otherwise interesting enough
    – ratchet freak
    Jun 12, 2012 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, 2012 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, 2012 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, 2012 at 20:06
  • 4
    @user16764 - I think you mean The Daily WTF?
    – LeopardSkinPillBoxHat
    Jun 13, 2012 at 1:02

9 Answers 9

Reset to default
112

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
4
  • 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, 2012 at 16:42
  • Very profound and concise answer! I wish I could give you more than a +1!
    – MathAttack
    Jun 13, 2012 at 2:00
  • +1 Seems we think the same way. But you explained it much better.
    – Fabricio Araujo
    Jun 14, 2012 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, 2012 at 18:38
29

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
4

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
3
  • 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, 2012 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, 2012 at 17:31
  • 1
    Wouldn't the former employee still be under NDA?
    – BlueRaja - Danny Pflughoeft
    Jun 12, 2012 at 19:28
4

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
4
  • 1
    I wish I could shut off the brain when leaving.
    – CaffGeek
    Jun 12, 2012 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, 2012 at 7:46
  • 1
    @daramarak You sleep? I just enter a subconscious coding state. ;)
    – Yamikuronue
    Jun 14, 2012 at 12:53
  • @Yamikuronue, haha, nice. I have to remember that phrase.
    – CaffGeek
    Jun 14, 2012 at 13:35
4

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
2
  • 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, 2012 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, 2012 at 19:54
2

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
3
  • 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, 2012 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, 2012 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, 2012 at 15:32
1

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
1

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.

Legal?

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
0

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.