In general, engineering managers. I'm not talking about "bad" engineering managers, I'm talking about average ones (which are the ones one usually get).

- It's difficult to sell good engineering work to them, and hence salary increases happen (if any) but on the lower end.

- With the typical excuse "Eng. managers should empower engineers", eng. managers do around 1% of the job when it comes to start big projects. The whole load lies on the shoulders of the senior engineers. One would expect that an eng. manager is probably the individual in the team with the most experience (both in engineering and in management), but eng. managers usually don't spend time trying to understand the systems their teams own. A classic example is: an eng. manager who knows very little or nothing about, let's say, Node+js, even though he has been in the team for over a year: their excuse? They only care about the "high level design decisions, they don't need to code anything". Funny thing is, the "high level design decisions" are done by senior engineers

Good engineering managers are invaluable, though. But in 80% of the software teams out there we either have bad eng. managers or average ones. In summary:

- good eng. managers => heaven

- bad eng. managers => it's ok. Since they are bad, they most probably will be fired or the whole team will know quickly how bad they are

- average eng. managers => hell. Because they are not "bad", so they are not fired. They think they are good and all.

I think you misunderstand the engineering manager position. They've to do things like present to senior stakeholders, manage expectations and handle deadlines, report on team progress, handle the teams budget, report upwards on how the team is doing, individually and as a team, ensure the team has the correct resources, ensure the team isn't blocked, facilitate planning and changes to plans, handling requests from different departments, focusing on continuous process improvement, interviewing, set vision and direction for the team, track and maintain delivery risks, align with others teams, know what other teams are up to, know high level changes across the company.

They do all this while having the technical grasp on what the team is delivering and how they are delivering it. If they're jumping into details around Node+js they are likely ignoring something else important.

A software engineer's responsibility is to design, build, test, monitor software while an engineering manager's responsibility is to oversee the team, projects, resources and stakeholders.

> A software engineer's responsibility is to design, build, test, monitor software while an engineering manager's responsibility is to oversee the team, projects, resources and stakeholders.

I think much of the frustration comes when a EM ONLY manages upwards with no regards to their direct reports. It creates a situation where the engineers are responsible for implementing decisions and patterns that they had no power over (often repeatedly warned against, to no avail) because that EM is bottlenecking their feedback and selectively reporting up to make themselves look good, sacrificing their team. In companies without skip-step reporting (where direct reports give feedback on the EM to their boss, once a quarter or whatever) this can lead to a death spiral where all the engineers are unhappy with a EM but there's no mechanism to remove them or complain to the higher ups. It just leads to mass dissatisfaction and group resignations, but even then there's no guarantee the EM will be removed if the higher ups don't know it's because of them.

That sort of strict top-down hierarchy just doesn't really work in software dev when the engineers have more technical savvy than their managers, and yet are constantly overruled and silenced in the pursuit of political points.

I agree with your broad point but the hierarchy is there on purpose.

Yes it is, but it should also have feedback systems where underlings can review their superiors. Hierarchy doesn't have to mean that underlings have nothing valuable to contribute.

I'll take the other side of this.

There are of course bad and average eng managers who have skills that are subpar. Let's keep them out of this discussion - they should be fired.

But the majority of eng managers who have the chops probably can't be in the weeds (even if they'd like to) because their plate is full of other nonsensical shit. Meetings, reviews, more meetings, planning, more meetings, and so on that effectively fills up the productive and creative part of the brain and day. At the end you're left with very little brain space to dig into, understand, and guide complex technical decisions.

No one needs to cry a tear for them or empathize but I suspect that's the reality.

What am I missing? The family environment that once existed in multiple companies.

I still remember that day where our manager came in the main office and said "for crying out loud, why am I having all these cravings the whole day? Who wants food?!" and he went on and ordered an entire buffet for us of so many things that felt like a birthday party.

I remember how productive we were after that for the remaining year.

Ah...so many mesmerizing memories.

Life was good back then, life was valued, believe it or not even by our management!

I have all the usual gripes, but right now the top one is slow and complicated onboarding.

There is no reason for dev environments and permissions to be set up manually. Automate it, test it, use CI/CD to keep it working, and you'll be able to hand new hires their computers and have them hit the road running before lunchtime. Of course you want to do pair programming, or better yet, mob programming at least the first few weeks to get into way of working and team cohesion, there's no technical silver bullet for that.

Also, stop issuing Windows machines or making devs deploy on Windows unless they are explicitly developing for the Windows stack and/or ask for it. Let them choose between Mac and Linux, or if you're resource constrained, just Linux.

The greatest decision I made was moving to a job that is purely offline code and involves zero dealing with the network

Before that I was very frustrated with the amount of boilerplate/infrastructure/logging/metrics/error handling/deployments/graphs/cloud platforms involved in modern web dev

It’s insane how much stuff is involved unrelated to writing code (for good reasons usually)

I just like sitting down and writing interesting code (that’s what got me into this field), so getting to focus on logic/algorithms with code that all lives in one process on one machine has been so much nicer

If you could share some details what do you work on?

Jira and the ticketization and subdivision of work into trivial units, removing real ownership of a feature. It's not that I'm against planning work over time, but there should be a minimum level of a granularity that's more than a few lines of code at a time so that a single person can effectively design, implement, debug, polish, and ultimately ship a meaningful chunk of work -- at the feature level, ideally -- rather than some minor subsystem that then gets integrated into a bunch of other subunits of work by three or four other people and then tested by yet more people who had no prior contact with the body of work. This sort of divide-and-conquer, IME, leads to terrible user experiences and unmaintainable code because no one person or team or has oversight or ownership into the final integrated product.

