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

281–290 of 316 posts

Re: How to drive away your best engineers

#281

Post by sanderjd »

BeetleB wrote: post #279
m3047 wrote: post #263

Earlier quoted context omitted.

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

What you need to shepherd them toward is not the commands to run to branch and merge, but the why. Why are branches useful? When should you merge? What do you do if there are conflicts? Most of this stuff isn't book material. It's what senior developers should be teaching junior developers.

Re: How to drive away your best engineers

#282

Post by tomp »

raisin_churn wrote: post #128
noduerme wrote: post #52

Earlier quoted context omitted.

I was waiting for a /s at the end of this comment, but now I can't tell if you're kidding.

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

MBA schools are just credentials laundering services.

Re: How to drive away your best engineers

#283

Post by BeetleB »

sanderjd wrote: post #281
BeetleB wrote: post #279

Earlier quoted context omitted.

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.

What you need to shepherd them toward is not the commands to run to branch and merge, but the why . Why are branches useful? When should you merge? What do you do if there are conflicts? Most of this stuff isn't book material. It's what senior developers should be teaching junior developers.

Although the original commenter referred to junior people, I'm often having to explain these things to those who are not - sometimes to people with more experience than I have (e.g. 15-20 years).

Besides, there are plenty of online resources as well as books on the purpose of branches, and its benefits. Some of these have been around since before Git existed. I don't have a problem explaining the why, and pointing them to resources. It's the inevitable "OK, but how do I do that with Git?"

Extending it a bit: I often work with people who will never read a manual. They'll want to find a quick SO answer, or a short tutorial for everything. But once in a while, you need to read the man page, or the official docs.

Re: How to drive away your best engineers

#284

Post by BeetleB »

sanderjd wrote: post #280
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…

> 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 things that don't have good resources, or if it's just a small tool/library that's not essential for their job, I'm happy to walk them through it.

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? Teaching the same stuff over and over again? Wouldn't you rather I either write docs or make a video once and just have them watch it? Or even better, just point them to the many existing docs/resources out there?

Re: How to drive away your best engineers

#285

Post by Ensorceled »

marcosdumay wrote: post #267
Ensorceled wrote: post #132

Earlier quoted context omitted.

- Manager: How long would it take to migrate from A to let's say B? - Me: What do we want to accomplish from the migration? I'm assuming cost reduction? - Manager: Yeah, the guys at B are much cheaper. - Me: Ok, give me until EOD Friday to do some investigation. - Manager: EOD Thursday would be better, don't need a full roadmap, just enough for an ROI. I'll flip over the CEO's spreadsheet that she's using for the cal…

How many times did you take a task you have no idea of the timeframe, do some short research without completing it and was able to make a correct estimate? If that happened even once, I would be interested to hear about it.

Literally all the time. Just had exactly this scenario with a technology switch. I spent an hour reviewing their api. We had a meeting with their sales engineer, I asked them a bunch of questions. Estimated 10-12 days to finish phase one integration, was working in single sprint. Larger projects get more upfront investigation and larger error ranges.

Re: How to drive away your best engineers

#286

Post by sanderjd »

BeetleB wrote: post #283
sanderjd wrote: post #281

Earlier quoted context omitted.

What you need to shepherd them toward is not the commands to run to branch and merge, but the why . Why are branches useful? When should you merge? What do you do if there are conflicts? Most of this stuff isn't book material. It's what senior developers should be teaching junior developers.

Although the original commenter referred to junior people, I'm often having to explain these things to those who are not - sometimes to people with more experience than I have (e.g. 15-20 years). Besides, there are plenty of online resources as well as books on the purpose of branches, and its benefits. Some of these have been around since before Git existed. I don't have a problem explaining the why, and pointing th…

Ok you convinced me that you're approaching this in a reasonable way. I also eventually check out from helping people who I become convinced are unwilling to help themselves.

Re: How to drive away your best engineers

#287

Post by sanderjd »

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, 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 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, and the company, and thus its more senior employees, should recognize that it's their job to mentor them through those gaps. Personally, I think companies are too hesitant to hire truly entry level employees and invest in training them.

Re: How to drive away your best engineers

#288

Post by hcarvalhoalves »

dalbasal wrote: post #62

Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compar…

> Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal.

"Software is eating the world", but most companies where software is either the product or a central part of the strategy (as opposed to a cost center) are still managed by people who either don't understand, or refuse to accept, that software is primarily _creative_ work, with a strong _collaborative_ component. In an attempt to reduce risk of an inherently risky creative endeavour, the management will over-hire and over-manage.

Biggest example is open-source: collaborative work done by random strangers on their own time and budget is competitive, and not rarely _way better_, than software produced by well-funded companies with competent people.

Re: How to drive away your best engineers

#289

Post by summertime42 »

anotherrandom wrote: post #264
summertime42 wrote: post #219

Earlier quoted context omitted.

If it's as bad as you say it is, collect evidence and prove Mythical Man-Month to them. Explain it's wasting more time AND money, and the deadline is missed regardless. Hopefully they'll listen.

Depends on the company. At BigCorp Inc., that sounds like a great way to get on management's bad side

It might be, but in my experience the hardest conversations are the best ones to have. If it all goes to hell, time to vote with your feet and dust off the resume, then.

Re: How to drive away your best engineers

#290

Post by fuzzfactor »

honkdaddy wrote: post #195
skeeter2020 wrote: post #189

I get why these "Managers are so clueless!" posts feel good and are often well received. One thing that would help is if technical talent didn't naturally position leadership as comprised of people who are totally different from them, who intentionally strive to create an unpleasant counter-productive environment that makes it hard to create and deliver software. I get the pain expressed here, it's real, and the prob…

Well said. Managing engineers is an incredibly difficult and multi-variable challenge - companies have been trying different approaches for nearly a century now. We like to imagine as software developers our management problems are unique and can be solved with a silver bullet blog post, but I think they’re largely the same meta-issues that Ford faced in the 30s or Boeing in the 90s.

Definitely not just software and not just engineers either.

Like he says in the final line of his epilogue:

>If you cannot change your company, change your company.

Post reply on HN