
You fired your top talent. I hope you’re happy - ech
https://medium.com/@deusexmachina667/you-fired-your-top-talent-i-hope-youre-happy-cf57c41183dd
======
iwanttoreply
I really liked both articles because they're starting to get at a fundamental
issue that is at the core of a lot of the management vs engineering conflicts
that tend to arise.

Personally I've been in Rick's shoes where I've been overburdened with tasks
simply because product management (not necessarily direct managers) committed
to accelerated timelines without consulting with the engineers. Although I
brought up distributing my load to my peers, it was always deemed that there
"wasn't enough time" to train them and the cycle repeated. I was always
sympathetic to my direct managers because they were given an unreasonable task
and had no mechanism of providing "upward" feedback or adjusting the schedule.
At the end of the day I was just putting more pressure on myself. After a few
years I had enough and left the company in the interest of my own well being.

At a conceptual level I think the issue is centered around making software a
business. On one hand designing and implemented quality software is an
iterative process and scales exponentially in terms of decision making (e.g.
one week of technical debt can lead to months of problems). On the other hand
businesses are deadline driven and function on a linear scale of time.

------
kazinator
There are various alternative ways to interpret the story. Like, "Yay, we
finally outran _one_ developer by using an entire team, and gutting the
requirements." That's like moving the finish line closer without telling the
forerunner.

Hey, only 5% of the users need this; let's remove it? What's 5%.

You know, that could be sometimes justified, but not always. Could we throw
something out of Firefox or MS Word that only 5% of the users use?

It's not clear whether Rick himself invented all those additional requirements
himself, or whether they were external.

Could it be that the man toiled earnestly to implement requirements coming at
him from various people such as product managers and such? And then they
crucified him for the software being too complicated due to doing things which
the current political party suddenly finds unnecessary.

------
watwut
What I find symptomatic is that everyone takes Rick being the superior genius
as granted - while there is little evidence of his real superiority. In most
likelihood, he was slightly more experienced then the rest of the team and
knew slightly more at the beginning. The evidence of them being actually
capable is there in the subsequent work. Which was better then Ricks, but note
how they don't get to be praised for skill at all. Only Rick is.

The pattern I have seen multiple times in IT companies is that if you act the
way Rick is described to act, you will create aura of geniality around you. If
you are the slightly more experienced and a lot more confident, you rejecting
other peoples ideas or criticizing their work will be unconditionally accepted
as truth. And once aura is there, it is also pretty easy to frame every
difference of opinion as objective truth that they are wrong.That gives others
little chance in politics.

Describing experience: it does not matter that those slightly less experienced
needed maybe two-three months to get up to speed, it does not matter that what
they proposed was actually equally valid solution to the problem at hand. It
does not matter that Rick saving day from someone else bad solution was may
Rick rewriting equally valid code to another equally valid code.

What happens is that Rick acted arrogant and therefore everyone in leadership
and in comments assumes he was the biggest rock star there was in the company.
Other people cooperated well, therefore they are clearly less skilled than
Rick was.

As for working 12 hours a day 7 days a week - it is irrational and invariably
leads to inferior results. However a person who has discipline to go home,
sleep, exercise, take rest, say no will not be praised as a role model,
despite making better more rational decisions. Nope, the one who does
irrational decisions is fallen genius hero.

