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

271–280 of 316 posts

Re: How to drive away your best engineers

#271

Post by grayclhn »

kimixa wrote: post #226
grayclhn wrote: post #223

Earlier quoted context omitted.

>> Stop estimating. > How does this person think an organization schedule, budget and allocate resources? Collect data and use a trivial prediction model (i.e. median calendar time it took to complete the last 5 stories). Monitor and improve the prediction model over time if necessary. If you’re not collecting data reliably enough to generate a prediction automatically, you’re not taking any of these issues seriously…

That's just a way of estimating that is likely quite accurate in a completely steady state. But what if you know you're changing things significantly, and that's the whole point you need to think about resources and schedules? Like starting a new project?

Use data on how long it takes to complete “projects.” Or break the project down into your best projection of the component tasks and multiply “number of equivalently sized tasks” by “average time to complete that sort of task over the past X months.”

Regardless, “collect and use data from the past,” does not require a “completely steady state,” and is pretty easy to modify. I’d feel a lot better having a conversation around, “this is totally new, do we think it will take about 2x or 5x longer than our normal projects?” Vs “this is totally new, so everyone guess how many months it will take without looking at any relevant data on either past project duration OR the accuracy of your past guesses.”

When people talk about “estimating task size” they almost invariably mean some planning-poker version of the second. Especially in TFA where they bring up forecasting as a better alternative.

Re: How to drive away your best engineers

#272

Post by lifeisstillgood »

edgyquant wrote: post #241
lifeisstillgood wrote: post #175

Earlier quoted context omitted.

I argue it's democracy. (That can save Nations and presumably companies) Imagine voting for the CEO. Imagine voting to allocate budgets. Yes there will be a lot of pork barrel- but it might just work. I mean the idea that companies are like single cells / autonoma so they don't have to be democratic leads us to silly ideas like trying to put in place rules for not abusing the electorate. I mean if a boss is sexually…

Maybe but that can also stifle innovation. If Netflix had been a democracy they likely wouldn’t have voted to switch to the unproven online streaming business, etc.

Really?

I mean that was what 2000? 2002? Peak dotcom time.

I don't agree with the decisions all these humans sometimes make (cough Brexit cough), but that's not the point - as long as we don't vote away democracy, as long as we trust the other side has everyone's best interests at heart, then we can manage

Re: How to drive away your best engineers

#273

Post by bradlys »

davesque wrote: post #247
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…

This would only be true if finding another job was a simple (and reliable) process for most people. I imagine you might come back and say, "But finding another job should be easy for a talented engineer!" To which I would say, nope! Not true! The tech interview grind is often inconsistent and demoralizing. Even talented people might make a reasonable calculation to avoid the trouble and just stick with their current…

Correct. People also assume that you’re always going to get paid more at a new gig. This just isn’t true in SV. If you joined a startup and it rocketships - I’ve seen many smart engineers stick around for years just because they have a 7-fig TC. Why would they move elsewhere? Just isn’t financially responsible and most are willing to suffer through it as far as I’ve seen.

Re: How to drive away your best engineers

#274

Post by dadoge »

What is wrong with making engineers make estimates for their work?

I’d much rather me give an estimate than some EM or PM since I’m building the damn thing.

And totally confused by the author’s suggestion to “forecast”, which is what if not an estimate?

Re: How to drive away your best engineers

#275

Post by IlPeach »

Nice, thanks for sharing.

A few points stroke a chord. Specifically...

The definition of engineering manager who doesn't know how to do stuff and it's solution is very wishy-washy. Based on experience, this works in some contexts but not all. I think the author's hearth is in the right place, but the way it's explained is very short sighted. In other words this makes me think the author has never worked with an eng manager.

Layering: good problem to solve, solution? In theory, but in reality this is also very difficult to balance (e.g. from experience, especially when moving above 150-200 ppl working in the same area).

Too many meetings: very good problem. Solution? Partially meaningful. If you want to generalise, my take would be to make things async as much as possible. Collaboration between teams might be needed, and perhaps healthy. When you don't have collaboration you end up not knowing what's going on (i.e. isolating teams) and risking pulling meetings over and over.

Software definition; mostly agree, but again, the solution is much more complex than what the author leads to believe. Also assumes you have testers and product will be happy to sit through each ticket revision. This problem is solved by anticipating these requirements way way earlier than that.

Software delivery: are we talking about technical debt or what? If that's the case, the solutions (20%) make no sense. That's where you start diving into each single problem, breaking them down by priority, involving product and making sure things are tackled at the right time.

The rest seems to be good.

Re: How to drive away your best engineers

#276

Post by nonrandomstring »

grayclhn wrote: post #224
lifeisstillgood wrote: post #175

Earlier quoted context omitted.

I argue it's democracy. (That can save Nations and presumably companies) Imagine voting for the CEO. Imagine voting to allocate budgets. Yes there will be a lot of pork barrel- but it might just work. I mean the idea that companies are like single cells / autonoma so they don't have to be democratic leads us to silly ideas like trying to put in place rules for not abusing the electorate. I mean if a boss is sexually…

You vote by changing jobs. I think “real governments” make it clear that this isn’t sufficient to thwart harassment though.

> You vote by changing jobs.

Like you vote by moving country.

Re: How to drive away your best engineers

#277

Post by bluefirebrand »

kevinventullo wrote: post #235
dghf wrote: post #229

Earlier quoted context omitted.

But 90+% of the time, it'll be a basic use of add, checkout, commit, merge, pull or push, especially if you're a junior.

Don’t forget the most important operation: rm -rf the whole directory and re-clone the main repo.

Yep and if that doesn't work?

Sudo rm -rf

Re: How to drive away your best engineers

#278

Post by dbwjxufh7373 »

ironmagma wrote: post #177
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…

As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.

I don't think they were. Software devs hitting the job without understanding git means your hiring team is sleeping on the job.

Re: How to drive away your best engineers

#279

Post by BeetleB »

m3047 wrote: post #263
BeetleB wrote: post #237

Earlier quoted context omitted.

> have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed. Why should I have to teach a junior how to use an essential tool of the job, when I can just point them to good books/guides on the Internet? My list would definitely include: Hire people who can and are w…

> I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed. Git is nontrivial and has many ways to do things, and it is only one of many ways to do most of these things. If commit messages and merge squashing take the discernment and nose of a winemaker, you can't tell them to crush some grapes and leave it at that.

How about just making branches and merging? Why do I need to explain that to an employee? If they can't do with git very basic things it's because they're not willing to read.

Re: How to drive away your best engineers

#280

Post by sanderjd »

BeetleB wrote: post #237
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…

> have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed. Why should I have to teach a junior how to use an essential tool of the job, when I can just point them to good books/guides on the Internet? My list would definitely include: Hire people who can and are w…

> Why should I have to teach a junior how to use an essential tool of the job

Why shouldn't you? Unless you're a junior developer yourself, mentoring and developing the skills of the rest of your team is an even more important part of your job than whatever programming you're doing.

Post reply on HN