Software developers, what are your top frustrations at work?

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.

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

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!