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

311–316 of 316 posts

Re: How to drive away your best engineers

#311

Post by steveBK123 »

uwuemu wrote: post #309
steveBK123 wrote: post #227

Earlier quoted context omitted.

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…

Larger cultural issues:

Bad engineering - product relationship

Inability to set priorities

Zero roadmaps

No annual/quarterly objectives

The only thing that mattered was the thing someone was screaming about right that minute

Manager walked rather than deal with it anymore as well..

Re: How to drive away your best engineers

#312

Post by m3047 »

BeetleB wrote: post #284
sanderjd wrote: post #280

Earlier quoted context omitted.

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

> Why shouldn't you? Because I expect people to have basic reading and Internet searching skills. As I mentioned elsewhere, I don't have a problem mentoring them on what skills they should learn. I also don't have a problem directing them to resources where they can learn - even telling them what to focus on and what not to focus on. But I expect that once I point them to a resource, they'll go and read it. For thing…

> Put another way: If you were my boss

If you have a good relationship with your boss, talk to them. Don't whine. Have a solution or a fact finding plan.

Why are they coming to you? How is that expectation being set and reinforced? I don't know how many people this is, or how big the entire org is, maybe you need an org-wide bootcamp. If they don't have basic reading and internet searching skills, how did they get the job? I smell something for management to handle here.

Re: How to drive away your best engineers

#313

Post by foldr »

Closi wrote: post #304
foldr wrote: post #302

Earlier quoted context omitted.

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). Beside…

>Nah, a best guess estimate is better than no estimate at all.

Only if it's more-or-less accurate on average. It can't possibly be the case that a highly inaccurate estimate is better than no estimate. If you don't know, you don't know, and you should plan on that basis, not on the basis of a made up estimate.

Re: How to drive away your best engineers

#314

Post by Trailing2Dots »

Some actual anti patterns I've experienced:

* When a project is declared "finished" break the team apart and spread them about the company. Because the original dev never see the code again, why should they care.

* When a project is late, and it always is, pull out the original schedule rammed down our throats when the project was first started. Then it's easy to see who to blame.

* Have legal (YES!) decide rules for agile. True: they decided on 1 week deliverables, demanded complete documentation per week, insisted on a waterfall approach to design and dev. "When you've done it, you don't have to revisit the past!"

* Documentation was in charge of dev: "They read the docs and know what needs to be done:. I never figured out who "they" were.

* Create a lengthy, complex paper trail for deliverables.

True story of one company - now extinct. They had about a 50% turnover rate.

Post reply on HN