TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

460 点作者 ech超过 7 年前

40 条评论

drawkbox超过 7 年前
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.<p>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 <i>very important meeting or deal</i>, if it is that important you want a solid product not a one off.<p>As a developer you also need to manage balance and workload. Consistent work discipline and good sleep&#x2F;health are important. Take on challenges but be sure each project is a focus and you aren&#x27;t spreading yourself too thin, work quality goes down when you don&#x27;t have some buffer. A good developer would never design a system that is constantly pegged, don&#x27;t do the same to your schedule&#x2F;self as that is a single point of failure.
评论 #15490654 未加载
评论 #15483441 未加载
scarface74超过 7 年前
I see so many sides to this<p>-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.<p>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.<p>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.<p>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.<p>I’m training the team not to be dependent on me.<p>When it comes to meetings, each developer is responsible for chasing detailed requirements when there are gaps.<p>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.
评论 #15483757 未加载
评论 #15484406 未加载
Sevrene超过 7 年前
While I can agree there are &#x27;real&#x27; rockstar developers that act like the original article mentions, I don&#x27;t think whether Rick was or wasn&#x27;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&#x27;s work for the last two years(!) and the end as their result.<p>Other industries seem to get this better than ours. I&#x27;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&#x27;s never the manager&#x27;s fault for assigning too many tickets or not prioritising their tasks correctly (we&#x27;re not mind readers) but yet it&#x27;s always the developers fault for the perceived lack of skill or lack of effort. Don&#x27;t get me started on the arbitrarily shifting release dates that correlate with buggy releases that we developers get angry emails about. Maybe I&#x27;ve worked at badly managed busineses, or hey, maybe I&#x27;m just a bad developer, but this seems like the normal to me.<p>But if you&#x27;re managing someone and they fuck up, it&#x27;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&#x27;t it&#x27;s still not up to him, it&#x27;s up to the manager to decide what&#x27;s best for Rick and best for the project.
评论 #15483324 未加载
评论 #15483413 未加载
评论 #15483064 未加载
cupscale超过 7 年前
Yeah, wow.<p>I mean, Rick&#x27;s a dick, no doubt. But much like Frankenstein&#x27;s monster, it&#x27;s incredibly easy to see who had a hand in transforming Rick into what he became. It&#x27;s hard to read the original article and not see several large &quot;where the hell was management&quot; red flags:<p>&gt; Any time there was a particularly challenging problem, Rick would handle it.<p>That&#x27;s a <i>management failure</i>, 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&#x27;re solving all of the challenging problems?<p>Fixing this doesn&#x27;t even involve being super confrontational:<p>&quot;I&#x27;ll fix &lt;database issue 123&gt;.&quot; &quot;Hey, Rick, you&#x27;re already working on XYZ and I want Summer to get some experience working with our database system, so I&#x27;d like for her to do it.&quot;<p>&gt; First, he created a cult of dependence.<p>Because management idly sat by and let him do that. People want to feel irreplaceable and like they&#x27;re exceptional. One way to do that is to create this cult of dependence. Management&#x27;s job is to step in and re-assure Rick that he&#x27;s a valued member of the team while also directly confronting this cult of dependence.<p>We do this all the time at my job, and we don&#x27;t even do it using complete thoughts. We just say &quot;bus factor&quot; and everyone understands why one person can&#x27;t be responsible all the time for something (or in this case, everything).<p>&gt; Team members didn’t want to speak up and offer their own ideas because he always berated them for it.<p>Holy shit, you didn&#x27;t torch his ass for berating people in meetings? Are there even managers at this company?<p>This, to me, is the worst failure. Either management is ignorant of the berating (bad) or they silently tolerated it (even worse).<p>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&#x27;re not, and attributing it to one bad employee, but I can hope.
评论 #15483422 未加载
评论 #15483199 未加载
评论 #15482883 未加载
评论 #15483114 未加载
le-mark超过 7 年前
There were a lot of failures in the Rick story &quot;on all sides&quot; 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 &quot;managing your manager&quot;. Whatever process you find yourself in, you have to be able to push back and say: &quot;I&#x27;m working on X, if you want me to work on Y, what do you want first? What&#x27;s the priority?&quot;<p>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&#x2F;CTO or someone. You have to have a buffer between these groups and development. If this doesn&#x27;t exist or you can&#x27;t get it, go elsewhere.
评论 #15482915 未加载
评论 #15483104 未加载
评论 #15483954 未加载
评论 #15485748 未加载
评论 #15483190 未加载
pault超过 7 年前
From a comment on the original post:<p>&quot;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.&quot;<p>Also:<p>&quot;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.&quot;
评论 #15482879 未加载
评论 #15482938 未加载
评论 #15482876 未加载
provost超过 7 年前
A very similar scenario is described in the fictional work, &quot;The Phoenix Project&quot;, 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.<p>Management had to figure out they needed to handle the escalations, prioritize, reduce the bottleneck, document the solutions, and teach others to fish.<p>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?
评论 #15486351 未加载
评论 #15482839 未加载
评论 #15483735 未加载
评论 #15483617 未加载
iwanttoreply超过 7 年前
I really liked both articles because they&#x27;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.<p>Personally I&#x27;ve been in Rick&#x27;s shoes where I&#x27;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 &quot;wasn&#x27;t enough time&quot; 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 &quot;upward&quot; 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.<p>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.
thestephen超过 7 年前
<i>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.</i> <i>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.</i><p>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.
评论 #15486188 未加载
评论 #15484598 未加载
评论 #15486761 未加载
watwut超过 7 年前
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&#x27;t get to be praised for skill at all. Only Rick is.<p>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.<p>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.<p>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.<p>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超过 7 年前
There are various alternative ways to interpret the story. Like, &quot;Yay, we finally outran <i>one</i> developer by using an entire team, and gutting the requirements.&quot; That&#x27;s like moving the finish line closer without telling the forerunner.<p>Hey, only 5% of the users need this; let&#x27;s remove it? What&#x27;s 5%.<p>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?<p>It&#x27;s not clear whether Rick himself invented all those additional requirements himself, or whether they were external.<p>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.
snarfy超过 7 年前
You don&#x27;t get what you deserve. You get what you get.<p>There is a misconception that if you do the extra work you will get compensated some way either through promotion or bonus. It&#x27;s simply not true. You are paid for the position you were hired for.<p>Rick should have left the moment he took on more work without matching compensation. Why wouldn&#x27;t the business pile more work on Rick? It&#x27;s free. As soon as it costs money, all of the issues brought up in the article would be addressed. Suddenly management cares.
评论 #15483564 未加载
pascalxus超过 7 年前
Documentation, while important is also a bit overrated in it&#x27;s capabilities. Don&#x27;t get me wrong - It would be lovely if you could simply read a bit of documentation to understand what&#x27;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.<p>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&#x27;s going on. By all means, attempt to document as much as you can, but don&#x27;t expect it to be a silver bullet for understanding code.
评论 #15485347 未加载
评论 #15485991 未加载
thisisit超过 7 年前
The whole situation reminded me of this sketch:<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=BKorP55Aqvg" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=BKorP55Aqvg</a><p>Given the kind of unreasonable demands, people do crack.
评论 #15483354 未加载
评论 #15482980 未加载
oandrei超过 7 年前
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: <a href="http:&#x2F;&#x2F;www.slate.com&#x2F;articles&#x2F;health_and_science&#x2F;science&#x2F;2017&#x2F;10&#x2F;the_nobel_prize_does_science_a_serious_disservice.html" rel="nofollow">http:&#x2F;&#x2F;www.slate.com&#x2F;articles&#x2F;health_and_science&#x2F;science&#x2F;201...</a> and here : <a href="https:&#x2F;&#x2F;www.theguardian.com&#x2F;commentisfree&#x2F;2017&#x2F;sep&#x2F;30&#x2F;we-hail-individual-geniuses-success-in-science-collaboration-nobel-prize" rel="nofollow">https:&#x2F;&#x2F;www.theguardian.com&#x2F;commentisfree&#x2F;2017&#x2F;sep&#x2F;30&#x2F;we-hai...</a> 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 !
brooksbp超过 7 年前
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&#x27;t have the heart to do it (for real).<p>If your approach always begins&#x2F;ends with &#x27;from my side&#x27; or even worse &#x27;from our side&#x27; (team&#x2F;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.<p>It takes one to know one. If you know that someone like Rick is just &#x27;so different&#x27;, or if you just have that &#x27;gut feeling&#x27;, 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.<p>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超过 7 年前
Apparently they didn&#x27;t fire their top talent. They fired the <i>worst</i> talent since the team brought it together after the tyrant was vacated and the quality of the work was questionable at best when reviewed.
jlg23超过 7 年前
&gt; 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!<p>There is always two parties involved, the player and the fiddle. The assumption that the developer was sucked empty and thrown away is the OPs alone, the article referred to does not provide details of attempts at intervention.
cannonedhamster超过 7 年前
I was a Rick once, though not by choice. The company underpaid, management received bonuses based on cutting staff, and the company wasn&#x27;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&#x27;ve never let myself become a Rick again.
golemotron超过 7 年前
Maybe the pathology is that there is no management or that it is anemic. Everyone loves the idea of self-organizing teams until something like this happens. How would Agile or Holocracy solve this?
chandmk超过 7 年前
Thank you for writing this. The culture of one software developer deriding on other software developer work by badmouthing his&#x2F;her work and bragging about how firing the developer solved the problem might have a place in politics but should not be celebrated&#x2F;encouraged in the technical world.
internetman55超过 7 年前
As someone new in this industry, I&#x27;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&#x27;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.<p>Is this normal?
perpetualcrayon超过 7 年前
IMO, the most amazing quote from the original story:<p><pre><code> It also had a few thousand lines of new code to replace about 150,000 lines of incomprehensible mess. </code></pre> No one looked at the quality of work after maybe 10,000 lines of code?
评论 #15483713 未加载
评论 #15483696 未加载
mikl超过 7 年前
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.<p>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.
cc81超过 7 年前
Could you please not spam &quot;funny pictures&quot; in a post like this. It makes it annoying to read.
评论 #15483682 未加载
评论 #15483815 未加载
评论 #15483999 未加载
pascalxus超过 7 年前
Rick needed leadership coaching and he never got it. So, he never learned to be a good leader. The problem wasn&#x27;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&#x27;t want to learn these things, in which case, he should have been demoted to regular developer or if he&#x27;s having a bad attitude about that, then fired.
评论 #15484769 未加载
notyourday超过 7 年前
Personally, I&#x27;m patiently waiting for the third installment: &quot;Our incredible story&quot;
stillsut超过 7 年前
I&#x27;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.<p>In this light, I&#x27;ve seen these back-room clerical apps, that need everyone&#x27;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&#x27;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.<p>From Rick&#x27;s perspective, I&#x27;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 &quot;real tech stacks&quot; 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&#x27;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&#x27;t highly marketable; limited upside with huge downside for him. But I find it commendable nonetheless he chose to Build when &quot;Lead&quot; would have been more rewarding; and ultimately if he makes the deadline, no crisis ever comes to head.<p>Finally, the &quot;Rest of the Team&quot; did what I think was the tough but right decision to move forward. No way can you &quot;reset&quot; the project while sustaining weekly second-guessing coming from an obsessive, knowledgeable, ego-bruised, senior team member. Ultimately, even self proclaimed logical dev&#x27;s are irrational actors and as susceptible to group dynamics as anyone. We&#x27;re all limited people: mgmt can&#x27;t predict the future, proven-shippers sometimes come up short. I don&#x27;t know if we need to read this as a call to blame.
kahlonel超过 7 年前
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&#x27;t even understand. As a consequence of your vague requirements, if a developer chose to implement something that you don&#x27;t quite agree with, grow a pair and suggest an alternative.
leroy_masochist超过 7 年前
The HN discussion thread for the article to which this is a response is here: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15474893" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15474893</a>
评论 #15483390 未加载
codesternews超过 7 年前
I disagree with some of below comments and it is totally Managment fault.<p>I might be somewhat a little rick. But in my case it is the managment responsibility to set the expectation.<p>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.<p>Let&#x27;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.<p>Then you will be fired like dumb.
评论 #15485142 未加载
conorcleary超过 7 年前
Medium is trying to be Cracked with this article style.
评论 #15483082 未加载
moon_of_moon超过 7 年前
&quot;Rick&quot; is generally actively supported by a non-technical manager who wants to keep the project from going to a more agile team (&quot;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&quot;) and it locks in nice inflating budget.
RcouF1uZ4gsC超过 7 年前
Based on founders&#x27;&#x2F;executives blog posts, can we have a list of toxic managers&#x2F;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.
评论 #15486259 未加载
equalunique超过 7 年前
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&#x27;s overworked so-called rockstars.
ne01超过 7 年前
They did not fire Rick, they freed him. Ricks should not be slaved!
disease超过 7 年前
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:<p>Those that ask the most, give the least.
Shivetya超过 7 年前
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&#x27;t see anyone held accountable so why should they exert the effort?
评论 #15483727 未加载
评论 #15483581 未加载
korzun超过 7 年前
I briefed the original story, and one thing that stood out to me is that the author threw a &#x27;bomb&#x27; named collaboration into the mix AFTER firing so-called Rick.<p>What author fails to understand, is that the problem could have been addressed by collaboration as well.<p>I caught a &#x27;scrum-master&#x27; 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.<p>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.<p>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?).<p>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.
评论 #15484687 未加载
评论 #15485244 未加载
whipoodle超过 7 年前
Music to my ears.