We fired our top talent. Best decision we have ever made. Free Code Camp, you actually just reached out recently for a sponsorship. Are you trying to tell me I'm I'm not top-line talent here? Is that what you're saying? Are you implicitly calling me soft? Is that what

you're saying? I don't know how I feel right now. I honestly don't know how I feel right now. I'm hurting right now. Jonathan, let's go. You will never be able to understand any of what I've created. I am Albert effing Einstein and you are

all monkeys scrabbling in the dirt. Oh, beautiful wife, thank you. So our resident genius, Dr. Jackal, explosively completed his transformation into Mr. Hyde. He declared this in front of our product design team, developers, management, and pre-launch customers. One of our project sponsors had the audacity

to ask when the problem crippling our product would be fixed. Wait, someone actually said this out loud? Hell yeah, dude! Can I can I somehow be in that meeting? I want to be called a monkey scribbling in dirt like I I want to be that guy. I want to be sitting there

going, 'I'm too stupid. Yeah, yeah, I'm stupid.' I want I want to be in there. I want to see this genius. It's a fickle beast. Sometimes you have the good fortune to work with a mad genius. Other times you are doomed to work with pure

madness. I love that statement. There was a genius, the guy that wrote 'The Rime of the Ancient Mariner,' Coleridge, and throughout his life he struggled with alcoholism and he would often go mad and he would talk. They, in fact, another great poet, I forget the guy's name, said that he would

talk from dawn until dusk or he used some specific phrase that Milton also used in Paradise Lost when describing Satan's fall from Heaven to Hell and he said the same thing that that Coolidge could talk like the devil and he would actually turn people like

there's writings about people saying I am not willing to meet with you again because of how much you talk and like how mad he was genius is real and it can be crazy to me this isn't a genius this is just this is just this is just a blow

this is just a blowhard other times you are doomed to work with pure Madness there are also times when it's hard to tell the difference this story is about the Fall From Grace of an extremely gifted team member with a deep understanding of our product's

architecture he had an uncanny AB uncanny ability to forecast future requirements and a ton of domain specific knowledge ooh this is a hard fire that's a hard fire when someone can do this that's a hard fire he was our top contributor he was killing our

Flagship project project ooh we'll call this person Rick effing Rick you should have first off huge fail here should have called him Tom everybody knows about Tom Tom's a genius you wouldn't understand this you called him Rick Mr Sanchez pickle Rick good old fashioned

pickling you know what I mean Rick was universally recognized on the team as the top talent he was the lead developer and architect of the software projects anytime anyone had a question about code or needed help with the task they would go to Rick Rick had a giant whiteboard

installed in his office, used only for this purpose. It was always cluttered with ghosts of past discussions that uh that wouldn't quite erase anytime there was a particularly challenging... By the way, if you can get a whiteboard in your office, your IQ, your perceived

IQ, goes up an entire generation, like 15 points. It's the fastest way to make people think you're smarter is just just be closer to a whiteboard. Right, proximity to a whiteboard, it's just like stocks, it's like the Netflix stock honestly, it's just like Netflix

stock. Yes, we're going up today, we're going up people, 0.13%. Let's go, let's go. Oh boys, red lobsters on me tonight. Anytime there was a particularly challenging problem, Rick would handle it. Rick had a server, had a server with the

same specs as our production server, installed at his desk. He used this to run the entire application stack independently and troubleshoot every layer at once. Oh yeah, Rick didn't need anybody else. Rick preferred to work alone in his private workspace. Rick didn't need anything anybody else built.

He built everything he needed from scratch because it was infinitely better than the paltry offerings of mere mortals. That's pretty exciting. Soon Rick stopped attending meetings. All right, yeah, that's a good, that's a power move right there. Rick, okay, this is a p this

is a power move right here. Okay, I'm just not attending meetings. Okay, okay, I aspire to be Rick. Yeah, I think we need to all aspire to be Rick right now. Rick didn't have time for meetings anymore because there was too much to code. Let's go Rick. Rick closed

his door his whiteboard lay uh for Rick no longer had time to train anyone because he had too much to solve on his own Interesting so there's a kind of a weird story going on here I wonder if this whole Fall From Grace this whole

