Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to drive away your best engineers

blog.hulacorn.com

Post reply on HN
Print view View original

301–310 of 316 posts

Re: How to drive away your best engineers

#301

Post by EnKopVand »

23B1 wrote: post #136
EnKopVand wrote: post #72

Earlier quoted context omitted.

I think the point here may be that when you’re dealing with an occupation in which the best engineers can pick and chose. Then you’re likely to lose your best engineers unless you’re exceptionally good at managing them. Especially if you introduce boundaries and restraints. I’m not sure it’s naive to view the world like the author does. I’ve worked both sides of the fence, and while I’m now back in software developme…

> the best engineers can pick and chose Sorta. I would take a less-qualified but more personable engineer over their more capable peer any day of the week, for the aforementioned reasons: engineering isn't the only skill required – those who don't insist on managerial perfection don't actually need a lot of managing as a result. It's a positive feedback loop. Also if engineers think we don't check references and back…

What makes you think that the personable engineers aren’t also the ones leaving?

One of the reasons I have a lot of job offers isn’t that I’m the best technical engineer you’re going to meet, it’s that I have a large network and is generally seen as a nice person to work with. Obviously my ability also plays into this, but you can be both good at your job and a decent person at the same time. In my experience most people are.

> Play the cooperation game.

Like I said in my original post, I do this, and in my personal opinion experience so so most people. The thing is though, I have a lot of experience (and education) with/in the “MBA” side of things, and a lot of the things you see some companies do, that this article also touches on, like putting up a needless bureaucracy around estimates and time tracking, don’t actually work as intended. Time tracking tends to lead to cultures where the speed of delivery becomes more important than the quality, and estimating things by the hour is frankly just impossible in a field where you can spend an hour on something incredibly stupid and then 10 minutes on some brilliant solution to an issue marked as complex. I mean, maybe my anecdotal experience is from a mediocre perspective, but even after decades of programming I still do the equivalent of talking to a rubber duck, or at least asking my very good friend and coworker to come and spend 5 seconds spotting where I’ve made the obvious mistake (and the other way around), which we have time to do because we’re not on the clock to deliver as fast as possible by the way.

In a world of a lot of shitty business practices, people who can, will take their cooperation game to the place it makes the most sense for them. Including when they are also very personable people.

Re: How to drive away your best engineers

#302

Post by foldr »

Closi wrote: post #260
foldr wrote: post #29

Earlier quoted context omitted.

>The idea that it’s possible to have a project with no budget or time constraints just isn’t often the reality of the situation. It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Time is almost always more flexible than the people imposing the deadlines thi…

> It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Making decisions on the basis of an estimate which could be plus or minus 50% is fine. It’s better than making a decision on the basis of nothing at all, and then managing the project with no clue about ho…

But most estimates are completely wrong (much worse than +/-50%). Only accurate estimates can possibly be useful for planning, and very few estimates of time and cost for software projects are accurate.

Re: How to drive away your best engineers

#303

Post by walls »

ClumsyPilot wrote: post #116
woevdbz wrote: post #109

The underlying principle I've been using to understand this is, no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well. The opportunity cost of talented software engineers is much too high in general. This applies regardless of actual talent and does not guarantee results. I've seen mediocre SWEs with inflated egos jump ar…

> no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well So is everyone developing advertising at google is a second rate engineer?

Just look at the state of almost every google project.

Re: How to drive away your best engineers

#304

Post by Closi »

foldr wrote: post #302
Closi wrote: post #260

Earlier quoted context omitted.

> It must be possible because most budget and time estimates end up being way off anyway. Virtually no real projects are managed on the basis of accurate estimates of how long they'll take or how much they'll cost. Making decisions on the basis of an estimate which could be plus or minus 50% is fine. It’s better than making a decision on the basis of nothing at all, and then managing the project with no clue about ho…

But most estimates are completely wrong (much worse than +/-50%). Only accurate estimates can possibly be useful for planning, and very few estimates of time and cost for software projects are accurate.

> Only accurate estimates can possibly be useful for planning

Nah, a best guess estimate is better than no estimate at all. If engineers don’t estimate it doesn't mean estimates go away, it just means they have moved responsibility of estimating away from the engineers to the management team (who will then need to make their own estimate of how difficult/expensive something is to do and how long it will take).

Besides, you can be accurate without being precise - and engineers can work to become more precice over time as they gain more experience.

Re: How to drive away your best engineers

#305

Post by ratww »

BeetleB wrote: post #294
ratww wrote: post #292

Earlier quoted context omitted.

Reading is a huge problem with certain developers. It's not only documentation, which they ask for but never read. They also won't read error messages, and ask seniors for help on almost every situation. (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)

> (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it) Oh yeah - this drives me nuts, although I've seen it more from laypeople than developers. Some people are hard wired to just hit Enter for any informational window that pops up on the screen. I've talked to people who…

I kinda understand when laypeople do it, can't really blame them.

I guess developers who do it got the habit from their layperson days.

Re: How to drive away your best engineers

#306

