How to drive away your best engineers • Hacker News Board

Re: How to drive away your best engineers

#211

Post by proxyon » Sun, Jul 24, 2022, 3:44 PM UTC

woevdbz wrote: post #103

astura wrote: post #50

Earlier quoted context omitted.

This article could be a parody with how shockingly naive it is. The purpose of work is to solve business problems, not personal amusement and self-actualization. Business problems exist in the real world and have significant constraints. Many people will be much happier if they understood this.

?? Where is there any reference to amusement or self-actualization in TFA?

If you read between the lines what he's saying is that it doesn't matter if engineers enjoy the job.

Re: How to drive away your best engineers

#212

Post by kqr » Sun, Jul 24, 2022, 3:46 PM UTC

greymalik wrote: post #144

kqr wrote: post #108

Earlier quoted context omitted.

A good reference is Douglas Hubbard's How to Measure Anything . The idea is that most people can calibrate their sense of probability to be fairly accurate, by intentionally adjusting for some common biases. (In particular, if you prevent anchoring and availability bias, and actively engage system 2 and your loss aversion, you get a long way. There are specific techniques to do that in the book.) This is really easy…

I’m a developer who’s been doing this for a loooong time and I can’t imagine being able to accurately guess with 90% confidence the calendar day I’ll have a particular task done. And the tasks I work on are different enough that a feedback loop about how much I misguessed would be useless for error-correcting future estimates. Maybe that works for factory-like tasks like how long it tasks to add a REST endpoint for a…

No, it works for anything. The key that people misunderstand is that if the task is really uncertain, you're allowed to give a really wide range. In fact, you're supposed to -- that's the only way you can be correct 90 % of the time.

As a concrete example, I recently estimated "somewhere between 1 week and 4 months" when asked about an semi-well specified feature because I felt there's a 5 % chance it's done in less than a week, but even under pessimistic assumptions, there's about a 5 % risk it takes longer than 4 months.

When asked about a larger, unspecified projects a few years ago, I didn't hesitate to respond "between three months and 15 years". Sometimes that's the best you can do due to the uncertainties involved. It sounds useless, but it's really useful to have a quantitative measure of the uncertainty.

Re: How to drive away your best engineers

#213

Post by proxyon » Sun, Jul 24, 2022, 3:56 PM UTC

hownottowrite wrote: post #190

I don’t see “failing to fire bad engineers” on this list, which is a huge problem but easily fixable. A good engineer can put up with a lot of BS, but working with B and C level talent is a fast path to burnout.

I work for a company that doesn't fire no matter what. You can join and do nothing for 40 hours a week while never delivering on a single ticket in the issue tracker. True story there is someone here who has never had a single PR in nearly two years. He isn't a manager he's a dev. The other engineers can see this and it is immensely demoralizing and betrays such a serious dysfunction that no one takes this company seriously. To spice this up a bit this is a high end tech company which everyone reading this has probably heard of. The employee in question is not the only employee who does nothing. I would estimate roughly 10% of the company does absolutely nothing all day and another 20% work 20 hours or less a week.

Re: How to drive away your best engineers

#214

Post by Yahivin » Sun, Jul 24, 2022, 3:59 PM UTC

ThePadawan wrote: post #174

elric wrote: post #119

Earlier quoted context omitted.

Is there a story behind all this bitterness? MFA for every login is a very good idea. If you're having to log in to the same service over and over again within a short amount of time, someone is doing something very wrong. Sending out company newsletters seems like a nice way to let everyone know what the company is up to. Not sure how you go from that to reminding lowly engineers of their "insignificance". Social ev…

> Sending out company newsletters seems like a nice way to let everyone know what the company is up to. Not sure how you go from that to reminding lowly engineers of their "insignificance". I agree with both you and parent. I've enjoyed getting a monthly newsletter by email in past jobs, letting me know "hey so we just signed a contract with a client that is twice as big as the biggest one we've had so far". Makes se…

I hope the filter rule auto-replied "Congrats!" and archived the thread :)

Re: How to drive away your best engineers

#215

Post by Jugurtha » Sun, Jul 24, 2022, 4:02 PM UTC

From: https://www.merriam-webster.com/dictionary/scuttle

>scuttle verb(1)

1: to cut a hole through the bottom, deck, or side of (a ship) specifically : to sink or attempt to sink by making holes through the bottom

The actions of these people make you to give up on Occam's razor in disbelief. Sometimes they're the owner of the company who are doing everything someone who'd want to sink a ship would do.

The worst is when the ship was amazing (generating revenue like crazy, great reputation, top notch record, satisfied clients).