Milton fall going on right here from from dawn to dusk I wonder if part of the problem also lay in the management of Rick Let me guess the next step he did was ask HR how strict the sexual harassment policies were Sounds like a

move a Rick would do I'm just saying cuz this already sounds like people really like what he's producing so they let Rick keep making these bad decisions thus creating Rick into the villain right All legends live long enough to become villains Let Rick cook they let

Rick cook that's the problem is they kept letting Rick cook They made Rick okay a backlog grew behind Rick Bugs were popping up in old tools he built They snapped his attention from meeting commitments on new product development Got to be careful about this I mean

homegrown tools are both the the best thing and the worst thing right now I'm in the process of making a determination about using an industry standard tool or what we can do ourselves to meet our specific needs and our specific needs are just different than what the

industry needs but at the same time this is a this is a real problem about building your own tools is that you will lose time because you also have to start meeting things Homegrown is the worst It's not the worst Sometimes homegrown is the best Type one in the chat if you

I love React. There are a couple ones, there's not a lot of ones, but there is some ones in chat. Think about that for a second though, that's a homegrown tool, okay? What about Solid? Anyone here wants Solid? That's the thing is that just because something's homegrown doesn't

mean it's bad or good. Homegrown works if the company that produces it makes room for it to be successful. Does that make sense? Yes. I like Metal Gear Solid. When I worked on Falcor, Netflix Falcor should have been more successful, honestly. It should, it should have been so much more

successful than it was. It honestly, there's a lot of good things about Falcor. I think there's some things that we could have made a lot better. Falcor had a lot of really good ideas in it. The reason why it wasn't successful is that

pretty much at one point it was just me programming it. It was really, really hard, you know, and the problem space was huge. Falcor mentioned, let's go, I ain't Rick, I'm just saying you need tools, you need support. You need someone like that's thrown together the LSP. You need

somebody that's thrown together documentation. You need somebody that's also meeting bugs, that's talking with people. You also need someone that's managing the community. Falcor's community, when we released Falcor in 2015 I think to the public, it had 5,000 stars

on GitHub. That's crazy, back then that was like day one. You realize there all of a sudden there was like thousands. I'm going through thousands of issues trying to fix all these people's issues, responding to everything. It started showing up on questions on Stack

Overflow all of a sudden I'm on Stack Overflow answering all these questions then at work people are like why isn't this delivered why isn't this delivered where is all these things and you be like this is real you can't let Rick happen of course these bugs were

happening because the users had misstated their assumptions of course there wasn't any problem in his work of course on our project dashboard green flags changed to yellow yellow changed to red and red lights started blinking one by one task status has changed to

impeded everyone was waiting for Rick the project manager got a six-month extension from a sponsor at the end of the 6 months production Readiness was estimated to be a 7 months away at the end of the year production Readiness was 2 years out I totally get it I totally

get that software estimating is really really hard I know where is management and all this that exact well I mean the problem is that there's a beast they've created a beast I Rick was their own creation I mean obviously Rick allowed it to happen probably got a lot of

accolades slaps on the the back you know there's probably people being like wow I can't believe you created this thing this thing is so useful for what we're doing I'm not saying he was right he should have had the wisdom to know not

to build your own tools but also when everyone's cheering you on do you build your own tools Rick got the premium bathroom ramen all the time you know he did you know for a fact Rick he was getting that premium hand-fed wagyu bathroom ramen adab boys are nice adab

boys can make terrible decisions Rick was churning out code faster than ever he was working 7 days a week 12 hours a day everyone knew only Rick could pull the team out of this mess everyone held their breath and waited for Rick to invent a miracle cure that would

mend this crippled project every day Rick grew more belligerent and isolated really have you ever worked 7 days a week you know what happens when you do that that's some big Rick energy right there the mask was coming off Jackal was

becoming hide I participated in my first meeting with the project team about 2 years after the original agreed release date I'd been aware of the project for a while because it had grown infamous in my organization and hadn't been assigned to it I was sent to see if

we could save it my first meeting on the project was the aforementioned Albert Einstein meeting I went into the source code Rick was right no one could possibly understand what Rick had created except for Rick it was a reflection of the workings of his own mind some of it was

very clever a lot of it was copy-pasta it was all very idiosyncratic and it was not all well documented I went to our CIO with the verdict only Rick would ever be able to maintain this product plus every day that Rick worked on the

