It’s one thing to know how to quit a job; it’s another to know when it’s time. Last year I outlined 15 rules for quitting your job. Here, I’ll give you developers some tips on when to consider it. Don’t jump too quickly, however, as the Trumpocalypse is soon upon us and economic turmoil could be part of the game.
I’m lucky. I work for a great company, my co-workers are nice, I get to work from home, and I get to write about tech and code. It hasn’t always been that way. I’ve worked at some sad, dysfunctional places. I’ve also been able to abandon ship before big layoffs because I could read the tea leaves. It’s an intangible skill that comes in handy at many programming shops.
Here are nine reasons you might want to quote Johnny Paycheck to your current employer and find a new home for your coding chops.
1. Your system has been called legacy
If you’re working on the “legacy system,” polish your resume, cross-train if possible, and learn something new. Your organization, especially the bean counters, are looking to replace the system, and a lot of dumb organizations dump the people along with it and hire someone who already knows the new stuff.
Right now there’s an old codger reading this and saying, “Yeah, whatever kid, I’ve been on the legacy team for 30 years.” Certainly, that happens. But I’ve sorted through more than one resume where a person hadn’t learned a thing in two or three decades and suddenly had to look for a new job. Sometimes taking small risks is better than thinking you’re not taking any risks but finding out you’d taken on the hugest risk of all: irrelevancy.
2. You aren’t invited to meetings you used to attend
Whether the reason given is personal, professional, or technological, being dropped from a regular meeting is generally a sign that your ticket is punched. Look for the big rectangle on the wall and step through.
3. Bigoted boss in a diversity desert
As a white guy, I don’t have to deal with much racism. And like many people, I used to think racism was as obvious as the N word or someone wearing a sheet or a bunch of rednecks driving through a town in trucks with Confederate flags staging a “victory parade” for the president-elect. However, there are other forms, and if you find yourself being victimized in the workplace, no matter how minor it might seem, you should think about moving on.
This could mean being singled out or written up for the same things your co-workers are doing. Or the standard for your work is clearly different than your co-workers’ in your employer’s eyes. Or you find the reward is less. Or your evaluations bizarrely swing from positive to negative without any large changes in your performance.
Sadly, protections against these developments are virtually nonexistent. As an industry we suffer from cognitive dissonance. There is always someone explaining how it’s not really happening or not about race. If you’re in tech despite the bias, you have a lot of choice. Even if through social coincidence you’re not in a “protected class,” you have to ask yourself if you really want to work at a place where everyone who doesn’t look like you starts finding the door.
4. No quality standards
I’ve work for companies that talk about needing a “business case” to justify writing unit or load tests. And I’ve worked at firms where the only thank you for delivery are recriminations when (shockingly) things don’t go right and bugs make their way into production. Get out!
5. Top-down design/management
I’m not saying there shouldn’t be an architect or the business requirements are up to the developers or you should be able to download all the shiny stuff off the internet and pad your resume. What I mean is that thing where the boss comes in and makes a declaration, then after he leaves everyone agrees it’s not going to work but we’ll do it anyway. That’s the time to go. It leads to terrible software and failed projects.
6. Cargo-cult agile
Recently a certain consulting company created a diagram of “agile process” that resembles a map for a terribly designed subway system. Someone actually thought this subway map was the best representation of the software development process.
Imagine the sheer number of lines of process documentation per line of code that they generate! There are a lot of organizations that follow byzantine and cavernous versions of the SDLC/waterfall method while using agile terminology. Many of those throw the process out the window when it comes time to actually get anything done. If you want to produce actual software that actually works, this isn’t the kind of environment you want to be in.
7. A written PIP or negative review
Generally a manager who wants to help you get better talks to you informally. If they instead write you a negative review or performance improvement plan (PIP), it’s really the “first-step-toward-firing-you plan,” as another writer put it.
8. New must-have requirements at random
I once worked at a place that put new requirements in shortly preceding the release. The developers would cram to finish them right before, often staying up into the night. Shockingly these new requirements rarely worked right.
Don’t worry they were “agile,” so it was fine!
9. Repeated failures
If the software your team releases is a repeated failure (only internal teams tend to get away with this) and they refuse to change the way they do things, then maybe you should change your team the other way: with your feet.
It’s coming on a new year. If any of the above resonate, maybe your new year’s resolution should be to find a new place to work. What else has set or sent you off? Let me know on Twitter.