
We fired our top talent. Best decision we ever made - mooreds
https://medium.freecodecamp.org/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde
======
wakeywakeywakey
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
because of his ego.

"We could not build a hotel, so we bought new hammers and built a great dog
house instead."

~~~
mattbgates
I think I have to agree with you. The fact that Rick was allowed to be turned
from a Dr. Jekyll to a Mr. Hyde is kind of the company's fault. No one stepped
in to hold Rick accountable during meetings?

While I no longer work there, my first job with some programming had me
training to understand the code, what it was about, and even how to write it.

To this day, I still use this method so I don't get lost or bored in my code.

These are the lines I actually use along with commenting my own code just in
case I have to return back to it weeks or months or even years later, I don't
have to try and trace every step back to a particular code.

    
    
      // AUTHOR: MG
      // FILENAME: functions.php 
      // STATUS: ACTIVE
      // PURPOSE: All of the functions for this application (app name)
      // NOTES: There are several unused functions in this file that are commented out but once in production
      // They can be deleted as we likely will not be needing them at all.
    

Those 5 lines have saved me a lot of time. While I don't include the "author"
line since it just me writing the code, if there are tons of hands in there,
you should know EVERY SINGLE author as well as when code gets commented, it
should contain the initials upfront, such as // mg: this does this and this
does that. If I know multiple files touch.. I also add: "ASSOCIATIONS:" and
list all files that call this one.

Using this method, I've been able to complete a bunch of projects much quicker
because any time I start to forget: what am I doing? what does this code do?
am I on the right track? I can look right at the beginning of a file and know
the answer.

I'm not saying that a boss or supervisor has to be a micromanager, but
meetings are necessary to understand where everyone is at. Leaving a
programmer to do his own thing means that he really is doing his own thing and
is more likely to get lost in the code. I'd say more like he wasn't a genius
but thought he could do it alone.. and sometimes, it is nice to have someone
step in and tell you: "Hey where we at? What can we do to speed this up?" or
even provide their own insight... I can't tell you how many times I've talked
with my spouse about an issue.. and she's suggested, "Why don't you just do
this?" and it has saved me hours of time just because of someone not in the
code is able to see another solution.

~~~
Avalaxy
> 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 (app name)

Okay, probably the most useful one here. But what if we're refactoring the
code and the purpose changes? Or if someone adds a few functions and the
documentation no longer covers the purpose?

> NOTES: There are several unused functions in this file that are commented
> out but once in production They can be deleted as we likely will not be
> needing them at all.

Very dangerous, again because the source might change while the documentation
doesn't. But why even write "they can be deleted"? Why not just delete them?
That's what version control is for.

~~~
mattbgates
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 anyone's issue, but I'm old fashion.

> Status: Not all files are in use, but sometimes they are just leftover and
> may not be deleted, or sometimes, they might be used for testing purposes --
> so Status can be changed to INACTIVE, TESTING PURPOSES ONLY, etc. Maybe the
> file is inactive because newer code was written, but this was kept as an
> archive? You never know.

> Purpose: always state the purpose of the code.. if it changes, than this
> should probably change. If it doesn't, than again: you must be doing your
> own thing.

> Notes: optional, this is just notes that might be necessary..... again..
> Notes to myself: I have some code in there that is not currently being used
> and if I go into production, I probably won't need it so may as well delete
> it.

The Notes weren't supposed to be taken as a literal. This is just notes to
anyone who reads the file.

Sure, there is a such thing as too much commenting, but no one wants to go
through the code to figure out what it does. Leaving a little comment up top
of every page, regardless of the simplicity or complications of the function,
it is just nice to leave for anyone who has to go in there. It's a better form
of organization. Imagine having to go in there 3 years later... would you
remember what it does? The little statement up top might help you remember
more quickly.

~~~
gregmac
> 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 experimental idea (in a branch) for a few
days/hours, then switch back to your main code to fix an important bug, go
back and finish your experimental branch eventually, and merge everything
together -- often with nearly zero effort. If you're supporting multiple
release versions at once, you can fix a bug in one and often easily apply it
to all other versions.

Ever have a situation where something just stops working, but you're not sure
when other than in worked four months ago? You can arbitrarily check out any
old version and test, and even - in a single operation - undo that change from
the current version of code.

