Live data from Hacker News

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

medium.com

151–160 of 175 posts

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

#151
post #127
post #22

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 sh…

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

But it wasn't the same project. It was a lot smaller.

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

#152
post #85

Earlier quoted context omitted.

And in this field that especially includes "managing your manager". Managers get paid to have people skills. Programmers get paid to code. If you really are some genius, you may be able to write good code and also be more talented than your manager at people stuff such that you can manage your own boss with some seriously tricksy Machiavellian maneuvering. But, saying that is necessary is suggesting that all managers…

I'm really surprised how much pushback my comment about "managing your manager" has gotten here. I'll respond to your post in particular. If you really are some genius, you may be able to write good code and also be more talented than your manager at people stuff such that you can manage your own boss with some seriously tricksy Machiavellian maneuvering. Well, no, you aren't required to have better soft skills, or b…

From the company's perspective, though, at the end of the day the buck stops with the manager.

Yes it's important to manage up, but that's for your own benefit more than anyone else's. From the company's perspective, they pay the manager to handle you, not the other way around.

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

#153

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 typ…

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

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.

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

#154
post #127
post #22

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 sh…

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

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.

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

#155

Earlier quoted context omitted.

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

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.

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.

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

#156

Earlier quoted context omitted.

A lot of us are contractors for the company with 40 hour work weeks. People at my company are salaried. I don't know about the other companies. I don't stray much from my 40 hours. If others want to put in that time, so be it. I always tell them to knock it off, but some people just can't be helped. I don't put it all on management. It's a little of column A and a little of column B. It's tough standing up to managem…

I wonder what would happen if a company had overtime pay for developers. I'd be willing to put money on working hours getting reduced to something sane and deadlines pushed back to accommodate it. Maybe one day I'll suggest a trial for it at my company ;)

I worked for a company where we were all regular W2 exempt employees, but paid hourly. We got paid for every hour worked.

Curiously, we all worked a lot, made a ton of money for years and years, and bled the company dry. They eventually brought in some accountants that told them they had to put the brakes on this, and we were converted to salary. The company still ended up shutting down a couple years later, but it was a wild and lucrative ride.

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

#157

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?

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

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?

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

#158
post #5

The whole situation reminded me of this sketch: https://www.youtube.com/watch?v=BKorP55Aqvg Given the kind of unreasonable demands, people do crack.

And here's the solution: https://www.youtube.com/watch?v=B7MIJP90biM

He's missing a few dimensions.

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

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

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

#160
post #127

Earlier quoted context omitted.

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

But it wasn't the same project. It was a lot smaller.

It was the same project. Requirement and expectations management was done better. Communication about current status was done better. The descend to troubles described in original article is not just "too much work". It is bad decision making.

And I stand behind this 100%. Non technical management cant really do the above and where they can, it is only when technical staff feeds them accurate information about difficulty and scope. Someone making up requirements in his head and then coding something much more complicated is not a mark of genius. It is mark of someone who don't listen.

Post reply on HN