project moved the delivery date back a week that's an oof right there Rick was a negative 10x engineer all along like I've like we've said we've said quite a bit on this channel for a long time that the only true 10x engineer is

the engineer that can create 10x the work they just need more Ricks honestly just more Ricks we sat down with Rick and had a conversation about his role in the project we reviewed our concerns we sidestepped his self-comparison to Albert Einstein that's probably a good

move you know if anyone ever says that they're on the level of Albert Einstein probably a good move to avoid it they drove Rick into burnout then fired him yeah yeah that's what it that's that's what we're about to look at free code

Camp I don't think this article is doing what you think it's doing free Camp I'm not sure if you're reading the article the way other people are reading it we explained our new strategy the team was going to collaborate on building new products from scratch this

effort would be very limited in scope and would only provide the bare essentials to get us to production the whole team would contribute and be able to support it no bottlenecks how did Rick react to this the only way Rick could Rick exploded yeah imagine working

on something for 12 hours a day 7 days a week after being cheered on and told that you're great at this only to become slowly more and more burnt out to at the end someone says we're going to throw away all those years of work they

are Dr Frank like I just think about this for Rick like from Rick's perspective for a second dude what I mean here's here's the real deal though you should always control your emotions there's no excuse to like you should really never try to let yourself

explode they created a main character and then realized there ain't no main character I feel for Rick I don't Albert Einstein said some Albert Einstein was feisty I hope you know that all of Albert Einstein's quotes none of them are nice yeah I don't know work seven

days a week in a row for a while and see how your temper is Judo that's what happened to me that's the falcore time dude I flew off the handle at some point I went to my boss met with her and I was

like I quit this [ __ ] I quit [ __ ] everything that was me I did that it's what happens when you work too much you you lose you lose it you lose perspective on life Rick I wanted no part of this farce if we couldn't

appreciate his genius that was our fault not his Rick predicted that within months we'd come crawling back to him begging uh him to save us Rick screamed that we lacked the basic mental capacity to appreciate genius when it was staring us in the face I I you know the one

thing I don't get about Rick though is have you ever been in this situation I feel like if you've been in this situation I wouldn't be screaming this I'd be screaming like why the hell haven't you done all these things right like I feel like I'd be screaming a

different set of tunes sadly after this Rick rejected months of overtures by leadership he refused to take time off or allow any work to be delegated he rejected repeated attempts to introduce free open source frameworks to replace his hard-to-maintain bespoke tools he reverted code changes including tested

uh bug fixes by other developers he asserted that he wouldn't be held accountable for supporting other people's work he continued publicly belittling his colleagues we fired Rick I mean I do agree public belittling is not is not good I think this is more

based on a true story I don't know I just assume free code Camp probably wouldn't want to exaggerate too hard about somebody can we all just agree on this one this is a no Rick team it took about a week for the dust to settle it

took time for the shocked team to gather themselves after losing their embattled Guru then I saw them huddle around a whiteboard collaboration stock photo of collaboration you can tell because it has a hard hat and no person in the

universe has rolled up paper at their desk this this tall they collaborated they designed a replacement product it would be much simpler it wouldn't have all the bells and whistles nor would it anticipate requirements from 5 years down the product road map never write

real code without a real hard hat Rick's a product supported a dynamic workflow with over 15,000 permutations in reality 99% of our use cases followed one of three paths holy [ __ ] wait a second I know this plot this is the Black Mirror

Choose Your Own Adventure movie wait a second Black Mirror Choose Your Own Adventure this is just this is just Bandersnatch did they just did they just did they are they retelling Bandersnatch is that what we're getting right now this is such a Bandersnatch moment

Netflix mentioned, let's go, this removed over 30% of Rick's work. The team hardcoded the workflow, by the way, this is like the greatest way to do things. I do want to say that if you're building something that has a workflow, just build

the effing workflow. Stop trying to create a system that's going to solve every possible workflow ever created. It doesn't work that way. It wouldn't have, uh, custom hand-coded components for every task. They stripped out every bespoke dependency that they could, buy instead of build. Nice. This removed

hundreds of hours of, uh, of Rick's contributions, but it also removed thousands of hours of technical debt. We obtained an agreement from the project sponsor to shut off the edge case functionality. This had served only 5% of our pre-launch user group and was

