10 ms·

You fired your top talent. I hope you’re happy

460 points by ech 9y ago

provost 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
  - user5994461 9y ago
    It's simple to avoid: 1) don't work more than 45 hours a week, ever. 2) if you are forced to work any saturday or sunday, you take one day off in the following week. 3) don't work when you are outside of work. no remote access, no email, no slack, no app on your phone, don't accept calls from work.
- SomeStupidPoint 9y ago
  Can I ask what you're hoping to get out of a book? You already seem aware of and thoughtful about the issue. (To the point you could identify a similar one in fiction.) I'm always loathe to recommend books about techniques -- almost invariably, they're used in a process-as-proxy way. (If I had one piece of advice of managers, it would be that -- don't manage by proxy!)
- davidcbc 9y ago
  When I was reading "The Phoenix Project" I thought that the outcome there was going to be the same as in the original article this post is responding to. The "hotshot" developer would be fired and everyone would live happily ever after without addressing the reason things got so bad. I was pleasantly surprised when they acknowledged this is largely a management issue and worked to fix the underlying causes instead of using the developer as a scapegoat.
- cannonedhamster 9y ago
  The One-Minute Manager is a general book on how to appropriately manage people. How to Win Friends and Influence People is a fantastic book on people in general. Influence is a great book for managing up, or understanding why your people react the way that they do. The basics for any manager are the following: 1. Know what you're solving for, know what your people are solving for. Make sure that they are in alignment. 2. Invest in your people. Time, money, etc. Not just technical skills, but soft skills. A smile and remembering someone's name go a long way. 3. Keep everything that isn't their job, out of their job. If someone is a bottleneck then there needs to be a defined point in time every week where they do documentation and/or training until they are no longer the bottleneck. Assume it will take other people longer to do the same task at first and accept it, make sure that they understand this is normal. Edit: I'd also include this blog post in your reading: http://firstround.com/review/this-90-day-plan-turns-engineers-into-remarkable-managers/ http://firstround.com/review/this-90-day-plan-turns-engineer...
pault 9y ago
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."
- thisisit 9y ago
  Personally I think those are important enough points to be included in the main post. People shouldn't need to dig through the comments to see those. But these statements came ex-post and that too when people pointed out obvious holes in the original post. So these sound like the original writer was coming up with excuses to absolve the company of wrongdoing. Oh..you mean vacation..yea sure we did that.....you mean manager was responsible....ye sure we fired him.
  - mercer 9y ago
    I can imagine the writer not intentionally hiding these things, but I do agree that they should be added to the original article.
    - thisisit 9y ago
      I am not too sure because if I want to make noise about how my developer screwed up, highlighting the incompetence of the direct manager played a big part as well. Yea sure maybe the minute detail of management overtures being refused can be missed because they wanted to portray themselves as a good guy. From the looks of it the whole thing was written from "an expose on star developer culture" point of view. In which case, admitting your own mistakes in the first draft takes backseat and it's all about the "star developer". What is even more surprising is given that so many people have pointed out this hole, there hasn't been an edit to clarify this point. I am not digital content expert but if it does spread wide, no one is going to care what is in the comments.
thisisit 9y ago
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.
- corford 9y ago
  >Given the kind of unreasonable demands, people do crack. Haha. As in mentally or the drug? :D P.S. Awesome video, thanks for sharing.
- RenierZA 9y ago
  And here's the solution: https://www.youtube.com/watch?v=B7MIJP90biM https://www.youtube.com/watch?v=B7MIJP90biM
  - Gigablah 9y ago
    He's missing a few dimensions.
    - dennisgorelik 9y ago
      "Dimensions" are not the part of requirements.