------
oandrei
Right, because computer programming (unlike computer science!) does not take a
genius. It is, basically, a routine work. Unfortunately, there is a tendency
to say the same about fundamental science, for example here:
[http://www.slate.com/articles/health_and_science/science/201...](http://www.slate.com/articles/health_and_science/science/2017/10/the_nobel_prize_does_science_a_serious_disservice.html)
and here : [https://www.theguardian.com/commentisfree/2017/sep/30/we-
hai...](https://www.theguardian.com/commentisfree/2017/sep/30/we-hail-
individual-geniuses-success-in-science-collaboration-nobel-prize) This worries
me. Without outstanding contributions from individuals, science will turn into
waste of human resources. We absolutely need to protect and care about our
elites !

------
drawkbox
There are quite a few places like this out there, typically technology has a
muted role in decisions in these organizations, quality takes a backseat for
the crunch for the next meeting demo, ad infinitum.

A smell of these types of places is they always blame the developers that just
left, almost like a scapegoat or two minutes of hate rally. Another smell is
estimation is rarely respected i.e. if you say it will take a month they
should expect it to take that long or even twice as long as the programmer
estimate, but at places like this, about halfway through they say it has to be
done in a few days for a _very important meeting or deal_ , if it is that
important you want a solid product not a one off.

As a developer you also need to manage balance and workload. Consistent work
discipline and good sleep/health are important. Take on challenges but be sure
each project is a focus and you aren't spreading yourself too thin, work
quality goes down when you don't have some buffer. A good developer would
never design a system that is constantly pegged, don't do the same to your
schedule/self as that is a single point of failure.

~~~
internetman55
Wow, that exactly describes my company.

Our group ignores the ops stuff necessary to keep our product up and running
to keep pushing out garbage for the next big demo. Most of our product is not
working multiple days out of the month.

Some MBA guy with ambition learned enough technical skills to keep things up
and running with some help from me.

Boss goes to MBA guy to keep things up and running and considers the problem
"solved". MBA guy is running himself ragged by logging on after hours and
screwing around with data files just to keep things running, then doing the
same admin BS all day.

After MBA guy is let go, he is badmouthed for coming up with an unsustainable
solution. All future admin work is explained as being necessary only because
of him.

Eventually we had our "launch" and our PM did the "big presentation" to our
company leadership. After everyone started to realize our product was garbage
and we had boatloads of promises we could never keep, she just jumped ship.

I would have considered the whole thing a joke except it ruined my health and
relationships for several months.

------
snarfy
You don't get what you deserve. You get what you get.

There is a misconception that if you do the extra work you will get
compensated some way either through promotion or bonus. It's simply not true.
You are paid for the position you were hired for.

Rick should have left the moment he took on more work without matching
compensation. Why wouldn't the business pile more work on Rick? It's free. As
soon as it costs money, all of the issues brought up in the article would be
addressed. Suddenly management cares.

~~~
scarface74
_There is a misconception that if you do the extra work you will get
compensated some way either through promotion or bonus. It 's simply not true.
You are paid for the position you were hired for._

I agree on the surface. But I would add that extra work may not get you a
promotion or more compensation at the company you are at _now_ but the right
kind of extra work where you are learning new skills or can say that you did a
project that was important does help your resume and can make you more money
somewhere else.

~~~
mercer
Plus, the people you work with and for might start their own company and offer
you work, take you on as a well-paid freelancer, etc. Business is not all
business.

------
brooksbp
1:1 conversations outside of normal work context can help. Dropping the work
context is critical to having a human:human conversation. Most people don't
have the heart to do it (for real).

If your approach always begins/ends with 'from my side' or even worse 'from
our side' (team/mgmt context), you will always fail to connect with and
influence someone like Rick. This sort of language will just reinforce the
division between Rick and everything else.

It takes one to know one. If you know that someone like Rick is just 'so
different', or if you just have that 'gut feeling', you need to find someone
who can connect with Rick. An age gap (20+ yrs) helps too; reach out to the
respected elders in the company.

If you can show that you care about this person, and want them to be
successful and healthy, then they might start to listen to you. All you really
need is their attention.

------
pascalxus
Documentation, while important is also a bit overrated in it's capabilities.
Don't get me wrong - It would be lovely if you could simply read a bit of
documentation to understand what's going on in the code. Reality is different.
The details of understanding code, is in the code itself and how it connects
to all the other bits of code.

The original author of the code has an understanding that far exceeds the
explanatory powers of any documentation or anyone else that can come along and
try to understand what's going on. By all means, attempt to document as much
as you can, but don't expect it to be a silver bullet for understanding code.

~~~
syshax
I wish more people understood this.

There is no excuse to not have any documentation. One must always make an
attempt to write a reasonable amount of documentation so there isn't a
situation where there is no hope to understand anything except read all the
source code.

But a lot of people (managerial types especially) expect docs will be "step 1
look here, step 2 look there, step 3 fix with this exact command"

Docs should explain how a system works, and perhaps some important places to
look, but it's not a checklist to fix all problems. The consumer must still
possess the ability, and will, to investigate and fix problems using their own
critical thinking.

------
jlg23
> Instead, they played Rick like a fiddle, burned out all of his talent and
> skill, and once Rick was considered damaged goods, kicked his ass to the
> curb for the good of the company’s productivity. How brave! How heroic!

There is always two parties involved, the player and the fiddle. The
assumption that the developer was sucked empty and thrown away is the OPs
alone, the article referred to does not provide details of attempts at
intervention.

------
cannonedhamster
I was a Rick once, though not by choice. The company underpaid, management
received bonuses based on cutting staff, and the company wasn't a tech
company. They refused to give raises or title only promotions. I tried to set
up knowledge transfers, tried to spread workloads, instituted training, but it
was never enough and all the work ended back with me. I eventually left and
now make significantly more for less work. I've never let myself become a Rick
again.

------
Beltiras
Apparently they didn't fire their top talent. They fired the _worst_ talent
since the team brought it together after the tyrant was vacated and the
quality of the work was questionable at best when reviewed.

------
golemotron
Maybe the pathology is that there is no management or that it is anemic.
Everyone loves the idea of self-organizing teams until something like this
happens. How would Agile or Holocracy solve this?

------
chandmk
Thank you for writing this. The culture of one software developer deriding on
other software developer work by badmouthing his/her work and bragging about
how firing the developer solved the problem might have a place in politics but
should not be celebrated/encouraged in the technical world.

------
internetman55
As someone new in this industry, I'm noticing that whoever appears more normal
in meetings instantly wins any conflict, regardless of who has the most valid
arguments. I find myself preemptively doing as little work as possible on days
I think I'll have some sort of discussion in a meeting, since being frazzled
from writing code ensures that the other party can force their demands on you
without issue. It seems like people are also throwing out little jabs
constantly. If you are in a relaxed state of mind, you win and they look weak.
If you are worked up and respond, they win. Basically I writing code seems
like a horrific waste of time on most days.

Is this normal?

------
scarface74
I see so many sides to this

-I’ve been a Rick, stayed at a company for nine years, knew where the bodies were buried because I buried most of them myself and became more disenchanted year after year which caused my attitude to get worse and worse. They wouldn’t fire me but they also wouldn’t promote me and give me raises - causing a horrible cycle.

I woke up one day 8 years later in 2008 and making only 10,000 more than I had
made in 1999 as the raises were abysmal and the bonuses got cut realizing that
I wasn’t competitive.

9 years, four companies, and a lot of humbly studying and learning from people
a lot younger than I am, I’m finally in a position that I want to be in as the
software developer lead for the company.

I saw myself becoming the bottleneck and working crazy hours for the first 5
or 6 months. I had to put a stop to it. I sat down with my manager, hired
three more people. I now insist that everyone be responsible for making sure
their work gets all the way to production, everyone does there own devops
work, documentation is part of the “definition of done”. I let them solve
their own problems even if I know I could solve it faster.

I’m training the team not to be dependent on me.

When it comes to meetings, each developer is responsible for chasing detailed
requirements when there are gaps.

My responsibility is to hire, train, and to mentor. I will do the most
critical pieces of the architecture that is a base for everything else. I also
enforce a 40-45 hour work week. If you want to learn on your own that’s fine
but no one should put in crazy hours. We don’t want to set that expectation.

~~~
mercer
When I read the original article I was immediately curious how Rick would've
written about this, and whether he was really as bad as he sounded, because I
also have been, at least, a semi-Rick. Or at least I can imagine someone
writing about me in a way similar to this.

There's a lot I could say about my experience, but it boils down to a
combination of bad practices/behavior on both sides (that I learned from
immensely), broader circumstances, as well as a bad fit between me and my
direct superior(s) or the nature of the company. I think the latter is often
underestimated.

I believe that the 'true' story of bad employee/employer is often a lot more
like a romantic relationship than we care to admit. And while my impression is
that Rick was more at fault in this situation, I'd say that just like a
romantic relationship, the best lessons to draw from these events are not the
blame-game ones.

(of course, maybe that says more about my romantic entanglements than about
work hierarchies...)

EDIT: tangentially related, but I just realized that one of the few ways in
which I feel I can say I've 'matured' on my path to 'adulthood', is having
experienced multiple sides of, in essence, the same situations. It makes
empathy and productive solutions so much easier, even if not always in the
moment.

This kerfuffle is a good reminder for me to keep an eye out for these types of
lessons and to avoid reflexively looking for someone or something to blame.

~~~
fortythirteen
Having an entire product rest on your shoulders sucks and emotionally drains
you rather quickly. In my case it was a startup with a technology I created on
the side that became the main business and eventually became the sole earner
for a company whose other business had already been dwindling.

At the time there were maybe half a dozen people in the country that even
worked in this particular niche. If I left the company it would likely go
down, and the CEO kept telling me how many people would lose work if I left.
And the pressure and responsibility kept growing and growing. And the sales
people, who made up half of the staff, kept getting more and more
antagonistic, as I couldn't meet their constantly larger expectations, which
were often technically impossible (like sci-fi movie level). This situation
lasted for over a year, culminating in a huge blowout between the CEO and I
when I left.

I became a Rick real fast. I still feel like shit for being a Rick, and it's
taken years for me to move that experience out of my "work baggage".

------
thestephen
_We re-released the product to this group. It consisted of 10% of Rick’s
original code which was pretty stable. It also had a few thousand lines of new
code to replace about 150,000 lines of incomprehensible mess._ _The team had
replaced five years of work in about six months. Over the next few months we
expanded from pilot to full customer release._

Up next: Manager on Medium bragging that he or she would be able to type out
all ~1 000 000 words in the Harry Potter series in a couple hundred hours.

~~~
talmand
I'm curious how they managed to refactor about 150,000 lines of code down to a
few thousand lines.

~~~
x1798DE
Could be they slashed a bunch of features, but I wouldn't be surprised if they
replaced a bunch of homebrewed frameworks with third party equivalents. "Line
count" is such a vague measure, it's easy to get counter-intuitive results.

~~~
ryandrake
I used to routinely achieve 10-to-1 code refactors, without losing any
functionality, and have probably done a few 20-to-1's. 50-to-1 is not really
unbelievable. It's amazing the kind of pointless verbosity and over-
complication some programmers are capable of.

Besides refactoring, there's also garbage cleanup. We've all seen instances of
huge, 1000 line functions that do nothing because the result of their
calculation was thrown away, or because it's never called in the first place.

------
pault
From a comment on the original post:

"Unfortunately Rick rejected months of overtures by leadership. He refused to
take time off or allow any work to be delegated. He also repeatedly rejected
attempts to introduce free open source frameworks to replace hard-to-maintain
bespoke tools. Including the security framework as you mentioned."

Also:

"Another poster blamed management. I agree that the situation that came about
was also his manager’s fault. 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."

~~~
cupscale
This still reeks of CYA.

> "He refused to take time off or allow any work to be delegated. He also
> repeatedly rejected attempts to introduce free open source frameworks to
> replace hard-to-maintain bespoke tools."

Why did he have the authority in either of those last two decisions?

> "I agree that the situation that came about was also his manager’s fault. "

And his manager's manager, and basically anyone who was aware of this project
and the fact that it was delayed by two years.

 _Nobody_ above Rick's manager was looking into this project when it was
delayed by two years? Nobody took a look at the JIRA/whatever board and saw
that one person was blocking everyone despite working 100 hours a week?

~~~
jsjohnst
Two years past a committed delivery date is a very long time in software terms
and is a sign heads need to roll all over the organization.

I think an argument could be made for everyone in Rick’s chain up to and
potentially including the CEO should be let go.

> I’d been aware of the project for a while, because it had grown infamous in
> my organization, but hadn’t been assigned to it.

And especially the blog post writer who knew about the problem for a long time
self admittedly and did nothing about it, only to then pat himself on the back
for handling the situation poorly when it was finally assigned to him.

------
thisisit
The whole situation reminded me of this sketch:

[https://www.youtube.com/watch?v=BKorP55Aqvg](https://www.youtube.com/watch?v=BKorP55Aqvg)

Given the kind of unreasonable demands, people do crack.

~~~
RenierZA
And here's the solution:
[https://www.youtube.com/watch?v=B7MIJP90biM](https://www.youtube.com/watch?v=B7MIJP90biM)

~~~
Gigablah
He's missing a few dimensions.

~~~
dennisgorelik
"Dimensions" are not the part of requirements.

------
notyourday
Personally, I'm patiently waiting for the third installment: "Our incredible
story"

------
stillsut
I'd really need more information about what Rick was building to make up my
mind on this one. Based on what I could google about the author, he has always
worked for a large research university IT department.

In this light, I've seen these back-room clerical apps, that need everyone's
special requirements included, turn into boondogles of team bloat and mis-
communication. If Rick thought he could ship it himself, and had a track
record to make the estimate, I can't begrudge mgmt for hoping he could do it,
even betting on him. As others have noted, it took a full team a year with
scaled back feature set. A losing bet, that could have been played safer for
sure, but maybe only wrong in project hind-sight.

From Rick's perspective, I'd speculate he was somewhat motivated by a threat
of impending irrelevance, and somewhat justified in estimating the true
penalty in his productivity from collaboration. Again, from snooping on the
author, I think there was some Oracle, lots of Microsoft in tech stack.
Knowing this type of 10x guy, his implementation style is usually somewhat
deprecated from a decade of head down productivity. Also, one of the biggest
problems outside "real tech stacks" is the lack of collaboration workflows and
conventions. So it may indeed have been true that tripling man hours on the
project could have resulted in negative productivity given the project's code
base 6 months in. I still think Rick earned the right to gamble, fail, and go
down with his ship. It was foolish because he would have likely only grown in
esteem and compensation with some artful delegation. And doubly foolish, if
his stack skills weren't highly marketable; limited upside with huge downside
for him. But I find it commendable nonetheless he chose to Build when "Lead"
would have been more rewarding; and ultimately if he makes the deadline, no
crisis ever comes to head.

Finally, the "Rest of the Team" did what I think was the tough but right
decision to move forward. No way can you "reset" the project while sustaining
weekly second-guessing coming from an obsessive, knowledgeable, ego-bruised,
senior team member. Ultimately, even self proclaimed logical dev's are
irrational actors and as susceptible to group dynamics as anyone. We're all
limited people: mgmt can't predict the future, proven-shippers sometimes come
up short. I don't know if we need to read this as a call to blame.

------
kahlonel
If you are a CTO or manager, please do your developers a favor by not throwing
buzzwords at them in 99% of your conversations that you don't even understand.
As a consequence of your vague requirements, if a developer chose to implement
something that you don't quite agree with, grow a pair and suggest an
alternative.

------
pascalxus
Rick needed leadership coaching and he never got it. So, he never learned to
be a good leader. The problem wasn't documentation. The problem was,
management never taught him about the value of delegation, ROI, opportunity
cost and the ability to strategically eliminate certain features for a better
outcome. Maybe he didn't want to learn these things, in which case, he should
have been demoted to regular developer or if he's having a bad attitude about
that, then fired.

~~~
philipov
Management can't teach what they don't know ;)

------
provost
A very similar scenario is described in the fictional work, "The Phoenix
Project", is it not? There is a smart character who handles every escalation,
but nothing is documented, he was the bottleneck, and his stress level was
high.

Management had to figure out they needed to handle the escalations,
prioritize, reduce the bottleneck, document the solutions, and teach others to
fish.

This article seems to be addressing the same issue, albeit a bit more
confrontationally. Anyone have recommendations for a non-fictional book on how
managers can identify these problems and implement people-centric solutions?

~~~
tonyarkles
Yup, very similar scenario in The Phoenix Project.

And thank you for the reminder of that. It occurred to me reading the original
article and this reply to it that I may be somewhat putting myself in a Rick
situation right now.

I don't have any good book recommendations, but I'd be delighted if anyone
else did :)

~~~
bartread
I can sympathise. I've basically been brought in to take over from someone who
was the technical bottleneck for the company I now work for so that he can get
on with being CTO. For a while I was necessarily working alone, but now I've
hired a team and am in the process of eliminating myself as the bottleneck: by
the time I go on holiday at the end of this week I want to be off the critical
path and never find myself on it again.

~~~
tonyarkles
Are you me? :)