responsible for about a quarter of the product's complexity. 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. That's a lot. That's a lot of coding. That's a lot of coding. The team had replaced 5 years of work in about 6 months. Over the next few months, we expanded from pilot to full customer release. Not only had we replaced what

Rick had built, we spent, we, we sped past him and fully launched the product, all in under a year. The result was less than a fifth the size of complexity of what Rick had built. Yeah, if only, if, if only there was somebody, hear me out here, hear

me out here everybody just just hear me out just for a second okay imagine if there was like a position where somebody manages the product and prevents people from over engineering it imagine not possible I don't think that exists okay that'd be amazing yeah I know I'm an idea

man I'm an idea man okay a scrum mommy we need a scrum mommy we need a scrum mommy immediately soy chaotic where are you I always call you soy chaotic I know it's soy chotic okay but in my head it's

soy chaotic okay cuz it's more descriptive I feel like you're our scrum mommy so I need you in here telling Rick how to live Rick you could save him you could change him okay I believe in you it was also hundreds of times faster

nearly bug-free despite having been assembled in a fraction of the time and serving 10 times as many customers that went back to Rick's other products they threw away his old code too they re-released another product after his 3

years in development with 3 months of concerted team effort there were no Ricks left on the team we didn't have any mad Geniuses building everything from scratch but our productivity was never higher Rick was a very talented developer Rick could solve complex business logic problems and created

sophisticated architectures to support his lofty designs Rick could not solve the problem of how to work effectively on a team this is a hard one I still go back to this one as being a very hard one I I like using open source tools until they quit fitting your needs then

you kind of have to build from scratch or find a new tool. What a long LinkedIn post. Rick's presence was destructive in several ways. First, he created a cult of dependence. Any problem eventually became a Rick problem, a myth he encouraged. Developers learned to stop trying and

just wait for Rick. Second, he didn't write maintainable code. He never documented or tested anything and he failed in spite of his own intelligence. His belief in his personal infallibility trumped common sense. Third, he was personally destructive. Team members didn't want to speak up and offer their

own ideas because he always berated them for it. Rick only respected Rick and went out of his way to make everyone else feel small. Fourth, he lacked all personal accountability. No failure was his fault. He sincerely believed this and prevented him from learning his own mistakes. I

don't believe Rick started out this way. I saw him at his best. This was after years of working escalated overtime and facing increasing criticism from customers and colleagues. It's sad that Rick descended this far. His manager shared in this responsibility. This is good. I'm glad

that they because you know what this should have been classic narcissism. Everyone's a narcissist, okay. Real talk time and circumstances. People, time and circumstances. That's what separates you from Rick. Some people are more narcissistic than others. I feel like

that's kind of a narcissist point of view, my friend. I hate when you decide to use a tool and then it takes longer to make uh it work in your use case and would would have been just to write the own thing directly to fit your needs.

It's sometimes hard to know which way yes, that's but that's the thing is that I I feel like a responsible developer first fails by using open source and then fails by trying to write it internally. You should first fail by using open source. Unfortunately, Rick was

so far gone that he couldn't or wouldn't be brought back. No amount of coaching, feedback, time off, or assignment to other projects could change his toxic behavior by this point. I mean, firing actually is a pretty good move like if sometimes you need a sharp wake-up call and that can

really help you or you'll just descend further, depending on which one. By this time the whole team knew he was destructive, but the cult of dependence was so strong that everyone believed he was the only option. There is always another option. Your team strength is not a function of

the talent of individual team members, it's a function of their collaboration, tenacity, and mutual respect, and their talent as well. Also, maybe it is also like cuz if you have a really tenacious, highly collaborative, very respectful group of idiots, you're still going to build

bad software. There's definitely you can't just you can't just throw talent out the window. Maybe talent is still semi-relevant, you know what I mean? Like maybe you got to put a little little you got to put like a little something in there. Focusing on building teams that

value each other and try to bring the best out of one another together, they'll be able to tackle greater challenges than Rick could ever fathom. It's just like Wheel of Time, when women can link together, but a man can't link together without a woman, and so therefore a woman

could defeat a man by joining with another woman, even the strongest man could be defeated by multiple women. Teamwork makes the dream work, everybody knows that. Wheel of Time reference, let's go. Not Amazon Wheel of Prime, okay? If you haven't seen Wheel of Prime, you don't