I only had this problem at companies with heavy middle management and not enough engineering input into processes, often with no engineering leadership at the top or upper middle. I eventually quit that job because I was so frustrated by the stupid bureaucracy and my micromanaging direct manager, who wasn't very experienced in the frontend world and kept suggesting (nay, insisting) on inappropriate solutions based on his prior knowledge from 10 years ago in a different field.

I got 10x more work done before they implemented the new system and brought on the new manager. This sort of system was intended to bring up the bottom performers and help them stay accountable, but as one of the higher performers on my team (according to my reviews, anyway), it constantly hampered me and prevented me from getting meaningful work done. I spent way more time fighting the bureaucracy and shuffling Jira tickets between like 8 columns and more subcolumns (that nobody really followed anyway) than coding. Quit soon after that, after complaining to our VP with a detailed report about why the new system wasn't working and was actually hurting productivity. All he did was ask me to hide the report so I wouldn't embarrass anyone =/

All my best work was done in the opposite situation: small teams with high autonomy and minimal managerial interference. We still had frequent checkpoints and demos, but the engineers did the actual design and coding, and we were measured by our outputs, not our processes.

I get most frustrated about meetings... so frustrated, I wrote down some guidance in my blog[1].

Intersting fact: What I like most is Code Reviews (which is kind of a meeting)... a breathe of fresh air if done right.

[1]: https://pilabor.com/blog/2021/04/tips-and-tricks-for-meeting...

I can definitely relate to missing the days of more deliberate and quality-focused work. In the rush to produce more code, we sometimes overlook the value of precision and consensus building. It's vital to remember that balance is key in the software development world.

Low IQ management who contribute negative value. It doesn’t have to be this way - I’ve worked with high IQ management - but it seems to be the norm in the industry now.

I wouldn't say creating value is the smaller goal. It's THE goal. From a business perspective or an engineering perspective, everyone (aside from pure sociopaths who use unethical means) can agree that creating something of value is the only path to revenue.

Creating value means different things though. Values change between different phases of the project, across different stakeholders, across levels of engineering expertise. Coming to agreement on the value proposition ("when the team comes together and reaches consensus") takes time, mental work, and commitment to the process. Far too many companies run with the "just start coding" mentality, skipping the crucial goal of reaching consensus. That's what's missing. We're vision-constrained and often don't even know what we're building or why.

I'd say the following are my two main frustrations:

1. Poor planning and scope changes for tickets and projects. Nothing more infuriating than starting work and realising that the task is more complex than expected/has more moving parts to take care of than expected, and the planned approach won't be sufficient at all. Or in the case of a recent example, having one ticket that completely makes the previous ticket redundant, because the previous one was designed and created based on an assumption that hadn't been thought out properly...

2. Lengthy build processes. How do they expect devs to properly QA each other's work if switching branch and building the project takes 10+ minutes every time? Or heck, just stay in the flow in general if the only way to check your work properly involves waiting for the same process? We definitely need to find a way to decrease the length of time this takes, and separate compiling the front end and back end for this project...

Scrum, JIRA and typescript summarizes all frustrations at work

Typescript errors like the never one

tl;dr: are you familiar with the book "Death March" by Edward Yourdon?

At my job there aren't any clearly defined roles. Development takes ages, there is no sense of accountability, and there is no desire from anyone to actually improve anything. All development is done by one single developer unless you were chosen to be on one of the two sub-development teams that exist (I never see them or hear what they're up to)

The CEO will assume the role of product manager for a given project and disappear 99% of the time. The head of the dev department will assume the role of project manager and also disappear for 99% of the time. I see him working on other tasks including submitting and self-approving PRs for small, random bugfixes that would be better suited for junior developers

If you want a product manager to weigh in on your work, they will do that at the tail end of development when one is randomly assigned to look at what you've made, but only right before you're ready to ship. And you, software developer, have to dictate to them how this thing that you were told to build should fit into their product roadmap, whatever that is, even though that discussion won't result in any follow-up development work

While working, posting detailed progress updates in multiple formats is encouraged. In other words, you should record a demo of what you're doing, then also transcribe that into screenshots and text in case someone has a preference for one over the other (though it doesn't really matter since nobody is going to look at either)

When you get input, it will always be to request for more changes. "I told you to name this feature 'actions' last month? Well I think it should be 'plans' now. Go rename all of the files, endpoints, database fields, and everything else. Plans are done? Well here's a discussion I had with someone else the other day in a separate issue that you weren't involved with where I said 'maybe plans should be given a special dashboard, but I'm not sure'. So why didn't you make that special dashboard? You can't release an incomplete feature, you know"

Features can't be shipped until someone else signs off of them. I have shipped several features by deliberately bypassing these checks. Nobody has noticed or cared so far

My direct "boss" has no realistic input or effect on anything that I'm actively involved in working on. I check in with him every couple of weeks where I bring up the lack of involvement from a feature's stakeholders and the endless scope-creep on whatever projects I'm handed. He tells me that even though I've pinged everyone who's involved multiple times, I really just need to keep pinging them for input. They are simply too busy to check their notifications or even do their jobs, after all. Otherwise, I should just keep on keeping on

But hey, at least the pay is good!