That's probably the solution: find at least one other person for this team.
The CTO was amazingly taking care of all of the infrastructure himself, I came
in to lighten his load, and I feel like we could use another person or two to
bring it down to a manageable level.

------
perpetualcrayon
IMO, the most amazing quote from the original story:

    
    
      It also had a few thousand lines of new code
      to replace about 150,000 lines of incomprehensible
      mess.
    

No one looked at the quality of work after maybe 10,000 lines of code?

~~~
dpark
These claims make me assume the original author exaggerated everything to the
point that the whole story is essentially a lie. This guy was incredibly
capable but copy-pasted everywhere and wrote shitty code? This doesn’t even
make sense. It makes even less sense that somehow no one noticed his copy-
paste coding for over two years until he was finally fired for other reasons.
But then those same incompetents who didn’t notice the copy-pasting or
generally overengineered spagetti code suddenly came together to rebuild the
whole product in a quarter of the time with less than a tenth of the code.

Yeah right.

------
leroy_masochist
The HN discussion thread for the article to which this is a response is here:
[https://news.ycombinator.com/item?id=15474893](https://news.ycombinator.com/item?id=15474893)

~~~
technovader
the real MVP

------
moon_of_moon
"Rick" is generally actively supported by a non-technical manager who wants to
keep the project from going to a more agile team ("it will take you 1000 man
years to replace this and if you try we will make your attempts fail until we
do it ourselves") and it locks in nice inflating budget.

------
equalunique
Seeing that the author of this is a security engineer, I now understand why I
relate so much to this. I know this to be true - the infosec field does have
it's overworked so-called rockstars.

------
codesternews
I disagree with some of below comments and it is totally Managment fault.

I might be somewhat a little rick. But in my case it is the managment
responsibility to set the expectation.

If a task takes 5 days to complete but your manager says I need build at the
end of day. You can not deny it and you have no other option but to patch.

Let's assume another scenario. If your manager says he needs build at the end
of day and you are spending 5 days to just write the beautiful thoughtful code
than what will happen. You loose your creadibility and no one will trust you
and say you are rockstar.

Then you will be fired like dumb.

~~~
watwut
It sounds like only Rick worked that much. While there is management to take
part of the blame, I have seen multiple times developers working that much
because they wanted to. Sometimes they thought it "must be that way", other
times they wanted to pretend they are heroes to save the day and did things
that could easily wait. Yet other times, they had no life out of work or messy
life and this allowed them to pretend it is not the case.

------
mikl
Great write-up. If your software team has a single point of failure, a
linchpin developer that holds everything together, then your team is
defective. Regardless of the attributes of this developer, management has
failed in letting it come so far.

I have quit jobs for far less severe cases of this. Feeling like you can’t
take time off and that the project will fail if you do not save it, is not
healthy. If you find yourself in that situation, you need to seriously
consider why your team is broken, and if its not your fault, quit. Find a job
where you have colleagues that you can rely on to shoulder their part of the
work.

------
ne01
They did not fire Rick, they freed him. Ricks should not be slaved!

------
disease
The story given in the original Medium article reflects what is, in my
opinion, the single most important thing you will ever learn as a software
engineer:

Those that ask the most, give the least.

------
conorcleary
Medium is trying to be Cracked with this article style.

~~~
pc86
Medium doesn't have editorial control over what its users post on the site.

------
RcouF1uZ4gsC
Based on founders'/executives blog posts, can we have a list of toxic
managers/companies that people can reference whenever they are considering a
job offer? This would be based on public postings about how they treated their
employees.

~~~
cannonedhamster
Generally, any company that has high turnover or is replacing senior level
jobs on a regular basis should be reviewed with suspicion. High turnover is an
indicator of the work not being commensurate with the pay or a toxic
environment. Lots of senior-level openings in a company that isn't brand new
signifies a company with leadership problems or funding problems.

------
Sevrene
While I can agree there are 'real' rockstar developers that act like the
original article mentions, I don't think whether Rick was or wasn't one of
them is what matters here. What matters most here is how management dealt with
him and their lack of responsibility for Rick's work for the last two years(!)
and the end as their result.

Other industries seem to get this better than ours. I've worked in quite a few
places that assign too many projects or tasks to key developers and then
reprimand them for lack of quality or quantity, which ever you will inevitably
buckle under first and it's never the manager's fault for assigning too many
tickets or not prioritising their tasks correctly (we're not mind readers) but
yet it's always the developers fault for the perceived lack of skill or lack
of effort. Don't get me started on the arbitrarily shifting release dates that
correlate with buggy releases that we developers get angry emails about. Maybe
I've worked at badly managed busineses, or hey, maybe I'm just a bad
developer, but this seems like the normal to me.

But if you're managing someone and they fuck up, it's also your responsibility
because you were meant to be managing them. That was your job. Even if Rick
was told to stop working, take a break, and he didn't it's still not up to
him, it's up to the manager to decide what's best for Rick and best for the
project.

~~~
noxToken
> _Don 't get me started on the arbitrarily shifting release dates that
> correlate with buggy releases that we developers get angry emails about._

I'm willing to bet that it likely causation in a majority of cases. I've been
there. Business comes back with a list of wishes for the quarter. We're asked
about the features as a whole, and I'm already on the fence about whether it
can actually get done.

We start getting granular with the stories. By the end of the first sprint's
estimations, we've definitively said, "There is no way we can finish all of
these by the end of the quarter." That's taken back to upper management, and
the whip is cracked. Too bad.

Sprint has started, and instead of a quarterly wish list, we now have hard,
immobile release dates for different feature sets that don't give enough time.
Some people are working long hours, and some of use are sticking to our 40 and
done. The features are released as wished. The production defect count
increases, and the production team grumbles.

I assume we'll repeat this until the clients get sick of shoddy workmanship
and outages.

~~~
Sevrene
Working overtime without some sort of commiseration should be illegal, yet it
is typically expected in a lot of salaried work. Even my local groceries makes
their workers spend 10 minutes cleaning up before close, 'off the clock'. Game
studios are notorious for the crunch at the end of a projects life cycle
because of the random off the cuff date a publisher needs to fill up a void in
their yearly lineup or quarter.

The thing is they don't explicitly say 'work over time' they say 'this feature
needs to be complete and working by Monday or else' What does management think
the developer will do, pull it out of our behind? Reminds me of Steve Jobs,
actually.

I once had my boss explain to me if these features don't get completed before
the end of the month, he will lose his house. I had already previously told
him that it's impossible and had to explain we will need to compromise to
reach that date. We released 1 month late but the software has a lot of issues
and I'm now blamed for this as the lead developer of only two programmers. I
worked 12 hour days 6 days a week for 1 month and he wanted me to work more.
He still has his house.

It's a zero sum game. Developers only have so much time in a week and the more
you chip at sleep and rest/play time, the more it's going to cost the
developer's health and the project's cost.

It's frustrating because I'm just a developer (mostly contractor to boot) and
yet I feel like I have valuable constructive criticism that would benefit
management and the productivity of the project on the whole if they adapted
it. You can rarely pull that off tastefully. Maybe I'm wrong, maybe these
things exist for a good reason and I'm seeing this differently because I'm not
in management so I have some confirmation bias. That's possible, but I've
experienced the exact same scenario as you and it always seems harmful for the
developer and harmful for the project.

~~~
internetman55
I'm new in this industry, but based on my life, the experience of some close
friends, and anecdotes like this, my impression is that you need enough career
security and cash savings that you can just ignore stupid requests from your
boss and not care about the fallout. Of course that is probably unsustainable
outside of entry level jobs, so I am sort of convinced that I should have a
6-10 year plan to exit it

~~~
Sevrene
That's an interesting way of thinking about it. I'm not very assertive, so
perhaps If I stood up to management a bit more everyone would be better for it
anyway. Although it's easier to stand up to your boss when it falls under your
domain (technology), but when it's their domain (managing people) it's harder
to be assertive.

Also what happens when it just becomes a self fulfilling prophecy? Regardless,
if you experience terrible management you should probably be finding another
job anyway.

------
whipoodle
Music to my ears.

------
le-mark
There were a lot of failures in the Rick story "on all sides" as POTUS would
say. This author seems to identify with Rick and frames this type of developer
as gifted, but taken advantage of. At the end of the day, we all have to
manage our own careers. And in this field that especially includes "managing
your manager". Whatever process you find yourself in, you have to be able to
push back and say: "I'm working on X, if you want me to work on Y, what do you
want first? What's the priority?"

If you find yourself in the pitiable position of fielding calls from Sales,
Marketing, and Support, you need to get out of that situation by appealing to
the CEO/CTO or someone. You have to have a buffer between these groups and
development. If this doesn't exist or you can't get it, go elsewhere.

~~~
coldtea
> _There were a lot of failures in the Rick story "on all sides" as POTUS
> would say._

Nope, there weren't. That's what management is for. Everything that happened,
since they didn't attempt any change, is their fault and their only.

~~~
marktangotango
Naw, at the very least Rick was guilty of hubris and naïveté. I came in after
a Rick left once, that guys ignorance and poor decisions hobbled that company
for years. Icarus is not held in high regard, by anyone.

~~~
falcolas
Yes. How dare Rick be human; to be missing traits which are typically obtained
by teaching, not by osmosis. The story of Icarus is, one, completely
fictional, and two, a parable used for teaching such traits.

~~~
scarface74
If you are in technology, either you become responsible for learning on your
own or you get left behind.

I’m not just referring to learning the latest new and shiny JavaScript
Framework. I learned the hard way that technical skills will only take you so
far. I had to learn the soft skills.

------
cc81
Could you please not spam "funny pictures" in a post like this. It makes it
annoying to read.

~~~
dpark
He was mocking the original: “Look at my story! I’m going to use pop culture
character names and memes and shit to identify with my audience! Whee!”

~~~
corobo
Once would have been enough. Twice to make a point. But then the point's made.

~~~
dpark
_Shrug_

Tastes vary.

------
Shivetya
likely Rick never could off load his work because of management. he may have
been up against a wall of resistance where no one else did anymore than they
had too. this is how you get Ricks. You have a general apathy among many of
the developers which sets in because they don't see anyone held accountable so
why should they exert the effort?

~~~
scarface74
There are always choices — either change your environment or change your
environment.

~~~
lukaslalinsky
There is also another option, you genuinely like your work. For some reason,
the team does not want to get involved and the management fails to notice
this. Fixing the mess means either stepping up as a manager, or leaving. In
both cases, you lost the work you liked. What do you do?

~~~
scarface74
What is there to like about a job with bad management and bad team dynamics?

I also learned the hard way the cost of staying at a job for too long because
I got comfortable - or at least was more comfortable with the devil I knew.

------
cupscale
Yeah, wow.

I mean, Rick's a dick, no doubt. But much like Frankenstein's monster, it's
incredibly easy to see who had a hand in transforming Rick into what he
became. It's hard to read the original article and not see several large
"where the hell was management" red flags:

> Any time there was a particularly challenging problem, Rick would handle it.

That's a _management failure_ , and a particularly egregious one that I see
new or overly passive managers make. How do you expect one person not to have
all of your domain knowledge if they're solving all of the challenging
problems?

Fixing this doesn't even involve being super confrontational:

"I'll fix <database issue 123>." "Hey, Rick, you're already working on XYZ and
I want Summer to get some experience working with our database system, so I'd
like for her to do it."

> First, he created a cult of dependence.

Because management idly sat by and let him do that. People want to feel
irreplaceable and like they're exceptional. One way to do that is to create
this cult of dependence. Management's job is to step in and re-assure Rick
that he's a valued member of the team while also directly confronting this
cult of dependence.

We do this all the time at my job, and we don't even do it using complete
thoughts. We just say "bus factor" and everyone understands why one person
can't be responsible all the time for something (or in this case, everything).

> Team members didn’t want to speak up and offer their own ideas because he
> always berated them for it.

Holy shit, you didn't torch his ass for berating people in meetings? Are there
even managers at this company?

This, to me, is the worst failure. Either management is ignorant of the
berating (bad) or they silently tolerated it (even worse).

I really hope the managers at that company are taking a long hard look in the
mirror and doing a post-mortem on what went wrong with Rick. I suspect they're
not, and attributing it to one bad employee, but I can hope.

~~~
coldtea
> _I mean, Rick 's a dick, no doubt._

"No doubt" a real person is a dick, because of a single-sourced account from
those who fired him, which even at that, leaves the question of their own
failures wide open?

~~~
cupscale
Ehhh sorry, saying things like "I'm Albert Einstein and you're all just
fucking monkeys scratching in the dirt" doesn't strike me as the speech of
someone who's particularly nice.

Most people (at least in my experience, you know, the one who's making the
subjective judgement about him being a dick) can be angry without saying
something pretentiously mean like that.

It's ok for the conclusion here to be, "Rick's an asshole who should've been
fired but management fucked up pretty badly." Situations don't have to be
binary with only one party at fault.

EDIT: Let's also not forget the accounts of Rick supposedly berating people in
meetings. If multiple people think you're being mean to them, you're probably
being mean.

~~~
bartread
I don't know: in my experience pretty much everyone has a breaking point
somewhere and once they reach it things can get pretty random. I've seen
people I thought had it all together just completely lose the plot and
disintegrate too many times to believe it's all bubbling away there, just
below the surface, in all of us.

~~~
cupscale
Your reasons for being an asshole don’t change the end result though. It just
changes the context around it.

Similarly I can understand how an aggressive dog came to be (poor training,
etc.). That won’t change my opinion that the dog should be put down when it
mauls a kid, you know?

~~~
falcolas
Perhaps it's the dog's owners who should be put down. After all, they'll just
get another dog and make it as aggressive as the previous one...

Blaming an innocent for how they were cultivated is silly. Especially when
those innocents can be rehabilitated.

We're getting a little off topic, but this company is just setting up another
Rick to take the blame when the train goes off the tracks again.

~~~
cupscale
If you read my other comments, you’ll see that I agree with you completely.

That doesn’t mean the dog shouldn’t be put down. It just means there are also
other parties at fault.

~~~
falcolas
It absolutely means the dog shouldn't be put down. Dogs, and more importantly
people, can be rehabilitated.

All it takes is one person in power to care enough to see to that
rehabilitation to transform an aggressive "dick" back into a productive team
member.

------
korzun
I briefed the original story, and one thing that stood out to me is that the
author threw a 'bomb' named collaboration into the mix AFTER firing so-called
Rick.

What author fails to understand, is that the problem could have been addressed
by collaboration as well.

I caught a 'scrum-master' CTO wanna-be that wrote an article about (omitting
my name) how he is happy I was gone because I was hard to manage. This guy
showed up and hanged his scrum-master certificate on the wall and promoted a
(fresh out of college) junior developer to management because he was there for
a year longer than me and proceeded to enable and reward the most idiotic
technical decisions I have ever seen while the rest of us was battling
scalability problems.

He never talked to me; he was in the room with his new director of engineering
(1 year of non-management experience, seriously) trying to come up with a
strategy on how to do things and then try to run with it without getting any
feedback.

Obviously, I shot them down, and it got to the point where they would come up
with this stuff (no communication) and could not provide any details (why will
this work? why is it better?).

I simply quit and never looked back at that point, they probably did
collaborate a lot more. And by collaboration, I mean circle jerk whatever
ideas sound great and force them on junior developers that do not know any
better.

~~~
watwut
Except that, in this case, project continued more successfully without Rick
then it did with his unofficial leadership.

~~~
Andaith
I'm not entirely sure that's true. I have no evidence, I just don't think any
company would have a blog post "We had staffing problems, now we're buggered".
Instead it's "We had staffing problems, we fixed them, now everything is
amazing".

I also don't think things would have gotten this bad if the original dev team
could have picked up more of the slack, but I don't have experience in
dysfunctional workplaces. Still, the "We had one guy with all the domain
experience, then we fired him and all our other devs magically became amazing"
thing doesn't sit right with me.

~~~
watwut
They failed at fighting Rick, they failed at politics and they quite clearly
are not ready to be leaders. They did not failed at programming once the above
was solved by new leader.

Yeah, because that framing is imo wrong too.

1.) In all likelihood, they Rick was not that much genius, although he might
have some more more knowledge initially and probably was not bad programmer
either. There is nothing to show he was genius.

Here I will make the guess: Rick belittled other people and criticized
everything they did and simultaneously had more initial knowledge. That made
everyone assume Rick is genius and others are low skilled. The politics follow
from there. Note that other people did not slacked at work nor took three
hours long lunches (I assume). Them working overtime would fix nothing.

Local praised genius belittling other employees has predictable consequences -
it is that others look significantly less skilled then they are to management
(yeah management is to blame too) and those people know it. It also means
those people will learn to not have ideas and not have initiative, because
they get insulted for those and because those invariably turn against them. As
I told, it is very predictable.

2.) The other people did not turned from people who are learned to be passive
to people who suddenly got agency and autonomy. Nothing in their programming
skills changed, only people management of leadership of company changed.

And note how them not being arrogant still means they get comparably very
little credit for technical talent or skill. (I see that as pattern in it.)