need to watch that, but Wheel of Time, good book. Hey, if you don't know Wheel of Time, you're a loser. That's all. Come on, you don't read extensive worldbuilding fantasy that's like 10,000 pages long? What do you guys do with your free time?

It's described in this. I took place many years ago and do not reflect the opinions or experiences of my current employer. I have published follow-up uh story with our lessons learned if you're interested in reading more. And then this is just like, hey, I got a Physics degree

from Stanford University. I've never worked with anyone named Rick. Okay, good. Rick treating team is equal to Prime treating his chat. Yeah, I mean, but there's a difference here, okay? You guys are actual idiots, like I don't know what Rick's team was like, okay? I don't know

anything about who Rick was working with. Hey, YouTube chat rules, gosh, oh [ __ ] that's pretty good. I have a cousin Rick. A little torn on this one. Rick didn't fail alone. Yeah, I'm torn on this one too. Rick did not fail alone. I

think what what I I see a couple really good lessons here. One, the encouragement of the self-pre-individual can be very destructive. And you see this actually quite a bit at Netflix, in the sense that everybody works kind of more in silos. And silos are great if someone can

execute within that silo, and silos can also be very destructive if you have to have more and more cross-collaboration. And so that's kind of like, it's both really, really fantastic and both really, really hurtful sometimes. Sometimes you have to go into something and it's

really hard to work in that something because it's so siloed off. It's such a representation of that into like that individual's way of doing something. And so, is it good? Is it bad? I don't know. It's hard for me to tell. Tell Buzz

factor is important, and right now there's a lot of Buzz Factor. You know, how does a solo dev get feedback? That's another thing. It's very hard. The silos are both great and terrible, you know what I mean? That's why you have to

have standards. You have to have standards. But standards, I mean, the problem with standards is process. It's always the same thing. Process is both good and bad. I'm a bigger fan of less process. I don't think I should tell what another team should do. I think that team

should make that decision, but that naturally leads to silos. But that's okay in my personal opinion. But here's the deal, if that other team is dysfunctional and can't ever get something off the ground, that's a failure of the manager. The manager should have known things

aren't going well, that collaboration isn't going well, and that way you can get rid of this entire process. Let engineers discuss what they need, and management is supposed to be there to make things work. I don't know why people want this constant manager syncing

status updates every last little bit of information like you don't need that level, you need engineers building, managers ensuring timelines are going and that people are actually doing what they're saying they're doing. Right? Agile is a sign of bad management in some sense, yeah, depending on how agile that

agile is. Right? At some point, uh do you ever get help from other devs in Falor? So this is something I've always wanted to talk about. I'm not sure how to say it yet, but there's something that I I I there's a shortcoming out of this that

I I want to say, you constantly hear people saying, oh, we need to write all of our code in JavaScript because all we have are JavaScript engineers or something along that line, right? Where the problem is that we have to adhere to this one singular path because if we

don't, people on the outside who find bugs won't be able to contribute to what we're doing. And here's my kind of inverse take to to that, which is that I have been working on plenty of projects that were both inner source and open source for a company, and every single

Firing Our Top Talent Was The Best Decision Ever | Prime Reacts

This is a place for all the things that are awesome on stream. 

ThePrimeTime

Firing of Top Talent and Initial Reaction

The speaker recounts firing their top talent, questioning if a sponsorship request implies they are not top talent themselves.

The speaker expresses hurt feelings and compares themselves to Albert Einstein, belittling others as monkeys.

Dr. Jackal's transformation into Mr. Hyde is announced in front of various teams and customers.

The speaker expresses a desire to be in the meeting where the outburst occurred.

The speaker discusses the duality of genius and madness, using Coleridge as an example.

The speaker mentions another poet (name forgotten) who described Coleridge's talkativeness using a phrase from Milton's *Paradise Lost*.

The speaker distinguishes between true genius and mere bluster.

The story focuses on the fall from grace of a highly gifted team member.

Rick's Exceptional Skills and Growing Isolation

Rick, the top contributor, possesses exceptional skills and domain knowledge.

Rick's contributions and leadership are highlighted.

Rick's use of a whiteboard and a personal server for troubleshooting is described.

