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

201–210 of 316 posts

Re: How to drive away your best engineers

#201

Post by ebiester »

biztos wrote: post #176
ebiester wrote: post #92

Earlier quoted context omitted.

Forecasting looks like this: https://medium.com/expedia-group-tech/monte-carlo-forecastin... It’s running through simulations based on previous team behavior to give a range.

Don’t you still have to correctly estimate the amount of work (time) to complete each task in your backlog? You can apply all the “science” you want, but at the bottom of it all you have engineers holding up a card with a “4” on it when the scrum dude says “add date picker to the Foo widget.”

When I did this last, we incorporated size of epic instead and looked at number of tickets on average. You still have to break it down but you can take into account the number of added tickets given a large enough sample size.

Re: How to drive away your best engineers

#202

Post by torginus »

devoutsalsa wrote: post #156
marginalia_nu wrote: post #19

Earlier quoted context omitted.

If we move to a microservices architecture, we can use 100 developers to solve same the same problem in with ten times the hardware! With growth like that, we'll be unstoppable!

How else will we justify the military grade, globally distributed, multi-planetary federated, immediately consistent Kafka cluster that the CIO just purchased? I’m still not sure how to get all the servers to synchronize when Mars is on the opposite side of the sun.

That has more downtime during upgrades than my college dorm Counter-Strike server built from leftover PC components ever had.

Re: How to drive away your best engineers

#203

Post by mancerayder »

threatripper wrote: post #35
bratbag wrote: post #24

Earlier quoted context omitted.

I don't agree. Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced. Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.

We don't want to manage engineers we want to manage projects and projects have budgets and deadlines. If you can't deliver then maybe you're not a good enough for the job. If you can't even promise then why are you still working at our company? One of the best ways to drive away engineers is to make them commit and then watch them fall into misery when they desperately try to somehow make the deadline. Many weak char…

> Many weak characters break that way. The trick is to make them choose their own deadline and fail.

I think I missed the title, main topic or perhaps even what you were replying to when you wrote this. Maybe there is a context. In its absence, this reads like a HowTo for getting someone you already don't like, to quit.

Clear communication is a very important managerial skill, by the way.

Re: How to drive away your best engineers

#204

Post by ratww »

bosie wrote: post #187
whydid wrote: post #183

Earlier quoted context omitted.

Yes, git can be complex. It's also a requirement for modern software development. It is well documented, and not esoteric. If someone hasn't taken the time to learn the tools their team uses, they will be a burden to the rest of the team. They don't need to become an expert, just experienced enough so they don't cause problems for others on the team.

> If someone hasn't taken the time to learn the tools their team uses, How does your company handle this? How do you give the people the time/resources to learn those tools?

My company handles this by allowing them to study on the dime. I just ask how much time they want and ask them to do it, and if they need some material or help devising a study plan.

Curiously the two that needed it didn't really want to study at all, and we eventually let them go (they were interns).

Re: How to drive away your best engineers

#205

Post by ratww »

ramphastidae wrote: post #157
raisin_churn wrote: post #128

Earlier quoted context omitted.

If MBAs weren't economically efficient, the market wouldn't make so many of them and companies wouldn't pay them so much.

This is pure fantasy. Markets have never been efficient and actors have never been rational.

I think that was sarcasm. Or at least I hope so.

Re: How to drive away your best engineers

#206

Post by brongondwana »

katzgrau wrote: post #44

"What makes engineers sad? Their boss(engineering managers, Directors, VP’s) do not know what they face on a day to day basis and does not know how to build something, whether it is a feature or architecting something from scratch." If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and…

By far the hardest part of that transition (at least for me!) is going from being able to create measurable impact on the order of days to most things taking months or years to create real change.

As a coder, I could get a bug report, build a fix, test it, get it deployed within an hour if it was urgent and simple.

Now I do a lot of listening, a little bit of talking, a bunch of thinking and discussing with the rest of the executive team, and mostly make small corrections which might show meaningful results in 6 months' time. Every so often there's still something really amazing and valuable, but it's much rarer and less predictable when that's going to be.

And yeah tons of new learning to do. Being a good programmer doesn't automatically translate to being good at running a company (though understanding tech and having been there certainly helps both for understanding what your staff are going through, and having their respect)

Re: How to drive away your best engineers

#207

Post by ratww »

hibernator149 wrote: post #46
hericium wrote: post #12

Agree with most points but one which is making a manager do coding/shipping. Most of IT managers I met possessed no real IT skills. They wrapped their heads around only as much theory as needed to _manage_. Most of them did not came from engineering world but from business one. Ideally, manager should be able to do the work their team is doing, but reality is quite different. I stopped expecting managers to understan…

- Manager: How long would it take to migrate from A to let's say B? - Me: How would I know that? - Manager: Just make an educated guess. - Me: Maybe X months? I really don't know. - Manager writes down X. - Me makes a mental note to not trust Manager again... Maybe it's better to have any plan than to have no plan, but having a plan based on known bad data can't be the solution. Dear Managers, if your plan requires d…

That's actually perfectly fine, as long as they don't treat the estimate as a deadline.

Re: How to drive away your best engineers

#208

Post by bdw5204 »

indy wrote: post #8

Too much time is spent generating metrics for non-technical managers to evaluate the productivity of engineers.

The best way to evaluate the productivity of engineers would be to determine if their peers see them as a top performer, a net positive or a net negative. If somebody is a net negative, get rid of them. If somebody is a top performer, make sure they're compensated accordingly and kept happy so they don't leave. If somebody is a net positive then you should be satisfied that you aren't stuck with a net negative. Any attempt to evaluate software engineers beyond this is going to be inherently arbitrary.

If you invent arbitrary metrics, your engineers will often have to choose between doing work or gaming the metrics.

Re: How to drive away your best engineers

#209

Post by proxyon »

astura wrote: post #50
23B1 wrote: post #34

Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company's hiring and resource management, and a perfect understanding of the software's requirements. These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but a…

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.

Re: How to drive away your best engineers

#210

Post by jb3689 »

allgreed wrote: post #182
ClumsyPilot wrote: post #116

Earlier quoted context omitted.

> 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?

I think believes is the key here. There are definitely people who believe that if they can work on complex graph colouring problem in a real-time processing scenario and the interruptions are minimal - then indeed their talent is utilised well. And I can imagine such a scenario happening at Google in advertising department/division/tribe .

There are plenty of critical, unglamorous jobs which need to be done. It’s not unreasonable for an engineer to value high six figure/seven figure salaries over a feeling of work fulfillment and skill utilization
Post reply on HN