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

41–50 of 316 posts

Re: How to drive away your best engineers

#41

Post by speedgoose »

marginalia_nu wrote: post #19
romanovcode wrote: post #9

Earlier quoted context omitted.

> My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated). What one developer can do in a week - two developers can do in two weeks!

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!

Make sure to deploy your micro services in Microsoft Azure AKS to improve the reliability on the long term, thanks to the included and frequent network issues.

Re: How to drive away your best engineers

#42

Post by threatripper »

SideburnsOfDoom wrote: post #31
threatripper wrote: post #16

Earlier quoted context omitted.

Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. A total nightmare for project management.

> Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. So you're saying that 1) engineers have to be forced to "commit to a schedule" and b) that schedule then turns out to be fantasy. I want you to think harder about what you said and where the problem actually lies. Maybe th…

True, the problem lies somewhere else. Maybe the project should not exist at all if it's not manageable.

The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time?" and if you cannot then you should not take the project. The problem is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great.

Re: How to drive away your best engineers

#43

Post by SideburnsOfDoom »

threatripper wrote: post #42
SideburnsOfDoom wrote: post #31

Earlier quoted context omitted.

> Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. So you're saying that 1) engineers have to be forced to "commit to a schedule" and b) that schedule then turns out to be fantasy. I want you to think harder about what you said and where the problem actually lies. Maybe th…

True, the problem lies somewhere else. Maybe the project should not exist at all if it's not manageable. The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time?" and if you cannot then you should not take the project. The problem is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the en…

> The question "can you do it?" implies more than "can you maybe do it if you have infinite time and luck?" it implies "can you deliver on time?

Incorrect, it implies "can you do it in a reasonable time, that is as yet unknown and unknowable" - which might even be quite small, but no-one really knows, so committing to a fixed deadline is at best fooling yourself, and is more likely a trap.

> is that it's hard to hire engineers that are capable enough. Therefore we must make it work with the engineers we have and that means to push them harder than they are used to. If they succeed, then great.

I think that problem is that this is an intentionally deceptive, demented burnout-factory, and no decent engineer would want to work for you.

Re: How to drive away your best engineers

#44

Post by katzgrau »

"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 knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy.

If any engineers are under the impression that their job is harder or more important than management, sales, etc, they're being arrogant.

Coming from a former strong engineer who started a company and now manages people more than code.

Re: How to drive away your best engineers

#45

Post by noduerme »

Granted, speaking as someone running a very small shop, mostly freelance, I really think a lot of the ennui and sense of being overwhelmed or unsatisfied can be solved by just deploying constantly. Rather than get stuck in a review cycle I try to get every incremental change online as soon as it's done and minimally tested. That can be up to six live redeployments per day, especially when a new feature is in beta. It's however many redeployments are needed when something launches. I prefer a local test server and straight to production. When you get the third build of the day uploaded by 5pm, and hold your breath til 6pm without anything catastrophic happening, you can keep your phone on and go get some beer and fajitas. If you make it to 8pm and the company is still running, a deep sense of fulfillment sets in about a job well done. That feeling of the day's work being done just doesn't exist unless you break it up into tiny incremental updates.

Re: How to drive away your best engineers

#46

Post by hibernator149 »

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 data that just isn't available, please take the time to ask yoursevles if you are micromanaging. Going with a less concrete plan is definitely better than going with a plan based on wrong assumptions! Maybe you are in a position where deadlines just make no sense and you need to be more agile?

Re: How to drive away your best engineers

#47

Post by [deleted] »

threatripper wrote: post #30
romanovcode wrote: post #9

Earlier quoted context omitted.

> My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated). What one developer can do in a week - two developers can do in two weeks!

It sounds like you're not having enough coordination meetings. You can make communication more efficient if you add more levels of hierarchy. MBAs are good at managing. Engineers are often wandering off-topic, so put MBAs in between the engineers to manage the communication and avoid unsupervised engineer-engineer-contact between different groups.

[deleted]

Re: How to drive away your best engineers

#48

Post by LaurensBER »

tomohawk wrote: post #13

Agree on some points (first 3 for sure), disagree on others. A major missing one is the demoralizing effect of having to work with incompetent team members, with management unwilling or unable to do anything about it. An incompetent person is likely not a bad person - more likely a good person who is the wrong position, or who just isn't capable. I recall working on a team where I was called over by one of the member…

I'm glad you said that this was at a government agency otherwise I would have been sure that we worked together in the same team, with the same person.

I worked together for a year with A. who is a "senior" engineer, some of the stuff that A. pulled was;

- Not being able to use GIT. At some point we decided that I would have to do all merges because he just wasn't capable of doing them.

- Editing the project using nano on a server because he couldn't figure out how to install GIT on his laptop. This included YAML files where he would manually count the indentation...

- Reviewing the old code in a pull-request, multiple times...

- Copying the requirements from project A to unrelated project B because they're both Python projects so it should work?

- Claiming to be able to program in multiple languages, giving examples such as INI, YAML and JSON...

- Claiming expert knowledge in C++ and Java, I haven't seen him read or write a single line in all the time that we worked together.

- Sending endless questions over Slack about the most basic things that he could figure out himself (e.g did you look at that PR? When I had already approved and merged it or how do I change something using SQL?)

- In general just not getting anything done, there was one sprint in which he finished two tasks, one of which was changing a password in a text file

After a while he was made temporary lead and the following happend;

- Killed my CI/CD pipeline because "automation is dangerous", manual releases now routinely take over 12 hours...

- Introduced a rule that PRs now had to include screenshots of manual tests instead of us writing automated tests - Lying to stakeholders about issues, literally: "we can just claim it was a bug in vendor X code, it will look better!"

- Proposing to re-review old PRs every two weeks, because PRs are like fine wine?

- Giving tasks to the team that made no sense. E.g a task to clean-up old versions of software X that was upgraded using YUM on a Linux server. I tried to raise the point that the package already included a clean-up script. He got angry and didn't want to hear it, I chilled for a day and closed the ticket.

- Insisting that production password would be encrypted on disk (granted, not the worst idea!) just to proceed with then storing the plain-text password on Confluence (where it was accessible to the whole company) and in GIT :)

- Killing our database replica's because: "they were misconfigured, someone linked them to the production database. That's very dangerous!"

I documented and raised these issues with my manager who didn't want to address them because: "it would be bad for A. motivation". I said screw this, I can't work like this and stopped working with him on that specific project. Productivity dropped 80%.

He's currently scheduled for a promotion to "tech-lead" at the end of the year. I've left that place, some places are just not worth saving.

Re: How to drive away your best engineers

#49

Post by Gigachad »

noduerme wrote: post #45

Granted, speaking as someone running a very small shop, mostly freelance, I really think a lot of the ennui and sense of being overwhelmed or unsatisfied can be solved by just deploying constantly. Rather than get stuck in a review cycle I try to get every incremental change online as soon as it's done and minimally tested. That can be up to six live redeployments per day, especially when a new feature is in beta. It…

It astounds me how some companies will let months of work sit in an unmerged PR and then sometimes decide they don't even want it. Not only is it a massive waste of resources, its shit for the person who built it, and also sucks if you actually do have to merge it and resolve months of merge conflicts.

Re: How to drive away your best engineers

#50

Post by astura »

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.

Post reply on HN