The perceived increase in IQ associated with having a whiteboard in the office is mentioned.

Rick's preference for working alone and building everything from scratch is emphasized.

Rick's avoidance of meetings and lack of time for training are noted.

The speaker questions whether management contributed to Rick's downfall.

Speculation about Rick's actions and the company's response.

The consequences of letting Rick continue his behavior are discussed.

The problems associated with homegrown tools are examined.

A discussion on the trade-offs between using industry-standard tools and building custom solutions ensues.

The speaker's experience with Falcor, a homegrown tool at Netflix, is shared.

The Project's Deterioration and Rick's Firing

The project's status deteriorates, with deadlines missed and increasing delays.

The difficulty of software estimation is acknowledged.

Rick's behavior is described as creating a 'beast' and receiving excessive praise.

Rick's work ethic and isolation are highlighted.

The team's dependence on Rick and his increasing belligerence are discussed.

The speaker recounts their first meeting with the project team and assessment of Rick's code.

The speaker's conclusion about Rick's code and its maintainability is shared.

The speaker discusses the conversation with Rick and the decision to fire him.

Post-Rick Collaboration and Project Revival

The team adopts a new collaborative strategy, building a simpler product from scratch.

Rick's reaction to the new strategy is described.

The speaker empathizes with Rick's perspective but emphasizes emotional control.

The speaker shares a personal anecdote about burnout and losing perspective.

Rick's further actions after being informed of the new strategy are detailed.

The speaker reflects on Rick's reaction and offers alternative perspectives.

Rick's continued destructive behavior after the decision is outlined.

The firing of Rick and the subsequent team's actions are described.

The team's collaboration and creation of a replacement product are highlighted.

The new product's simplicity and focus on common use cases are emphasized.

The comparison of the situation to the *Bandersnatch* movie is made.

The significant reduction in code size and complexity is noted.

The team's approach to simplifying the workflow is explained.

The removal of technical debt and edge case functionality is discussed.

The re-release of the product and the reduction in code size are highlighted.

The team's success in replacing years of work in a shorter timeframe is emphasized.

The positive outcomes of the project's revival are summarized.

The need for product management to prevent over-engineering is suggested.

The significant improvements in speed, bug-free operation, and customer reach are mentioned.

The success of the project after Rick's departure is highlighted.

Rick's talents and inability to work effectively on a team are contrasted.

The speaker discusses the challenges of using open-source tools and building from scratch.

Rick's destructive presence is analyzed through four key points.

The speaker reflects on Rick's downfall and the role of management.

The speaker discusses the importance of time and circumstances in shaping behavior.

The speaker shares their perspective on choosing between open-source tools and building custom solutions.

The speaker reiterates that Rick's behavior could not be corrected.

The importance of team collaboration, tenacity, and mutual respect is emphasized.

The speaker discusses the relevance of individual talent within a team context.

The speaker concludes with a reference to teamwork and the Wheel of Time series.

The speaker provides additional context and disclaimers.

The speaker addresses comments from the audience.

The speaker reflects on the lessons learned and discusses the impact of individual work styles.

The speaker discusses the duality of siloed work, highlighting its benefits and drawbacks.

The speaker discusses the importance of standards and process in software development.

The speaker emphasizes the role of management in fostering collaboration and addressing dysfunctional teams.

The speaker criticizes excessive management oversight and promotes a more hands-off approach.

The speaker discusses Agile methodologies and their potential downsides.

The speaker shares their perspective on the challenges of inner-source contributions.

The speaker argues against the necessity of using a single language for contributions.

The speaker's experience with inner-source projects and the lack of external contributions is highlighted.

The speaker's perspective on the impracticality of relying on external contributions is shared.

The speaker criticizes inner source as a flawed concept.

The speaker discusses the reasons why inner-source initiatives often fail.

The speaker explains why inner-source projects often lack external contributions.

The speaker discusses the risks associated with using obscure programming languages in internal projects.

The speaker expresses concerns about using JavaScript for internal services and CI/CD pipelines.

The speaker criticizes JavaScript's error handling capabilities.

The speaker explains their dislike of JavaScript and its error handling mechanisms.

The speaker elaborates on the frustrations of handling errors in JavaScript.

The speaker summarizes the key takeaways of the discussion.