Post by drdec »

BaseballPhysics wrote: post #296
drdec wrote: post #152

Earlier quoted context omitted.

I think the difference is that a forecast is developed by a team (or formula/ML) separate from the engineers doing the work.

Once again: no team or model or formula can produce a forecast without an assessment of complexity for the work effort being forecast. So if what you're saying is true, this would involve someone other than the devs assessing complexity, then coming up with a date, and then holding the devs accountable. And that sounds like a complete nightmare that's far worse.

> without an assessment of complexity

The point of ML is that that can happen without human intervention.

And yes, I agree that if devs are held accountable to such timelines that would be terrible.

But if they are used for business planning with the understanding that they will not be accurate in the specific, but hopefully in the aggregate, then that's fine. (This is how engineer's estimates should be used as well for that matter.)

Re: How to drive away your best engineers

#307

Post by sanderjd »

BeetleB wrote: post #295
sanderjd wrote: post #287

Earlier quoted context omitted.

> Put another way: If you were my boss, would you want me to spend my time teaching the same basic Git usage to every junior hire? I guess I think it depends. I think some companies absolutely do need to take this on, hiring very green brand new hires and investing a large chunk of their more senior engineers' time into showing them the ropes. How else would it get done? I don't mean only for this specific example of…

> I don't mean only for this specific example of git usage, but every entry level employee - whether from a college program or a bootcamp or self taught or whatever else - is gonna have a lot of gaps, That's understandable - the issue under contention is how to address the gap. I absolutely do not expect people to know Git when they start. If you look at my comment history, including in the last few days, you'll see…

> Why is it not enough to have a Wiki page listing all the tools they're expected to know/learn, with guides to resources to learn from?

It's not enough for the same reason that we have classes and teachers in schools rather than just lists of textbooks.

But I agree with you that some things are more and others less valuable to teach interactively rather than through "book" study.

Re: How to drive away your best engineers

#308

Post by BaseballPhysics »

drdec wrote: post #306
BaseballPhysics wrote: post #296

Earlier quoted context omitted.

Once again: no team or model or formula can produce a forecast without an assessment of complexity for the work effort being forecast. So if what you're saying is true, this would involve someone other than the devs assessing complexity, then coming up with a date, and then holding the devs accountable. And that sounds like a complete nightmare that's far worse.

> without an assessment of complexity The point of ML is that that can happen without human intervention. And yes, I agree that if devs are held accountable to such timelines that would be terrible. But if they are used for business planning with the understanding that they will not be accurate in the specific, but hopefully in the aggregate, then that's fine. (This is how engineer's estimates should be used as well…

> The point of ML is that that can happen without human intervention.

What kind of wizardry is this? What are the inputs to this ML? The vague requirements supplied by the customer and filtered through a sales rep?

Please. ML isn't magic. Hell, what would this magical model even be trained on??

Re: How to drive away your best engineers

#309

Post by uwuemu »

steveBK123 wrote: post #227
LaurensBER wrote: post #6

Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. - Not involving your current team in decis…

Yes, I was in an "agile" org that over-hired senior engineers and then expected them to just do regular "spade" work tickets.. but more quickly / more per sprint. No ownership of long running projects/tasks, no design/planning, just a constant stream of whatever ticket is at the top of the queue - GO. Over the last 12 months, 55% of seniors have left. Most that remain have been at the firm 0-1 year.. The median senio…

I just want to know how do you keep a job as a manager when you fuck up so badly. The vast majority of what seniors bring to the table is experience. That is also what you pay for. That experience is not like gold, it's like a gold mine - you have to mine it first, then bring it to the surface and only then you can profit off it. The fact that there are software houses out there that do not understand this is amazing (in a bad way). I mean I guess there is some value in a senior dev coding menial tasks (generally more mature, less error prone code with the right amount of abstractions), but that like saying there is some value in a rocket engine pulling a plough... technically true, but not really economical and there's a pretty good chance of most of your rocket engines going away rather quickly.

Re: How to drive away your best engineers

#310

Post by anarazel »

marcosdumay wrote: post #269
anarazel wrote: post #118

Earlier quoted context omitted.

It's not uncommon IME that doing the work to come up with a reasonable estimate is 80% of the final work. E.g., addressing a scalability issue might require a bunch of profiling work, then a bunch of experimentation / thinking about developing a lock free algorithm. Or it might turn out that reducing false sharing a bit will give large enough benefit on its own. Without having done most of that I won't know whether i…

> It's not uncommon IME that doing the work to come up with a reasonable estimate is 80% of the final work. That estimate you do after finishing 80% of the work is probably orders of magnitude smaller than the real thing. More realistically, if you don't have the experience for an estimate beforehand, you also don't have the experience to know when you covered enough of the high-risk subproblems, so you have no basis…

There's tasks where experience doesn't tell you ahead of time how long something takes. If you need to figure out a [novel take on an] algorithm, it'll be hard to predict the time even if you did things like that plenty times before. And you'll be able to judge the remaining work after pretty decently.
Post reply on HN