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

231–240 of 316 posts

Re: How to drive away your best engineers

#231

Post by DangitBobby »

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…

You're doing a lot of assuming that the engineer seeking greener pastures because they are, I don't know "selfish" or something, is easily detectible. I can confidently tell you that you're operating under self delusion.

Also assuming that someone who isn't going to tolerate fuck-fuck games with assholes when they don't have to is themselves an asshole. It's entirely possible to amicably end a relationship with someone (a business) you can't stand, with them none the wiser that it was ever about something other than compensation.

> Want to be free and clear to operate without too much bureaucracy? Play the cooperation game. This is as true with engineering as it is literally any other thing that requires more than one human.

This is pure hopium. Bureaucracy is installed in anticipation of growth/security/safety gains, and existing success of the team can be completely ignored by someone who thinks the good of bureaucracy will outweigh the harm.

Re: How to drive away your best engineers

#232

Post by astura »

marginalia_nu wrote: post #81
astura wrote: post #40

I suspect that the author has never actually worked in a flat organizations, it's been my experience that flat organizations have way, way more problems than "too many managers."

In practice, they still have all the same hierarchy, except it's not as obvious.

Yep, plus nobody ends up having any accountability to boot.

Re: How to drive away your best engineers

#233

Post by katzgrau »

onethought wrote: post #87
wildrhythms wrote: post #69

Earlier quoted context omitted.

Do you think someone is qualified to manage a process they don't understand?

The inverse question, is it even possible to have a manager who understands every nuance of the process they manage?

I find that, in practice, the more a manager knows about how things are done - the more they have the urge to micromanage and resist delegation, especially if they're perfectionists.

Doesn't sound completely horrible in theory but in reality it's bad for everyone.

Re: How to drive away your best engineers

#234

Post by p1esk »

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…

if engineers think we don't check references and backgrounds anymore – including reputation – those days are long past

How do you check reputation?

Re: How to drive away your best engineers

#235

Post by kevinventullo »

dghf wrote: post #229
ironmagma wrote: post #177

Earlier quoted context omitted.

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.

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.

Re: How to drive away your best engineers

#236

Post by JJMcJ »

astura wrote: post #232
marginalia_nu wrote: post #81

Earlier quoted context omitted.

In practice, they still have all the same hierarchy, except it's not as obvious.

Yep, plus nobody ends up having any accountability to boot.

Typically flat means anyone in Sales or Marketing can give orders to any developer and must be obeyed instantly.

Re: How to drive away your best engineers

#237

Post by BeetleB »

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 willing to read. Be it for learning or for understanding specs.

I'm not one of those people who gets upset at people coming to my cube to ask questions - I actually enjoy it (far more than them IM'ing me). But if it's something easy to find on the Internet, or clearly documented in a local wiki/manual, they should have at least tried to read it.

Similarly, I'll take the time to document very well how a tool I built works. Almost always someone will then come to me and ask "Hey, can you tell me what the tool does and show me how to use the tool?" Over 90% of the times it's not because my documentation is bad (which I admit it very well could be), but because they didn't even try to read it.

Re: How to drive away your best engineers

#238

Post by msrenee »

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…

I'd say the more personable engineer is the more qualified engineer even if their technical knowledge is less. Being able to deal with other people is a massive part of being good at the job.

Re: How to drive away your best engineers

#239

Post by edgyquant »

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.

Markets are more efficient and by rational it means they act in their perceived best interest to optimize their own utility.

You just don’t know economics, that doesn’t make it fantasy

Re: How to drive away your best engineers

#240

Post by no-s »

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…

> Hire people who can and are willing to read.

Also make sure they are able to read more than the first few words of the first sentence…(from bitter experience)

Post reply on HN