Live data from Hacker News

We fired our top talent. Best decision we ever made

medium.freecodecamp.org

91–100 of 137 posts

Re: We fired our top talent. Best decision we ever made

#91
post #35

I see a lot of red flags in this. I suspect what happened here was Rick was the type of personality that defined himself by being the person who solved problems. He probably wasn't a genius, he was probably just senior and experienced. He didn't want it to end up like this, I bet. I bet he didn't expect it. He didn't know how to say no, and even worse: no one knew that he should. Rick had no peers or management that…

Eh, I've joined 3 or 4 projects where there was a "genius" behind it. They liked being in control, and to a one they all talked about being irreplaceable. I don't know Rick, of course, and can't speculate on what's going on in his head, but he certainly seems like the geniuses on the projects I and others ended up rescuing from their own respective geniuses. I think everyone's quick to pile on the author, for some re…

I think everyone's quick to pile on the author, for some reason

Oh, that's easy.

The prevailing wisdom around here is that management is always, without fail, a bad thing.

Management is either bad because they get in the way by doing anything, or, when a project goes sideways, management is bad because it failed at doing something.

For example, the devs involved in the BMW scandal? Well management told them what to do, so it's management's fault.

And this post? Well, it's management's fault for not stopping this guy.

Re: We fired our top talent. Best decision we ever made

#92
There is a whole lot of anger directed at the company and management regarding this post, and while I agree that it is deserved, seeing the developer in this situation is not "at fault" is also the wrong way of looking at this. My apologies in advance for this rather long rant -- I'm the first to admit that this post, and many of the responses, frustrated me a bit. You can skip to the final paragraph if you just want to understand the source of my frustration.

Management failed, yes. They should have let him go a long time ago and it's at least a little compassionate that they put up with this issue for two years. But, honestly, calls for more direct management involvement always concern me[0]. What really needed to happen is "Rick" needed to better manage himself. The "red flag" of "I build everything myself and don't rely on other code" scares the hell out of me and implies that management were not terribly familiar with developing software.

Use something proven, documented and solid so you don't have to re-invent the wheel. I don't buy that this guy was a "Genius Developer". I won't explain all of the obviously good reasons to using good, proven, third-party options except to say the a large benefit in this case is that others on the team might already be familiar with them and can help out more easily.

And then there's the lack of documentation. I know it's a common thing. I often feel like it's a battle I'm personally fighting all the time with other devs at every level. I mean, is there any language out there these days that doesn't have a doc-comment sort of mechanism that will be parsed by popular IDEs to make using the things you've written easier?[1] It's conceivable that "Rick" fell into the two-year backlog by spending most of his day trying to make sense out of the existing code-base. Maybe he wrote fast algorithms or had an incredible knowledge depth/scope in the given languages but that's intelligence masquerading as genius.

I also take issue with the idea that this guy went from Dr. Jekyll to Mr. Hyde. From reading this, it sounds like he was always a bit of Mr. Hyde -- he was just delivering when the software was simpler to manage on his own. Yes, there are those corner cases where you get a developer who's talent is such that his ability to work with others becomes less important -- those times exist only when there is a corner case that they fit within -- one where they can have a positive impact without creating a large crater in whatever it is they're in charge of. When I've interviewed candidates, though, those are not the people I have ever recommended. I can deal with a non-genius much easier than I can deal with someone who is untruthful[2] or incapable of getting along with others.

It sounds like the company could have had a more active mentoring program between senior and mid/junior level developers. Even recognizing that this individual was a senior developer, getting him involved mentoring those below his skill level could have surfaced some of these issues earlier. Yeah, I get that some developers do not have the personality types to mentor well[3]. But the only issue I take with them firing the individual versus attempting to address the problem after "cooler heads prevailed" is that they waited too long for either. And before I get accused of being a heartless animal, I speak from personal experience here. I lost my job in January of this year. It felt like the worst thing imaginable for a little bit. It wasn't fun. But I am better off, now. I found new employment (and quickly -- one perk for "Rick" is that hiring is out of control right now) and I ended up at a place I would have never found, otherwise. I'm actually doing things that I've always wanted to do and while I loved my last job, I love this one, more. Yes, in my case, I wasn't "fired" -- my rather unique position was eliminated because the company changed directions -- but that's not provable in an interview so I was on the same footing as Rick ... mostly.