Can you do all this without source control (or with copies named by date)?
Sure, but it's kind of like the difference between fetching water from a well
using a hand pump and bucket vs having running water and being able to open a
tap. Before you have running water, it's just life, and it's not that big a
deal to fetch water, really. Once you have it, you could never imagine having
to live life that way.

~~~
mattbgates
I do know what "source control" is but even when I wasn't working for myself,
my boss made me still add this stuff, despite knowing at the end, upon saving,
it would ask what changes were made.

We used something called "Source Safe" from Microsoft.

As for what's in the Notes and deleting it upon live production... that is the
old stuff... in case the new stuff stopped working for whatever reason.

I guess we all have our own methods of doing things. Fortunately, I've not had
major issues, though everything is backed up to it a server upon my completion
of work for the day.

~~~
megaman22
Man, you're banging rocks together and working hard, rather than smart. My
sympathies for being stuck with a crapfest like sourcesafe.

------
KirinDave
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 could even faintly empathize. They didn't get
that there was simply too much to do.

Rick's first and biggest mistake was long before his absurd outbursts:
refusing to admit the project was too big before it was too late. Instead he
imploded and started saying stupid and offensive things. He defined his
identity by his ability to solve problems but no matter how much he tried, the
problem seemed to get worse.

He got fired. He even deserved to be fired, I think. Because part of being the
technical adult in the room is NOT letting it get that far out of control.

The ugly part is that it seems no real lessons have been leared by the org.
Instead of recognizing the obvious lack of technical management, they're
spreading the responsibility across the entire org. Intead of owning their
business logic they called up vendors and sold it to them. Instead of broading
the scope of the business with these added capabilities early on the entire
business is now balanced on top of a pinhead of those few cases.

Everyone made terrible mistakes. And it seems like no one learned from them.

~~~
Frondo
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 reason, but the Rick
side of the story just rings so many bells for failing projects I've joined
(or, later on, took over and reimplemented by myself).

I'm no genius, either, just old enough to know a little tiny bit better.

~~~
KirinDave
Please don't take my analysis as a way to absolve Rick. He's the worst type.

~~~
Frondo
Ok, fair, that's good, I think we probably agree more than disagree then.

I guess my take on it is that the handful of Ricks I've seen, they all wanted
to position themselves as irreplaceable, as kings of the project. For them it
was intentional.

Maybe not the case with the Rick in this story. Without knowing the person (or
even if the person is real, or if this is a composite character from multiple
situations, etc), we're all just guessing.

I'm just more inclined to sympathize with the author, because of my own
experiences with Ricks. :)

------
alistproducer2
Rick was not managed - at all. Rick became a monster because no one at the
management layer was doing their job. If you're letting coders write custom
tools instead of procuring where possible, that's management's fault. The list
of mismanagement goes on and on. Sure Rick was a douchebag. Anyone who has
spent any time in a cs program has met a potential Rick. The fact that you
fostered one while he almost blew up your project is your failure, not his.

Edit: also if 90% of his code was able to be thrown out, then I don't think
Rick was ever the super star that you or he thought he was.

~~~
shoo
There also seems to be a vacuum of project management.

No one had the hard discussions with clients to reduce scope and cut high
effort/low reward features?

They knew he was working 80 hour weeks and didn't take steps to address that
early.

~~~
munin
> No one had the hard discussions with clients to reduce scope and cut high
> effort/low reward features?

They did as soon as they had someone to blame, though.

------
davmar
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 don't the next article will be about one of them.

~~~
cpncrunch
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.

~~~
6nf
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 because the author decided to slag him off in a public blog
post

The author looks bad because he's oblivious to what he's done and instead
decided to shit on a really dedicated employee for the failures of the
management team.

It takes some serious lack of perspective to post something like this on your
public blog. Ugh. I feel sick.

~~~
cpncrunch
>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 seems to have been mostly caused
by Rick himself. The company should have pulled the plug earlier, but they
must have trusted him.

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

~~~
mdip
> 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.

------
josephg
I've seen this sort of thing happen before, and I think there's a big danger
in leaving senior engineers lonely in a company.

Imagine how differently this would have played out if 'Rick' had someone at
their technical level to talk to. They could bounce ideas off another person
and they could help field questions from the team when busy. It sounds like
Rick made some potentially questionable technical decisions - but with another
very experienced dev around they could keep each other honest and on point.