Also, promise people equity then change the goal post by introducing new variables, haggling over everything, and attempting to screw them in every sentence (for instance, change the vesting period in one sentence, add a condition in the next sentence, claim they've had no impact on the company in the next, threaten to fire everyone in the next, add yet another condition in the next, tell people you can't give them the equity you promised because you promised someone else and do that for the other person too).

That's, in essence, how to fuck up your own company lightning fast.

Re: How to drive away your best engineers

#216

Post by iancmceachern » Sun, Jul 24, 2022, 4:03 PM UTC

dalbasal wrote: post #62

Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compar…

I would argue it applies to most engineering disciplines, not just software.

Re: How to drive away your best engineers

#217

Post by kqr » Sun, Jul 24, 2022, 4:06 PM UTC

nonrandomstring wrote: post #125

FrankyHollywood wrote: post #78

Earlier quoted context omitted.

The book would be an anthropological study. Having worked as a freelancer for more than 15 years, seen many companies from startups to large finance I see these patterns over and over again, it's like human nature. Totally unrelated companies have these exact same flaws. Clueless middle management driven by money and ego making these destructive decisions. At the same time, a group of engineers at a startup without m…

Yes, I think it would. Anthropology. Way too late in life I discovered what anthropologists actually do after stumbling upon Alan McFarlane's lectures about "The origins of Modernity" [1]. Nobody ever made history seem so interesting and clear why What's Past Is Prologue. A big shout-out to all anthropologists! https://fortnightlyreview.co.uk/2013/07/anthropology-empire-...

Gerald Weinberg has a bit of an anthropological take (due to his wife being an anthropologist, IIRC) in his Quality Software Management series.

Re: How to drive away your best engineers

#218

Post by summertime42 » Sun, Jul 24, 2022, 4:06 PM UTC

pikaynu wrote: post #4

I totally agree with this. I am in a situation right now where the skip level manager is asking to schedule meetings every other day to talk on a problem that requires research. They want to talk about a solution and not letting us find one. Another one is defining aggressive timelines when I don't even know what to solve. Obviously the timelines were shot to hell in the worst way possible.

In the nicest way possible, get those meetings canceled. Show initiative by simply saying "I will provide an update by the end of the week; let me do my research first."

If the skip-level is refusing to stay out of your lane and not let you do your job, it might be time to dust off the resume. Thankfully, the market is crazy hot for anyone not a junior. Still, that sounds bloody awful; I am sorry you are going through that. :/

And in the best way I can say this, but deadlines don't matter if they are not set by your engineers AND accounting for the time to add unit tests/integration tests/bug fixing/clean code. I've inherited plenty of salvage projects with terrible codebases that eventually get scrapped wholesale and redone from scratch - so if someone tells me to cut corners for bullshit deadlines, I'll push back with those stories and keep the course. Call me cushy/inflexible/unrealistic, but I refuse to write a salvage project of my own.

Re: How to drive away your best engineers

#219

Post by summertime42 » Sun, Jul 24, 2022, 4:08 PM UTC

cebert wrote: post #163

Hiring cheap contractors can be frustrating too. I am on a project that is behind schedule. Management’s solution is to temporarily staff the project with several temporary, cheap offshore developers. I think a smaller team with competent folks can be much more product. There’s a lot of truth to the book, “The Mythical Man Month”. Now, we have far more meetings and communication chains. We also have to spend multiple…

If it's as bad as you say it is, collect evidence and prove Mythical Man-Month to them. Explain it's wasting more time AND money, and the deadline is missed regardless. Hopefully they'll listen.

Re: How to drive away your best engineers

#220

Post by astura » Sun, Jul 24, 2022, 4:10 PM UTC

proxyon wrote: post #209

astura wrote: post #50

Earlier quoted context omitted.

This article could be a parody with how shockingly naive it is. The purpose of work is to solve business problems, not personal amusement and self-actualization. Business problems exist in the real world and have significant constraints. Many people will be much happier if they understood this.

Are you a people manager? If so, what is the turnover like on your team? I ask because the author is dead on and I've been in this industry for 10 years.

If you wanna make this a competition I've been in the industry for 16 years.

I'm a technical lead which does have a little bit of people management responsibilities. Turnover on my team is probably well below average, we had two developers leave for other jobs in the last year out of 15 developers and one fired for poor performance. I can't remember anyone leaving the year before.

To be clear, I don't think this article is wrong per se, just obnoxiously naive and doesn't have any empathy for the real world constraints that people have to work with. It's just... uhhh... rubs me the wrong way.