It's hard to not see it as personal, but at the same time, people, especially in our industry, are the biggest cost a company often has. Keeping a toxic employee too long can literally be the difference between the success and failure of the entire organization, resulting in the loss of everyone's job and financial devastation for the founders. It's not a company's obligation to detox toxic people, but one way that can happen is by being fired and discovering that your assessment of your abilities and contributions was woefully wrong leading to great personal change. I hope the best for "Rick" as I would for any human being suffering loss, but I'm hoping he's figured out, by now, what he's done that has contributed to his failure and is "relaunching" as a better version of himself. That said, by writing this post, they've made that a lot harder for "Rick".

And that's my final point -- I'm a bit disgusted with the post as a whole. While they to provide "Rick" anonymity, "Rick" and likely "Rick"'s friends and family will know he's been written about. At least in the short term, when "Rick" applies for a job and indicates that this organization was his past employer and that he was let go, they're going to hit up Google, find this post, and likely conclude that "Rick" is "The Rick", causing him to be avoided[4]. Perhaps I'm being overly dramatic, but I find the whole thing to be unprofessional enough that I have zero interest in discovering just what it is that this organization does because I'm not inspired to be a customer or a future employee.

Worse, it's conceivable that they'll have future lay-offs that fall into the category of "reorganization" or "Not The Employee's Fault(tm)" and now all of those individuals might be mistaken for being the "Rick" (if they're guys, anyway). And like many of you other fine folks have pointed out, the post makes it smell like this company has (potentially) serious management/team issues -- the fact that they're celebrating firing someone by calling it the "Best decision we ever made." They "purchased" something at about the cost of a nice 4-bedroom McMansion where I live, lived in it for a year or two, then just abandoned the property for two years and handed the land back to the city who charged them to bulldoze it (the latter being an analogy to the unemployment penalty they're now paying). That's the "best decision ever made"? What do all of those other decisions look like[5]?

Having to fire someone is a huge failure for a company -- It started when you "picked wrong" and hired this person over all of the other choices, you then wasted a large amount of your own/investors money, you've wasted you/your employees time and energy, you've added toxicity to the organization and you've hurt the trust of your existing employees who do not know the full picture. Letting that go on for over two years just amplifies how massive a failure your organization just suffered. Don't celebrate it. That's about as tasteful as dancing on a grave.

[0] This often starts with the "We need a Project Manager". When I hear those words, I can feel the productivity being sucked out of the room and with rare exception (really, at every place other than where I am currently employed), that's been the case.

[1] I'm nuts about this, personally. I write a lot of code and I'm sure there are many among us who fall into the "if I wrote it 6 months ago, it might as well have been written by someone else". I live or die by whatever I put into those doc-comments, so minimally they're present for everything that is part of the API -- if I've written a unit test for it, it's got a doc comment.

[2] "Untruthful" isn't a pleasant way of saying "liar" -- sure, someone who is knowingly dishonest, such as not taking ownership of a mistake that was made or a intentionally misrepresenting the truth is a non-starter, but untruth falls into the category of making promises you can't possibly keep. I'd much rather hear "I am uncertain/haven't researched X, Y, and Z, but assuming that those only present minor problems, I can have the project done by next Tuesday" over "It'll take a week" and having to hear about X, Y, and Z next Tuesday. Everyone slips and, of course, I've made that mistake, but there are those who you simply just assume will let the deadline slip despite what they say and that's grief I can't stand.

[3] And sadly, for much the same reasons as [2], those are developers I shy away from hiring. We work in a field that is a trade-craft and one of the most complicated trade crafts around. And while an ability to mentor as a Junior Developer isn't a requirement, as a Senior/Principal it's a core requirement, IMO.

[4] Some will say "Good, saved that company a lousy hire!" but that ignores two things: People who are bad at one place aren't necessarily bad everywhere -- the whole "not a good fit" thing is real, rather often. Sometimes you aren't at the right place. In addition, when people lose jobs, they often re-evaluate themselves and make life changes. "Rick" might not be "The Rick" anymore but he now can't escape his past as easily.

[5] Yeah, I know, I'm being a dick about a click-bait-y headline; I know they obviously don't mean that, but the flippant nature with how this was presented left a really bad taste in my mouth.

Re: We fired our top talent. Best decision we ever made

#93
post #8

Earlier quoted context omitted.

> AUTHOR: MG This is already in your commit history, so why hardcode it into the source? > FILENAME: functions.php This is obvious because you just opened the file. So again, why even put it there? When the file gets renamed the documentation is no longer correct? These things are also hard to refactor. > STATUS: ACTIVE Every part of the code is always active... > PURPOSE: All of the functions for this application (a…

Avalaxy, while I know companies use tools to do their thing... I don't, I'm old school. I have files on an FTP server and I write PHP code. But to explain: > Author: completely optional, depends on what you are using, you aren't wrong.. since I'm old fashioned, if I were to hire some coder to help me maintain my programs, I'd like to know that he was in there, and I'd have no way of knowing.. again, probably not anyo…

[deleted]

Re: We fired our top talent. Best decision we ever made

#94
post #32

Earlier quoted context omitted.

Avalaxy, while I know companies use tools to do their thing... I don't, I'm old school. I have files on an FTP server and I write PHP code. But to explain: > Author: completely optional, depends on what you are using, you aren't wrong.. since I'm old fashioned, if I were to hire some coder to help me maintain my programs, I'd like to know that he was in there, and I'd have no way of knowing.. again, probably not anyo…

> Avalaxy, while I know companies use tools to do their thing... I don't, I'm old school. You would do well to learn source control system (which these days basically means git). Leaving aside the team/collaboration part, once you learn it, it's so incredibly freeing. I cannot understate this enough. You can make changes to the code, and then go back with one operation (discard changes). You can work on an experiment…

Your status reasoning seems weak. Archive? Version control will have it in history. Maybe rarely you want it around for active references. Otherwise you likely don't need it.

The author bit is solved with version control. Much better than a line that can get bogged down with multiple authors or be outdated.

It doesn't feel like you're being old fashioned or old school. It seems like you're being a bit stubborn in your ways. Version control is a good thing. Perhaps there's better ways. Going your way with not having an sort of real alternative isn't right though.

Your other reasons like coming back years later can be applied to version control too. It's helpful to have commits that have diffs, time stamps, author, and other meta data. Imagine having to come back 3 years later without any of that. Commit history might help you remember and manage your project more quickly, efficiently, and effectively.

Re: We fired our top talent. Best decision we ever made

#95
post #26

The author has the audacity to lay 100% of the blame at the feet of his "genius". Sadly, the author will run continually into new sets of problems again and again at his company and each time find a new scapegoat. This is because 1) he cannot recognize that he is the problem and 2) attacks those who has scapegoated in public. Until the author matures, employees would be wise to run in the opposite direction. If they…

Well, I think the "genius" deserves most of the blame. The company obviously shouldn't have allowed this guy to waste 2 years writing crap, but I don't think it's fair to say that the author of this article is "the problem". That's like blaming someone for hiring an incompetent builder to build their house.

> That's like blaming someone for hiring an incompetent builder to build their house.

Well, kinda, but kinda not, too. When people hire builders they often know little/nothing about building a house and have a limited understanding of what quality building looks like. This company, hopefully, knew what habits a good programmer has (they must have because they eventually realized he didn't have them). Using your analogy, it'd be like a builder hiring a sub-contractor, relying on that sub-contractor to build the house in its entirety, allowing that sub-contractor to slip on the deadline by two years and when the builder went to check up on the sub-contractor, they discover the property has a kitchen, a foyer, a bunch of bedrooms but no roof or walls.

Note that I'm not saying my analogy fits perfectly, nor that "Rick" was actually the negligent builder he's been painted out to be in this but it was as much a failure on the company's side especially when you consider that they've paid this individual for those years of work knowing that it's non-refundable, they're stuck with the house, and the only option they now have is to bulldoze the property and start over. A better approach would have been to step in much earlier and correct "Rick" or get rid of him before a two-year slip in a project could occur.

Re: We fired our top talent. Best decision we ever made

#96
post #89

Earlier quoted context omitted.

I also think it's kind of silly to criticize a solo developer for not documenting. Has anyone seen a mid-sized team that doesn't explicitly delegate or make documentation a priority? Now you expect a solo person to document?

No developer is a solo developer. At a bare minimum, Present You is working with Future You. And Future You would appreciate it if Present You documented your work.

The biggest problem of being a solo developer is that there is no one else to drive documentation needs. Yes, documentation would be great for future you, but present you has no one (including future you) to chat with about the code to get an idea of what documentation would be useful. If you are forced to work just inside your head, then the result is going to be obvious and predictable.

And no, talking to the rubber ducky doesn't help.

Re: We fired our top talent. Best decision we ever made

#97
post #51

Earlier quoted context omitted.

The author is not to blame for the problem of course - since the problem existed before his arrival. The author made the problem worse by implementing the wrong solution. The company was lucky to survive this misstep, and poor Rick was forced to work insane hours just to end up being fired anyway. Not a good outcome for anyone. The company looks bad for mistreating a seriously committed employee. Rick looks bad becau…

>The author made the problem worse by implementing the wrong solution From what I can tell, the author thoroughly investigated the situation, then made the (correct) decision to rewrite the entire thing from scratch. It does seem as if Rick was severely burned out from the long hours, which probably made things a lot worse. I think he shares equal blame along with the company...nobody asked him to do that, and it see…

> I agree it's probably a bad idea to post it publicly.

This. I completely agree with you here. I would take it a large step further and say it was a despicable idea, particularly in the manner it was published as "Best decision ever". Yes, letting the guy go was a good decision and a good correction to a big, expensive, problem. Best decision? Far from it. It was a correction to a massive failure that amounts to paying a few hundred grand, letting a problem fester too long and finally stepping in and "starting over".

Worse, though, is that they've maligned someone in the process. Yes, "Rick" was anonymous ... except to Rick, Rick's family and friends, and probably prospective employers who will know where Rick last worked, who will know he was "let go" from his last job, and who will hit up Google, happen upon this post, bin his resume and pat themselves on the back for dodging a bullet.

Never mind that they've presented exactly one side of a complicated story with all of the biases that come into that. Never mind that a large number of the comments here are from people who correctly suspect that maybe there's something about this organization that caused this massive failure to happen and that those things, whatever they are, might have contributed to Rick failing in his position. And never mind that Rick, now that he's had a bit of an opportunity to reflect, has (hopefully) figured out some of the things he should have done differently and has (hopefully) made positive life changes that will likely cause him to be a fine employee in the future. Or the fact that he might just have not been a terribly good fit there in the first place and could thrive very well elsewhere. The person landing on this post, using basic deductive skills to decide "Candidate X is Rick", will pat themselves on the back for avoiding hiring the developer equivalent of a BOFH. Of course, this company will inevitably lay some other male employee someone off in the future for reasons that are not the employee's fault, and now they might be assumed to be "Rick". There was a small benefit to the world-at-large for them having written this, but it came with huge downsides in the manner in which they've shared.

They could have written the piece as an argument with hypothetical components strewn throughout in more of a philosophical manner including no anecdotal stories about former employees and provided the same benefits, but without the myriad of downsides. It might not have been as interesting of a read, or reached as large of an audience, but then is the conclusion they've drawn really all that mind-blowing? The story, summed up, amounts to "We spent a large amount of money on someone and after two years of continuing to spend that money, we realized that we would have been better off if we had just decided to not work on that project and had, instead, turned that money into cash and flushed it all down the toilet[0]. So we stopped spending that money. Best. Decision. Evar. /s"

[0] Because every once in a while the toilet will plug, and some of that money will come back up.

Re: We fired our top talent. Best decision we ever made

#98
post #69

Earlier quoted context omitted.

I find that brilliant people come from all walks of life. It's not obvious why you would think mental aptitude would translate to healthy, gentle, or sociable personalities. Richard Feynman is known to have a temper, and Einstein was known to be extremely callous in intimate affairs. We've also seen MIT professors display a lesser regard for lesser minds in math. We've also seen brilliant top-of-their field sportsman…

I'm sorry but you're making a massive stretch by implying the either Einstein or Feynman were known as toxic assholes by basically anyone (except maybe Einstein's wives). And while one can of course say that someone is a genius at a sport, I meant specifically intellectually, and even more specifically I wanted to combat the notion that it is common for software engineers to be geniuses and total assholes. I just hav…

There are plenty of geniuses throughout history who were asseholes but still brilliant. EQ and IQ are not highly correlated at all.

Re: We fired our top talent. Best decision we ever made

#99

TBH, I read this as: we mismanaged the project for months (years?), reduced scope creep by negotiating with the client, and finally implemented what should have been the version 1.0 solution while shifting the blame entirely on the loner dev who worked himself into a corner trying to catch up to our sales department's untenable promises. Everyone created the problem, the dev was an easy target to eat the blame becaus…

This thing reminded of a sketch I saw sometime ago:

https://www.youtube.com/watch?v=BKorP55Aqvg

Re: We fired our top talent. Best decision we ever made

#100

TBH, I read this as: we mismanaged the project for months (years?), reduced scope creep by negotiating with the client, and finally implemented what should have been the version 1.0 solution while shifting the blame entirely on the loner dev who worked himself into a corner trying to catch up to our sales department's untenable promises. Everyone created the problem, the dev was an easy target to eat the blame becaus…

Let's understand the context... The author has spent the last 10 years in University IT. Easy to see how it takes years to realize something is out of control and not managed well.
Post reply on HN