cupscale 9y ago
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.
- pault 9y ago
  They responded to these points in a comment on the original article, which acknowledged management's responsibility for creating the problem, and they say they fired his manager first.
  - cupscale 9y ago
    I'll admit that I'm particularly touchy about bad people managers, but it really does seem like they just washed their hands of the problem without trying to really discern: * Why this became such a big problem (and wasn't resolved earlier) * How to prevent it from happening in the future Because if one team can effectively silo themselves so well that problems like Rick are allowed to fester for multiple years, I don't have high hopes for the future for them.
le-mark 9y ago
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.
- jchw 9y ago
  That's not really the point. The point is that the company is patting themselves on the back for firing someone who, by their own description, sounds like they could've provided a ton of value with better management (and even did, at first.) There's nobody who should be patting themselves on the back in this story. It's a story of a bunch of incompetent managers and a programmer that couldn't manage himself, and evidently someone high up in the company that's proud of this somehow.
  - philipov 9y ago
    If you treat your stars like cows, they become dogs.
    - cannonedhamster 9y ago
      If you stop feeding your milk cows and expecting higher output, eventually they stop producing at all.
- lucisferre 9y ago
  "managing your manager" is great in theory, but a lack of managing up doesn't absolve management of their primary responsibility to do that job themselves. Their direct reports already have primary responsibilities to do the work, expecting them to also do yours is a little bit much. Managers who want their reports to develop the skills to "manage up" have a responsibility to help them develop those skills and should not simply expect them.
jlg23 9y ago
> 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.
kahlonel 9y ago
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.
whipoodle 9y ago
Music to my ears.
Sevrene 9y ago
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.
- rjzzleep 9y ago
  I'm not sure other industries do handle it better. I would argue that it's a prevalent problem. There has to be a reason, why there are a bunch of studies on success and failure ratios of projects. A lot of them explicitly stating that the top issues are bad communications, lack of priorities etc. One of the standard PM exams even has frequent exam question about how sources of conflicts in projects in the following order: schedules, project priorities, resources, technical opinions, administrative procedures, cost and personality Personality is always last. Yes, there are exceptions. There always are, but in general lack of experience at the top gets pushed down the chain. Top performers are always the first to be negatively affected though.
  - user5994461 9y ago
    Personality is not a thing as such. What matter is the environment. People adapt to their environment. Most character issues are a response to the work environment.
leroy_masochist 9y ago
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 9y ago
  the real MVP
conorcleary 9y ago
Medium is trying to be Cracked with this article style.
- pc86 9y ago
  Medium doesn't have editorial control over what its users post on the site.
drawkbox 9y ago
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.
- deleted 9y ago
  [deleted]
- internetman55 9y ago
  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.
korzun 9y ago
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.
- forgottenpass 9y ago
  I vouched this comment. I'm sure it was dinged for not using mild-mannered business vocabulary to describe the former workplace. But I've seen some form of this play out in real life enough times to tell your assessment probably isn't too far off, and you were right to get out of there. Finding someone that's actually dedicated and not just willing to say "dedication" in an interview needs a position that won't burn them out, or the knowledge of when to quit. Having neither is a disaster waiting to happen.
- watwut 9y ago
  Except that, in this case, project continued more successfully without Rick then it did with his unofficial leadership.
  - Andaith 9y ago
    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.
mikl 9y ago
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.
perpetualcrayon 9y ago
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?
- candiodari 9y ago
  You haven't yet seen many SWEs decide on whether to do a rewrite yet have you ?
- dpark 9y ago
  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.
Shivetya 9y ago
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 9y ago
  There are always choices — either change your environment or change your environment.
  - lukaslalinsky 9y ago
    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 9y ago
      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.
- zimpenfish 9y ago
  > likely Rick never could off load his work because of management. It's possible. But it's also possible that he considered everyone else far below his acceptable level of skill and refused to delegate or allow other people's code into "his" codebase, even going as far as to ignore a team-blocking ticket for months until someone else picks it up, then blocks on the review, then when management finally say "get on this", rewrites it himself and commits his own code without review. What? No, I'm not bitter about recent experiences. Not at all.
scarface74 9y ago
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 9y ago
  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.
notyourday 9y ago
Personally, I'm patiently waiting for the third installment: "Our incredible story"
snarfy 9y ago
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 9y ago
  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 9y ago
    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.
cc81 9y ago
Could you please not spam "funny pictures" in a post like this. It makes it annoying to read.
- dpark 9y ago
  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 9y ago
    Once would have been enough. Twice to make a point. But then the point's made.
    - dpark 9y ago
      Shrug Tastes vary.
- scott_karana 9y ago
  I remember seeing maybe four, and thought they were enjoyable. Taste's a funny thing.
- whipoodle 9y ago
  Oh, stop.
brooksbp 9y ago
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.
Beltiras 9y ago
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.
disease 9y ago
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.
thestephen 9y ago
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.
- user5994461 9y ago
  A team of 3 people for 6 months is a total of 3000 hours*men. They can do a lot.
- Angostura 9y ago
  Actually, I'm pretty sure what happened next was a dozen influential customers enquiring where those multiple weird little edge-case features that they relied on had gone in in the new, seemingly "dumbed down" release - the features that they had explicitly requested two years ago, which Sales had promised to get the sale, and which Rick had implemented in a bit of a hurry, noting that it would need to be refactored later.
- talmand 9y ago
  I'm curious how they managed to refactor about 150,000 lines of code down to a few thousand lines.
  - x1798DE 9y ago
    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 9y ago
      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.
golemotron 9y ago
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?
oandrei 9y ago
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/2017/10/the_nobel_prize_does_science_a_serious_disservice.html http://www.slate.com/articles/health_and_science/science/201... and here : https://www.theguardian.com/commentisfree/2017/sep/30/we-hail-individual-geniuses-success-in-science-collaboration-nobel-prize https://www.theguardian.com/commentisfree/2017/sep/30/we-hai... 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 !
pascalxus 9y ago
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 9y ago
  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.
- chiph 9y ago
  At a minimum, shops should have some short documents that explain where the code is in source control, what is needed to build it, where it got deployed, and some general idea about how to do a full system test. Call it the "Hit by a bus" doc if you want. Or more nicely -- the new hire orientation doc. And it's management's job to ensure it gets kept up to date. Because it's a business continuity issue.
pascalxus 9y ago
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 9y ago
  Management can't teach what they don't know ;)
