The amount of code my team churns out is high but the thought around code as a liability is low.
I miss the surgical like precision work where the team comes together and reaches consensus and do their absolute best to prepare, execute and maintain.
What are you missing?
- 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.
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.
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.
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 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!
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.
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
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.
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...
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.
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...
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!