Red Flags at Your Software Engineering Job
Some of these I've experienced firsthand. Others have been sent in by readers. Things might start to... devolve... as we get toward the end.
I. You don’t have local admin rights on your machine.
As a software engineer, you’ll often run into situations where you need access to install necessary software and tools, manage your development environment, and troubleshoot issues autonomously. This level of trust and autonomy not only streamlines your workflow, but fosters a culture of responsibility and innovation.
II. When you ask your team how things are going, they just laugh and cry.
“Things are great,” or “not too well, and here’s why” should be commonly-heard responses to this question. Open communication is important in any team, especially when that communication doesn’t stem from stress or frustration.
Of course, there’s always going to be some level of stress or frustration — but when the default response is a frustrated sigh, there’s a problem.
III. Metrics for the sake of metrics.
Shareholders often want metrics, and for good reason. It puts a measurable number on various aspects of the business, allowing for good data-driven decisions to be made.
Problems arise when shareholders want metrics for metrics’ sake. A great example of this is when your company’s exec team wants to add metrics to a development team. Software development is a creative process, and there are very few things that can be measured objectively in a creative process. If you start tracking the number of brush strokes a painter makes, and their job is dependent on the number of brush strokes made, the painter will begin to make superfluous brush strokes.
The same goes for git commits, pull requests, feature launches, bug fixes, etc. Any of these metrics can, and will, be gamed when a developer’s livelihood is on the line because of it. You want to see more commits in the codebase? Lemme just whip up a cron job real quick so I can make sure I can still afford to put food on the table.
IV. Your name is spelled wrong in every system, in different ways.
My name exists in a multitude of different formats at my company, with all of them (except for one) being incorrect. It’s not like it’s a particularly hard name to spell, especially when it could’ve been copy/pasted from my application/email/resume/etc when my accounts were set up.
I have at least two different company email addresses, because I had to request the first one to be changed. So instead of changing it, I was just issued a second email. The incorrect email was still used to later set up vital systems.
Sigh.
V. Toxic personality in the leadership that everyone is afraid to challenge.
A king that demands to be the king, does not deserve to be the king.
Authority doesn’t need to assert itself forcefully; it should be recognized and respected naturally. If you feel the need to remind your peasants employees that you’re the boss and that what you say goes, then you really have no right to be in a leadership position.
If your boss has a habit of asking for feedback, yet completely disregarding it anyway by deciding to do things their way because “I’m the boss and what I say goes”, they don’t deserve to be the boss.
In addition to this, a good leader should be able to gracefully accept a challenge. You should always be able to challenge your boss’s authority, without fear of being reprimanded. I’m not saying it’s okay to burst into his office and rub your nutsack on his rolodex, but the employees shouldn’t fear being punished for challenging their boss if their boss makes a stupid fucking decision such as scrapping a major development project.
Let’s be real here for a moment. Just because somebody is in a leadership position, does not always mean they’re the best at every single aspect of the business’s function. Your CEO likely doesn’t know jack shit about software development, because it’s not their job. But if they pretend to act like they’re the authority on the subject, and demand the useage of certain tools or workflows because “their friend” says it’s best or because they have an “architect mindset” or whatever, you’re dealing with a narcissist. Run.
This is the exact type of numpty that googled “best free programming tool” (heavy on the free because they’re going to cut costs in every way possible), saw that Visual Studio Code came up as the #1 option, and decided that’s what’s going to be used for their development team. Oh, what does their company do? Build iOS apps.
Yeah.
VI. The company utilizes a chair-time metric.
Contrary to popular (c-suite) belief, nobody actually works all day. One of the biggest fears from c-suite is that employees won’t be as productive when they’re working from home vs working in the office. As someone that’s worked in-office, hybrid, and remote, I can confidently say that I’m the most productive on my WFH days.
Why?
Because I don’t have to wake up at the ass-crack of dawn. I don’t have to fight through two hours’ worth of commuter traffic. I have time for a solid breakfast, instead of forcing myself to eat whatever greasy slab McDonald’s decided to throw into my bag today. Of course, I fully understand this doesn’t work for everybody. There are plenty of folks who prefer dealing with that nightmare, and honestly I have nothing but mad (and questionable) respect for them. Don’t get me wrong here, I’m more than grateful for the opportunity to feed my family, it’d just be a teensy little bit easier if I could do my job remotely. Because I can. It’s software.
However, this brings about an important concept. Chair-time as a metric.
Truthfully, nobody consistently spends their full work-day actually doing work. And if they do, it’s because it’s being stretched out for the sake of filling that space, or because they just so happened to catch a busy day.
Why, though, is the work taking up the full time allotted instead of being completed in the most efficient manner possible? Because you’re not allowed to go home (or leave your desk) without being reprimanded in some fashion. It truly doesn’t matter if the work is finished early or not. In this situation, your presence in your cubicle is far more valuable than the actual work that was completed.
I believe this mainly has to do with the mindset that work and labor is approached with. While employers are trading their money for you to do work, in most cases they’re primarily trading their money for your time. They don’t want to pay you a week’s salary if your task for that week only took a day, so you’re required to be in your cubicle for the rest of the week until the next sprint cycle instead of being allowed to go home. It’s an asinine way of doing things, and that’s why we have day-long tasks taking up the span of a week, or hour-long tasks taking all day. Unfortunately, this chair-time metric exists almost everywhere.
VII. All Major Tech Projects Get Scrapped
Absolutely run for the hills.
When your company starts the process of trashing major tech projects, that’s your signal that your job is going to get scrapped next so you need to start putting in job applications, like, yesterday. Ask me how I know.
When projects start getting reduced to the point where it requires an almost 100% reduction in your team… godspeed.
VIII. You’re Usually Unmotivated
Obviously, I can’t speak for everybody, but I got into software primarily because I’m interested in it. I love building cool shit, I thrive when I get to work on exciting projects. I do my best work when it’s something I’m genuinely interested in doing.
Of course I can’t expect a job to provide that level of engagement at all times, that’s completely unrealistic. There are going to be times when the work is unmotivating and unengaging. I mean shit, even my personal projects have moments that feel like an absolute slog to get through; it’s normal.
But when you feel unmotivated 90% of the time, then it’s a problem.
This problem could stem from any variety of factors, some internal and some external. Because of that, I can’t say for certain if the red flag is entirely the fault of your job, it very well could be a personal problem, but I find that in most cases there’s a problem with your job if you’re feeling unmotivated by it. Talk with your manager, see if you can get assigned more interesting work, or introduce some new project ideas to your Product Mommy.
Or maybe just quit and find something else. They say variety is the spice of life, afterall, and if you’ve been at your job for a handful of years and things are starting to feel stale, then there’s no harm in leaving to pursue something else that excites you.
IX. Honorable Mentions
I’m not going to provide deatils for each of these, just a nice bulleted list. I love lists.
It’s the end of the week and you still don’t have your environment set up.
You look at the codebase and there are no tests.
You have to request access for everything, through a tool that looks like it was made two decades ago.
No 1-on-1’s with your manager.
You’re asked to develop a production-ready feature from a proof of concept overnight when there are no designs for how the feature should be integrated into the product. (I’m a developer, not a designer… you shot yourself in the foot when you fired the design team.)
Herd mentality — everyone follows the company line and there are no independent opinions or thoughts.
No laptop ready for you on the first day.
Productivity tracking tools (screenshots, mouse movement, etc)
Management spends more time checking people’s Slack status rather than solving problems.
You go for lunch with your coworkers and you all talk negatively about the job.
You’re often bored.
There are no promotional opportunities.
The workplace isn’t positive.
The organizational chart frequently changes.
You feel replaceable.
You’re thinking about finding a new job already.
You’re questioning the company’s ethics.
Your company is losing its top talent.
Your role has never grown.