chandmk 9y ago
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.
iwanttoreply 9y ago
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.
codesternews 9y ago
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 9y ago
  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.
watwut 9y ago
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.
kazinator 9y ago
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.
cannonedhamster 9y ago
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.
RcouF1uZ4gsC 9y ago
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 9y ago
  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.
ne01 9y ago
They did not fire Rick, they freed him. Ricks should not be slaved!
moon_of_moon 9y ago
"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.
stillsut 9y ago
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.
internetman55 9y ago
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?
equalunique 9y ago
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.

460 points by ech 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.
- user5994461 9y ago
  It's simple to avoid: 1) don't work more than 45 hours a week, ever. 2) if you are forced to work any saturday or sunday, you take one day off in the following week. 3) don't work when you are outside of work. no remote access, no email, no slack, no app on your phone, don't accept calls from work.
SomeStupidPoint 9y ago
Can I ask what you're hoping to get out of a book? You already seem aware of and thoughtful about the issue. (To the point you could identify a similar one in fiction.) I'm always loathe to recommend books about techniques -- almost invariably, they're used in a process-as-proxy way. (If I had one piece of advice of managers, it would be that -- don't manage by proxy!)
davidcbc 9y ago
When I was reading "The Phoenix Project" I thought that the outcome there was going to be the same as in the original article this post is responding to. The "hotshot" developer would be fired and everyone would live happily ever after without addressing the reason things got so bad. I was pleasantly surprised when they acknowledged this is largely a management issue and worked to fix the underlying causes instead of using the developer as a scapegoat.
cannonedhamster 9y ago
The One-Minute Manager is a general book on how to appropriately manage people. How to Win Friends and Influence People is a fantastic book on people in general. Influence is a great book for managing up, or understanding why your people react the way that they do. The basics for any manager are the following: 1. Know what you're solving for, know what your people are solving for. Make sure that they are in alignment. 2. Invest in your people. Time, money, etc. Not just technical skills, but soft skills. A smile and remembering someone's name go a long way. 3. Keep everything that isn't their job, out of their job. If someone is a bottleneck then there needs to be a defined point in time every week where they do documentation and/or training until they are no longer the bottleneck. Assume it will take other people longer to do the same task at first and accept it, make sure that they understand this is normal. Edit: I'd also include this blog post in your reading: http://firstround.com/review/this-90-day-plan-turns-engineers-into-remarkable-managers/ http://firstround.com/review/this-90-day-plan-turns-engineer...