The problems that come from having only 1 junior dev on the team are obvious -
that person will feel alone and out of their depth, and like they're bothering
everyone with their problems. But there are similar issues from having only 1
senior dev on a team. That person will naturally try to take responsibility
for every aspect of your technology stack. They will do that naturally because
the only other option they will see is to let mistakes slip in to the product.
And a technical leadership position is a leadership position. Being a good
technical leader requires time away from programming to mentor, code review
and brainstorm. It requires you to hold meetings, support your team and keep
others accountable to standards. The people side of that is a set of skills
many programmers don't have.

Ultimately by firing that person you're saying that your team cohesion is more
important than quality in the product. Thats a totally reasonable choice. Its
also an option that a skilled manager would be able to bring Rick on board
with. "Hey Rick, over the long term we want to build an amazing team. You're
the most skilled person we have, and we think in the long run the mentoring
you've been doing is going to provide more value than getting this particular
iteration of our product out the door. We want you in on the long term vision
of our company having great engineering, which might mean this next release
slips - but we think extra mentoring will be worth it. What do you think?" ...
Etc.

------
quickben
I'd reword the title:

"Multi-year management failures result in huge time and resource company
expenses".

Outside of that, I'd also fire the person that wrote the article on company
image tarnishing grounds.

He may be proud of his decision, and it may have been the right thing to do,
but considering what he wrote publicly, anybody sane would stay away from them
now.

------
wdewind
Everyone is commenting on the mismanagement angle here, which is very real,
but I think it's also important to point out that the author is simply wrong
about "Rick" being a genius if the descriptions of his behavior and work
product are accurate. I think there's a huge myth about solitary geniuses who
are assholes. I've yet to meet someone I consider really genius who is also a
toxic asshole. Maybe occasionally you run into geniuses who are a little shy
or socially awkward, but by and large the defining factors of the true
geniuses I've worked with have always been a desire to share with the team,
improve everyone around them and contribute deeply to the product. Their code
is maintainable and other engineers totally get it and when they don't the
genius is there to walk them through it, taking notes on how they can make it
easier to understand next time. They hate the idea of being a dependency/SPOF,
and they are extremely accountable for very real and obvious progress.

I've also worked with people genuinely like "Rick" from the article. It
usually takes about a week to find out that they don't actually write any code
or contribute to the team in any meaningful way besides making noise. People
who are that wrapped up in their own ego _cannot_ make meaningful
contributions to their teams.

It lends more weight to the idea that there was a ton of mismanagement going
on at this company that beyond the bullshit described in the article, the
author still considers "Rick" to be a genius.

~~~
threatofrain
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 display great arrogance and disregard to lessers. The
guy who writes "The Haskell Book" isn't known to be nice, but people still
acknowledge that it's one of the top texts. Linus Torvalds isn't known to be
nice.

You might not consider these people to be "geniuses", but they are certainly
brilliant in some way, participating heavily in their field in some way.

~~~
wdewind
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 haven't seen that frequently, and in fact usually the pattern
is that the engineers who are typical assholes are, correctly, the least
secure in their own skills and try and mask that with needless complexity (in
code, communication etc).

I guess maybe my meta point is that I think intelligence generally fights
toxicity, not the opposite. I'm sure you can find counter examples as humans
are complex.

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

~~~
wdewind
> There are plenty of geniuses throughout history who were asseholes but still
> brilliant.

Agreed, as I said humans are complex and I'm sure you can find exceptions.
Just talking about general trends here.

> EQ and IQ are not highly correlated at all.

Assuming by EQ you mean being a nice person and intelligence are not
correlated I don't agree. Tons of studies backing this up (as well as
correlation with overall happiness). Here are two:

[https://www.ncbi.nlm.nih.gov/pubmed/12061571](https://www.ncbi.nlm.nih.gov/pubmed/12061571)

[http://onlinelibrary.wiley.com/doi/10.1111/jopy.12309/full](http://onlinelibrary.wiley.com/doi/10.1111/jopy.12309/full)

~~~
seanmcdirmid
EQ means emotional intelligence, the ability to empathize with people
effectively, allowing people to take hints via social cues when they are being
annoying or otherwise engaging in asshole-like behavior.

As geniuses are already extreme outliers. For one thing, they do not typically
fit in very well with their peers, often leading to seemingly anti-social
behavior.

None of the articles you link directly correlate EQ to intelligence, they
corrleate it to civic minded ness, and getting good grades in school. Social
people do well in social environments is not surprising.

------
mythrwy
"Rick was churning out code faster than ever. He was working seven-day weeks,
twelve hours a day. .......................... Every day, Rick grew more
belligerent and isolated. The mask was coming off. Jekyll was becoming Hyde."

Geezus. What kind of people are running this outfit that they don't see the
connection between these two phenomenon?

People who haven't spent enough time around programmers and/or people who
haven't spent a serious amount of time coding themselves would be my guess.

Coding 7 days a week 12 hours a day with the entire weight of everything on
your shoulders while others have "meetings" and write Medium blog posts will
turn Gandi into an asshole soon enough.

Not saying the guy wasn't intrinsically a jerk but this is a ridiculous
failure of management. And you are posting about this ridiculous failure in an
attempt to scapegoat someone who wasn't managed for the failure of a project
that was poorly managed? Shame on you author. Seriously. Grow up.

------
ironchef253
Plenty of blame to go around.

I have turned into Rick before. I was a super productive engineer and I would
work way ahead of the company in isolation and get things done super fast.
This was caused by me being a workaholic and enjoying my work too much, not
really caring about or paying attention to what was going on around me
politically. It never occurred to me that pulling way ahead of the company
would only result in severe damage to myself and the team.

Being this kind of engineer is like putting a Ferrari Engine into a Volkswagen
Beetle. The Ferrari Engine is going to tear the Beetle apart and the result
will be bad for all parties involved. The longer the Ferrari engine is allowed
to run, the more damage it is going to do.

When I behaved this way in the past, a strong mentor or manager would have
helped me immensely. Instead I had managers who were scared of me because I
was more talented than they were and just wanted me to go away. As a result, I
received no input as to how to better structure my working style and failed to
mature and grow. The result was I ended up getting laid off after becoming
deeply frustrated with everyone around me.

Companies need the right sized engine that provides the correct amount of
forward momentum, not an engine that rips the team to shreds. Learning to hold
back, Pay very close attention to my surroundings and communicate much more
carefully is required. This is generally the work of program managers, but
there are very few good ones. Lead engineers need to learn to program manage
themselves or they will just end up getting twisted around the axle.

The reality of this industry is that software developers are disposable parts.
Rick spent years building these systems, asking him to rebuild them would have
been impossible. Once he got to the point of becoming toxic, he had to go. The
Volkswagen Beetle (rest of the company minus Rick) needs to proceed onwards.

~~~
wwwater
Thank you for sharing!

> When I behaved this way in the past, a strong mentor or manager would have
> helped me immensely. Instead I had managers who were scared of me because I
> was more talented than they were and just wanted me to go away.

I think this is the cornerstone of the problem, that there rarely are more
than one strong personalities in a team, because each strong personality is
like a positively charged nucleus that attracts electrons but repels other
strong personalities.

------
chandmk
While I understand that no one could have gotten to a better conclusion I find
it a very distasteful commentary.

So Rick knew everything about the project, while everyone is simply making a
living off his work all those months/years, saved the management face many
times with miracles, probably not paid n*x, stopped attending meetings because
no one understood the stuff anyway, and the author has bad opinion of Rick's
code, conveniently ignoring context around Rick's choices, gleefully siding
with all those managers who have no clue in the first place and fired the
worker to have a new start!!!

Maybe Rick should be given a chance to comment on how bad those project savior
choices were.

Now we need to wait and see when would they identify next Rick of the current
version of the code when that stops cutting the muster for the flood of new
requests.

------
cdoxsey
There's a cautionary tale here for developers. If you're productive, hard-
working and have enough grit to complete projects, you'll get noticed and
handed even more responsibility.

Eventually it will be more than any single developer could handle and you'll
burn out.

Often, if you bring it up with management they'll do very little to fix the
problem. Projects that could be completed in a few days when delegated to
other teammates will somehow languish for weeks, at which point you get roped
in anyway to hit the deadline, except now you have to do it ASAP and you're
working nights and weekends.

At the end of a project like that mgmt will consider it a success, since the
project was completed, and the whole thing will happen all over again.

The only thing they'll actually notice is failure. But who wants to let
something fail?

So keep your head low. Get a sense for how long it takes others to complete
projects, and aim to be in the same ballpark. To get management to make
rational scheduling decisions you need to control what they see.

Which for this type of engineer is going to be really hard. Management should
be better at this, but in general they're not, so it's either constrain your
productivity or be successful for a year or two till you're overworked out of
a job.

------
ww520
This looks like gross mismanagement. Gross mismanagement of client
expectation, gross mismanagement of product scope, gross mismanagement of
feature/engineering processes/schedule, lack of leadership, and worst of all,
gross mismanagement of talent. It sounds like management has no or very little
technical background. Didn't understand how to build the product or translate
requested features into feasible functionality. And simply thrust the whole
problem onto a single senior developer. The guy while talented was overwork
and exhausted. I would turn into a Mr. Hyde too if I have to work seven-day
weeks, twelve hours a day.

~~~
mythrwy
Sounds like incredibly immature inexperienced people playing startup and
playing manager to be honest.

This post doesn't reflect well on the outfit at all. The fact it was even
published confirms the above.

------
paxys
From the way they described the developer and his work habits, it doesn't look
like they have a good idea of what "top talent" means. Probably one of those
places where you have to look busy and act smart to get promoted vs. actually
producing results.

~~~
cpncrunch
Exactly. There is nothing inherently wrong with a single developer building an
entire product, and I know a lot of very good "10x" developers who work mostly
on their own and build great products.

The reality is that there really are a lot of 10x developers out there, but
there are also 0.1x developers like this guy, who actively sabotage projects.

------
hmwhy
I think another issue that may be worth mentioning is that a lot of the
articles in the freeCodeCamp publication are written specifically to appeal to
people who are not (yet) very skilled.

At least in this particular case, the combination of the red flags already
mentioned by many together with the demographics of the target audience seems
like a dangerous combination that promotes stigmatisation of "talents" and the
idea of "if you can't become it or work with it, kill it".

I may be reading between the lines a bit too much, but the article appears to
be exceedingly popular by the freeCodeCamp publication standards, and that, to
me, is very unsettling for a story that I think is effectively "management
turned mismanagement into a heroic triumph".

------
hacking_again
This is probably libel, and regardless it's character assassination that
reflects more badly on management than it does on Rick.

~~~
lazyasciiart
In the US, it's not libel if it's true. Even aside from that, this doesn't
actually identify anyone.

------
urda
Thanks to articles like these, it's easy to know what professionals and
companies in our field we can avoid.

So many red flags from the author, I'm shocked that any of their talent
stayed. What a joke.

------
oceanswave
The transformation of Rick from Dr. Jekyll to Mr. Hyde is absolutely the
companie’s fault. This article further denegrates Rick by lacking the self
reflection to understand that it sounds like Rick was a devoted employee. He
put in crazy amounts of hours to help the company succeed. Of course this had
massive amounts of pressure behind it - related to the transformation. The
company rewarded his devotion by firing him. As anyone would, Rick saw his
hours of toil being stripped from him, anyone would be defensive in this
situation. Perhaps this departure might have been good for Rick too, but it
seems like it could have all been handled in a way that could have been
copesetic for both parties. One way might have been telling Rick what the
company felt, give him a nice long vacation to unwind, have the team
collaborate in his absence. More creative and effective solutions probably
exist.

------
pfarnsworth
This sounds like a shitty management chain that had no experience on how to
properly manage a gifted developer. The developer was allowed to do whatever
he wanted, which meant that his Hero-complex because a positive feedback loop
until everyone bought into it.

If management were better and kept better tabs on Rick, they could have nipped
this in the bud. Sounds like they instead let this fester until it turned into
an untenable situation.

------
andrewstuart
Poor recruiting, and worse management. The most interesting thing here is that
management blame the primadonna employee and not themselves.

This sort of thing is often seen in companies where the top management are not
that technical. They employ "geniuses" who are in fact just idiots, but are so
intimidated and awed by the ego that they are afraid to call them on their bad
behaviour. Even better, not employ such people in the first place.

I think such people should be given a direct talking to about their behaviour,
given the chance to fix it, and if not, moved on.

I've dealt with many companies who are tip toeing around whilst trying to work
out how to employ someone to replace this toxic team member.

------
perpetualcrayon
If I were in charge of the people on the project I would ask for the paper
trail to see what kind of methodology was being used to make progress.

I would probably end up finding that there was none (or only a bunch of CYA
paper trails), and fire everyone who was involved in that project.

EDIT: I once was recruiting for a project I was working on, and one of the
candidates during a phone interview bragged about a poorly managed project
they were on that "wasn't their fault". I didn't address it, but that's where
they were sorely mistaken. Not doing anything when you know there's a problem
(even if you don't know what the problem is) is not a valid strategy IMO.

------
Clubber
>Your team’s strength is not a function of the talent of individual members.
It’s a function of their collaboration, tenacity, and mutual respect.

It's both. Don't fall into the trap that collaboration, tenacity and mutual
respect will compensate for lack of talent. You still need to find talented
people, just don't hire assholes or turn them into assholes.

------
Too
I've seen both sides of this table. We had one Rick where i worked, above
average coder, very bad ego. When one team had been working on a module for
weeks, Rick would review it, declare it as crap (loudly), throw all of it out
and rewrite the whole thing in in a day and it would genuinely be better than
the original. This was a huge waste of time for both the team and Rick. He
would give himself veto to break backwards compatibility in public APIs and
was against all forms of automated testing for this reason, this allowed him
to produce a lot of code quickly on the expense of everyone else. Management
considered him genius which made his ego even bigger, he worked over time
often and produced the majority of all code, whenever something was not
working he would blame modules not produced by him and management would
believe it even though that was usually not the case. End result: working
morale was shit and almost all other developers including myself left.

I've also been close to becoming one myself, one of few with whole stack
server setup on desk and all, being able to answer questions from team members
in a few minutes which would take them hours or days to investigate they love
coming to me for questions and during planning they say i'm the only one who
can solve certain tasks. To avoid becoming a bottleneck and to give me time to
work on my own tasks i just say i don't have time and let them solve their own
problems, this makes the whole team more independent and happy and everybody
is able to debug their own code.

As others have already noted, management allowing it to go as far as it did in
the article is the original source of the problem.

------
ezekg
Sounds like Rick was burned out and blamed for bad management.

------
jarsin
I'm turning into this dude but I just play video games in my office :)

------
EngineerBetter
Pair-programming greatly reduces the risk of this situation arising.

------
luord
While a lot of the blame falls on management for, well, completely failing to
manage anything or establishing a proper feedback loop where the developer(s)
could contribute to management and deal with clients in a more organic way (to
prevent the requirements creep, mostly), there's still a lot to blame on the
developer. He evidently wasn't the genius he (and the company) thought he were
and, in the eagerness to prove that he was, he made a mess.

For my part, I'm glad I'm way too lazy to be a Rick; I would never want to
grab all that responsibility and, as such, I hopefully won't ever make a mess
of that proportion.

------
hkjayakumar
The author elaborates a bit more on how management unsuccessfully tried to
reach out to Rick, resulting in their departure before Rick's in response to a
comment[1]. This post is obviously just one side of the story, so take it with
a grain of salt I guess.

[1] [https://medium.com/@peachpie/thanks-for-the-insightful-
respo...](https://medium.com/@peachpie/thanks-for-the-insightful-
response-96bfdd1e5876)

~~~
imron
The key point being:

"He never should have been allowed to take on so much. If it gives comfort to
anyone else reading this, the manager went first because ultimately management
bears responsibility, always.

I was brought onto the team after that, as a hail-mary pass."

The original manager screwed up to let Rick get to that point, and once at
that point it was impossible to manage him, hence him getting fired.

------
mortyRolled
Oh, but the guy, Rick, kind of catches some blame too, even if you might point
out that permitting him to hoard the project as a lone cowboy is terrible
management.

If this discussion is filled with developers who are able to recognize the
poor leadership and planning that permitted an individual, acting alone, to
corner all software development tasks, and hoard the project’s codebase, why
did Rick fail to notice the same thing? Or worse, continue apace, fully aware
of the problem, and its resulting toxicity seeping into the atmosphere of the
operation?

Is Rick blameless, even if our recognition is granted the conceit of
hindsight?

Placed in the same shoes, would you see the trainwreck approaching? Would you
jump ship before the finger pointing started? Would you communicate, enlist
support, and try to adjust expectations in the face of vapid, idealistic tech-
industry pageantry?

~~~
lukaslalinsky
It's hard to recognize a bubble if you are in the middle of it. Not
impossible, but it's much easier to do from outside. That's why I think every
software company needs a good manager, who is able to detect situations like
this early, no matter how small the company is.

------
JustSomeNobody
I hope you fired Rick’s manager as well. Oh my, this should never have gone
this way.

------
internetman55
This pretty much happened to me at a project. Coworker was positioned as
leader of our project and thought I was a genius and could make her look
really good. Starts pushing me really hard to do stuff I had no experience
doing really quickly.

Another MBA-type coworker starts drafting me into his own initiatives. They
actually were essential to the stuff we did running at all, but apparently no
one actually knew that.

I overwork for a while. Eventually I get pretty burnt out and I stop being
able to work at a supranormal pace. Coworker/pseudo-PM gets mad and starts
badmouthing me to my actual manager. I get butthutt since I'm working 10x
harder than anyone else on my project yet I'm being harassed constantly.

Eventually I have enough savings that I stop caring about getting fire. In my
mind, management had unreasonable deadlines, so I began to rely on myself to
decide what a reasonable level of output was. I start doing about 4 hours of
work a day and stop caring about anything beyond my "daily minimum".

I started to get in really good shape, since I'd constantly sneak to the
parking lot and do laps or run to the gym when no one was looking. I started
returning to my religion and started reflecting a lot, and really meditating
on the situation. I realized that I was being punished for my pride and
arrogance and became a much more humble person.

Instead of working hard on my own work to glorify myself, I would focus on
making my team members as helpful as possible. Since I was fine losing my job,
I was also fine jumping on basically any metaphorical grenade for any reason
and absorbing political fallout.

Eventually my entire team was absolutely in love with me, except my pseudo-PM,
the MBA coworker, and my actual manager. I realize they are all just stressed
out folks trying to make a living. The Pseudo-PM seems mad at me for some
reason, and constantly complains about me while the rest of my team talks
about me as if I am a saint. Soon pseudo-PM is let go from the company.

Eventually the whole project just gets transfered to another manager, who has
reasonable expectations and seems to look out for his employees. Now life is
pretty good. It was just a really surreal experience.

~~~
internetman55
I'm trying to edit this but failing. Psuedo-PM leaves the company, MBA
coworker is let go, project is transferred from my manager to someone
reasonable.

------
pedrodelfino
Rick seems to have a typical behavior reflecting a “fixed mindset”. This
concept is described on the famous book from the psychologist Carol Dweck. He
seemed to search for validation all that time. Since the failure would be an
atemporal sign that he was not good, he denied the errors. Thankfully,
according to the research, eveybody can change from a fixed mindset to a
growth mindset. We all have some quantum of Rick inside us. I am reading this
on a Monday. This is a good text to start the week and reflect about my
behavior at my workplace.

------
tome
> Rick was a very talented developer.

No he wasn't. Even by the evidence of the article he wrote poor code. He
clearly churned out a lot of it but it was poor.

------
bobhir
Dynamics of software development by him McCarthy published in 1995 covers this
exact scenario in the "beware a guy in a room" rule

------
m3kw9
How is he a top talent if he only excels in a narrow area and completely bombs
the others?

------
tempYeez
Oh I hate Ricks. Programming genius who love to hear themselves speak, bully
others into their technical decisions and refuses to be unwavered from
predisposed technical biases. There is always some senior engineer with this
attitude.

------
skepticalbayes
Checkout his linkedin
[https://www.linkedin.com/in/jhamiltonsolorzano](https://www.linkedin.com/in/jhamiltonsolorzano)

Was this at UCLA on his research team? Or Stanford?

------
stmfreak
Who classifies people who cannot work with others as "top talent?"

------
enneff
You didn't fire your top talent. You fired an incompetent douche.

~~~
imron
They fired a scapegoat for poor management.

------
mdip
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.

------
cha5m
Writing maintainable, comprehensible code is truly the greatest challenge when
creating software.

