Ways to improve mental health for software developers

Any business looks for results. Media companies will do whatever brings in results. What brings in results? Sowing discord and division because that’s what keeps people coming back. How do we sow division? By making strawmen of anything we don’t understand. When a millennial says “boomer” and when a boomer hears “boomer”, they are talking about completely different things. But the word “boomer” gives us the illusion that we’re all talking about the same thing and that the other person truly is out to “get us”.

These are unfortunate tricks of the mind that are being used to serve our short term ego-gratifying needs. If any progress is to be made, we need to rise above these petty squabbles by focusing on what’s important and not what someone else tells us is important.

My problem with your solution is that, practically speaking, engineering managers often end up being glorified vice project managers because of the number of meetings they end up in. As a result, they can be significantly disconnected from the actual technology being used and the perils they are fraught with that can cause complications when implementing even simple features.

At least an EM knows something about engineering. And an EM is a role that indeed should exist in some capacity, whether or not that's the exact title they are given.

What I believe would be better is for engineering teams to be involved in the early to middle stages of planning and pre-development, and for either an EM or team lead to have the authority to prevent product owners and other departments from applying undue pressure on individual engineers. That should be the primary role of a lead, and they should otherwise step out of the way and let engineers speak for themselves since they are the ones working directly with the software and APIs being used.

Otherwise, we end up with a similar problem to the one I witness, which is that the EM in your approach would end up being incentivized towards diplomacy more so than serving the needs of either side. A leader-as-an-interface shields both parties from each other but also facilitates alienation. An EM that works in tandem with the engineering team can make sense, but standing between engineering and other company operations to me is an anti-pattern. Middle men are better off not existing at all even if it means having no EM or PM. All they do is remove power from both sides rather than become involved on an as-needed basis.

Let's put aside for a second that there are many lackluster programmers who happen to also be expensive.

The idea that there's "tech companies" and then there's the rest of the economy doesn't make sense, and probably has always been a false dichotomy. Small companies to BigCo fundamentally run on technology. Small hiccups in that technology cause gigantic interruptions. Until we are automated out of existence, they can't get away from us engineers.

One might say that software engineers are glorified digital plumbers. While there's a lick of truth to that statement, this is ignoring the fact that you wouldn't necessarily hire a plumber rather than a structural engineer when designing and constructing a building. Just as a structural or civic engineer must do research and calculations for every single job they are tasked with, software engineers necessarily must research and solve unique problems 99.9% of the time. You can't train a software engineer to do one thing repetitiously as what could have been done with a Ford assembly line worker. In software, there is simply no equivalent to being trained to turn the same bolt hundreds of times a day and that becoming your only job.

This isn't to say that there aren't repetitious aspects of the software developer's job. Many projects share certain qualities (ex. CRUD apps), and some repetition results from the role of a developer being overloaded.

I believe you are mistaken in suggesting there are no "rockstar" programmers. While I would shy away from such a cringe term, though rare they are, I've encountered a few "rockstars" in my time. They tend to do at least 80% of the work, perhaps 90%, by virtue of their cognitive capacity and ability to adapt. Do they make proportionally more than most other developers? Of course not. At best they are viewed as liaisons for their respective teams.

I am by no means saying that developers should be the backbone of a company. Although that can and does happen, and my have benefits, developers aren't necessarily qualified to manage or make high-level decisions that will take the business in different directions. Arguably, the hierarchs of companies are of a higher tier than developers because, while the developers are navigating, ultimately those hierarchs are the ones at the steering wheel, to use a somewhat flawed metaphor.

On the other hand, developers aren't of equal value to the janitorial staff. They aren't equal value to sales or customer service. They aren't even equal to design teams, since design teams usually can't ship a product themselves, and a product with poor design that does its job well is far better than a Figma document, which on its own is essentially nothing.

And yet many companies privilege these other departments over engineering, sometimes even when their core product is software. To put it bluntly, while there certainly are some excellent companies out there that treat engineers properly, too many companies mistakenly view software engineering as a necessary evil and as something that can and should do anything that is thrown at it because they themselves often aren't of the engineering mindset themselves. Most people get educated, "finish" those educations, and thus fail to understand that engineering can't possibly work the way they've treated their own specialties.

There is simply no reason why mid to senior level software developers can't be more closely involved with in pre-development and actually be listened to. My hypothesis is that having engineers sectioned off while a project manager or team lead acts as the sole interface with the rest of the company simply doesn't cut it, and it results in the demoralization of engineers because their voice is rarely heard or respected. Engineers think they don't want to be involved with the rest of the business, and while there's a benefit to avoiding possible distractions from coding, this non-involvement comes at an unseen cost.

> In command and control structures value is given by position not by contribution.

While that is true, and to a large respect is inevitable, that doesn't mean that its logical extreme should play out.

No matter what, power politics always emerges. It even emerges among engineers themselves. I'd go as far as to say it's a law of the universe.

Yet what happens when that law is amplified to such an extent that one party loses too often? They become alienated and demoralized. Not across the board, mind you. I am not suggesting that all or even most software developers experience these mental health issues because of where they fall in typical corporate structures. But when the problem exaggerates itself, even reaching its logical conclusion (which I have experienced myself), enough people can lose their sense of self worth that no amount of money can compensate for it. In the worst case, the personnel that companies lose are the rockstars, so to speak.

To expand on that last point, I myself have experienced being taken to the far end of the spectrum. I once worked for a team that went from having their own offices to a room with their own desks, to a bigger room with shared desks, and finally to a supply closet in the center of a building with no windows. All the while, sales and HR all got their own desks and cubes and were given frequent recognition even though this company's business was selling software. We went from being treated like experts to being sectioned off from the rest of the company and not being consulted for anything. This all happened within a year, and the first people to go were the ones with the most talent (fortunately one of them ended up at Apple and has been there for years now).

Yes, that's an extreme example, but this plays out to a lesser degree at many companies. Those whom are solving fundamental problems are often viewed as less than they actually are. By no means am I trying to glorify software development, because there's a banality to it at the same time. But it's not nothing. In fact it's the closest thing to reality that exists in companies that sell digital products. Without solving problems with logic and mathematics, everything else is just fantasy.

Businesses will have a better chance at achieving excellence and adapting to problems if they cut out the monkeys in the middle and allow engineers to be involved earlier in processes. Though sadly the vast majority of businesses are actually disinterested in excellence of any kind since excellence conflicts with the traversal of power structures through politics.

If businesses fail to hold on to software developers and struggle to hire new ones, it shouldn't be a mystery to them why they are facing that struggle. Maybe developers are more important than some of the traditional roles that they venerate.

So no, I don't agree that we deserve to be treated as low tier as we often are.

I havent had the mindspace to continue working on it since the startup I cofounded has taken off due to covid. Context - We provide medical diagnostic tests B2C in India.

It seems insane that they would not recognize it.

But the average engineer working on an average side project will not do something like that. Especially not during a quarterly review cycle. So then your accomplishments working 80% are compared to those working 100%.

I never worked with someone who had a 20% project during my 3 years. I did try to start one myself, but gave up after 1 day.