pault 9y ago

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

thisisit 9y ago
Personally I think those are important enough points to be included in the main post. People shouldn't need to dig through the comments to see those. But these statements came ex-post and that too when people pointed out obvious holes in the original post. So these sound like the original writer was coming up with excuses to absolve the company of wrongdoing. Oh..you mean vacation..yea sure we did that.....you mean manager was responsible....ye sure we fired him.
- mercer 9y ago
  I can imagine the writer not intentionally hiding these things, but I do agree that they should be added to the original article.
  - thisisit 9y ago
    I am not too sure because if I want to make noise about how my developer screwed up, highlighting the incompetence of the direct manager played a big part as well. Yea sure maybe the minute detail of management overtures being refused can be missed because they wanted to portray themselves as a good guy. From the looks of it the whole thing was written from "an expose on star developer culture" point of view. In which case, admitting your own mistakes in the first draft takes backseat and it's all about the "star developer". What is even more surprising is given that so many people have pointed out this hole, there hasn't been an edit to clarify this point. I am not digital content expert but if it does spread wide, no one is going to care what is in the comments.

thisisit 9y ago

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.

corford 9y ago
>Given the kind of unreasonable demands, people do crack. Haha. As in mentally or the drug? :D P.S. Awesome video, thanks for sharing.
RenierZA 9y ago
And here's the solution: https://www.youtube.com/watch?v=B7MIJP90biM https://www.youtube.com/watch?v=B7MIJP90biM
- Gigablah 9y ago
  He's missing a few dimensions.
  - dennisgorelik 9y ago
    "Dimensions" are not the part of requirements.

cupscale 9y ago

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.

pault 9y ago
They responded to these points in a comment on the original article, which acknowledged management's responsibility for creating the problem, and they say they fired his manager first.
- cupscale 9y ago
  I'll admit that I'm particularly touchy about bad people managers, but it really does seem like they just washed their hands of the problem without trying to really discern: * Why this became such a big problem (and wasn't resolved earlier) * How to prevent it from happening in the future Because if one team can effectively silo themselves so well that problems like Rick are allowed to fester for multiple years, I don't have high hopes for the future for them.

le-mark 9y ago

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.

jchw 9y ago
That's not really the point. The point is that the company is patting themselves on the back for firing someone who, by their own description, sounds like they could've provided a ton of value with better management (and even did, at first.) There's nobody who should be patting themselves on the back in this story. It's a story of a bunch of incompetent managers and a programmer that couldn't manage himself, and evidently someone high up in the company that's proud of this somehow.
- philipov 9y ago
  If you treat your stars like cows, they become dogs.
  - cannonedhamster 9y ago
    If you stop feeding your milk cows and expecting higher output, eventually they stop producing at all.
lucisferre 9y ago
"managing your manager" is great in theory, but a lack of managing up doesn't absolve management of their primary responsibility to do that job themselves. Their direct reports already have primary responsibilities to do the work, expecting them to also do yours is a little bit much. Managers who want their reports to develop the skills to "manage up" have a responsibility to help them develop those skills and should not simply expect them.

jlg23 9y ago

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

kahlonel 9y ago

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.

whipoodle 9y ago

Music to my ears.

Sevrene 9y ago

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.

rjzzleep 9y ago
I'm not sure other industries do handle it better. I would argue that it's a prevalent problem. There has to be a reason, why there are a bunch of studies on success and failure ratios of projects. A lot of them explicitly stating that the top issues are bad communications, lack of priorities etc. One of the standard PM exams even has frequent exam question about how sources of conflicts in projects in the following order: schedules, project priorities, resources, technical opinions, administrative procedures, cost and personality Personality is always last. Yes, there are exceptions. There always are, but in general lack of experience at the top gets pushed down the chain. Top performers are always the first to be negatively affected though.
- user5994461 9y ago
  Personality is not a thing as such. What matter is the environment. People adapt to their environment. Most character issues are a response to the work environment.

leroy_masochist 9y ago

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 9y ago
the real MVP

conorcleary 9y ago

Medium is trying to be Cracked with this article style.

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

drawkbox 9y ago

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.

deleted 9y ago
[deleted]
internetman55 9y ago
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.

korzun 9y ago

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.

forgottenpass 9y ago
I vouched this comment. I'm sure it was dinged for not using mild-mannered business vocabulary to describe the former workplace. But I've seen some form of this play out in real life enough times to tell your assessment probably isn't too far off, and you were right to get out of there. Finding someone that's actually dedicated and not just willing to say "dedication" in an interview needs a position that won't burn them out, or the knowledge of when to quit. Having neither is a disaster waiting to happen.
watwut 9y ago
Except that, in this case, project continued more successfully without Rick then it did with his unofficial leadership.
- Andaith 9y ago
  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.

mikl 9y ago

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.

perpetualcrayon 9y ago

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?

candiodari 9y ago
You haven't yet seen many SWEs decide on whether to do a rewrite yet have you ?
dpark 9y ago
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.

Shivetya 9y ago

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 9y ago
There are always choices — either change your environment or change your environment.
- lukaslalinsky 9y ago
  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 9y ago
    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.
zimpenfish 9y ago
> likely Rick never could off load his work because of management. It's possible. But it's also possible that he considered everyone else far below his acceptable level of skill and refused to delegate or allow other people's code into "his" codebase, even going as far as to ignore a team-blocking ticket for months until someone else picks it up, then blocks on the review, then when management finally say "get on this", rewrites it himself and commits his own code without review. What? No, I'm not bitter about recent experiences. Not at all.

scarface74 9y ago

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 9y ago
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.

notyourday 9y ago

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

snarfy 9y ago

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 9y ago
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 9y ago
  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.

cc81 9y ago

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

dpark 9y ago
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 9y ago
  Once would have been enough. Twice to make a point. But then the point's made.
  - dpark 9y ago
    Shrug Tastes vary.
scott_karana 9y ago
I remember seeing maybe four, and thought they were enjoyable. Taste's a funny thing.
whipoodle 9y ago
Oh, stop.

brooksbp 9y ago

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.

Beltiras 9y ago

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.

disease 9y ago

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.

thestephen 9y ago

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.

user5994461 9y ago
A team of 3 people for 6 months is a total of 3000 hours*men. They can do a lot.
Angostura 9y ago
Actually, I'm pretty sure what happened next was a dozen influential customers enquiring where those multiple weird little edge-case features that they relied on had gone in in the new, seemingly "dumbed down" release - the features that they had explicitly requested two years ago, which Sales had promised to get the sale, and which Rick had implemented in a bit of a hurry, noting that it would need to be refactored later.
talmand 9y ago
I'm curious how they managed to refactor about 150,000 lines of code down to a few thousand lines.
- x1798DE 9y ago
  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 9y ago
    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.

golemotron 9y ago

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?

oandrei 9y ago

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/2017/10/the_nobel_prize_does_science_a_serious_disservice.html http://www.slate.com/articles/health_and_science/science/201... and here : https://www.theguardian.com/commentisfree/2017/sep/30/we-hail-individual-geniuses-success-in-science-collaboration-nobel-prize https://www.theguardian.com/commentisfree/2017/sep/30/we-hai... 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 !

pascalxus 9y ago

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 9y ago
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.
chiph 9y ago
At a minimum, shops should have some short documents that explain where the code is in source control, what is needed to build it, where it got deployed, and some general idea about how to do a full system test. Call it the "Hit by a bus" doc if you want. Or more nicely -- the new hire orientation doc. And it's management's job to ensure it gets kept up to date. Because it's a business continuity issue.

pascalxus 9y ago

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 9y ago
Management can't teach what they don't know ;)

chandmk 9y ago

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.

iwanttoreply 9y ago

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.

codesternews 9y ago

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 9y ago
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.

watwut 9y ago

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.

kazinator 9y ago

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.

cannonedhamster 9y ago

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.

RcouF1uZ4gsC 9y ago

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 9y ago
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.

ne01 9y ago

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

moon_of_moon 9y ago

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

stillsut 9y ago

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.

internetman55 9y ago

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?

equalunique 9y ago

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.