How to Decide Whether to Leave or Stay at Your Current Workplace During the Great Resignation

There are a lot of opportunities for IT specialists to find new work right now. No matter what you decide - either staying in the same company or searching for something else - it makes a lot of sense to evaluate your current workplace. Here is my checklist to determine whether a job is desirable or not.

Human factor

Maybe we spend a lot of time in front of our computers, but human interactions are a big part of the job. It's an essential factor of why people leave or stay in the company. What should you pay attention to?

1. Are your colleagues friendly and helpful?

I find it sad that it is so common in the industry to not be welcoming for newcomers or not be helpful. The truth is that even in small projects, nobody would be able to do the whole job from start to finish - from figuring out the requirements, through developing the application, to deploying & supporting the users. As every person on the team needs others to be productive, your best contribution is often to help your colleagues.

2. Is there much pressure coming from the business side or management?

Another vital part of your job experience - is your manager protecting you from external factors or passing the pressure down to you. I’m not sure about every developer, but I’m both happier & more productive without stressing out too much - I already tend to overcommit, and I don’t need an environment that encourages this & hoping for people to still deliver with the impossible deadlines.

3. Do you get a good machine and tooling?

Your evaluation depends on your productivity, and your productivity depends on your computer, dev tools on it & 3rd party providers you are using. In most cases, engineering time is more expensive than computers or tooling. It’s a no-brainer from the business perspective for the company to spend as much as necessary on those tools & make sure the people can use their time as productively as possible. If they miss on this opportunity, you have a good reason to doubt the leadership in general.

4. How much overlap is in the knowledge in the team?

If nobody is backing you up, you are gonna have a bad time. If nobody does the things you do on a day-to-day basis, as soon as you are off & something is broken, you will get urgent calls. It can be especially tricky if the team is too small to have adequate overlap between team members, but this shouldn’t make you accept being irreplaceable.

5. Are there regular code reviews?

Code reviews are the minimum needed to keep people in the loop about code changes. It’s an excellent place to discuss the direction the team is pushing the codebase. If you lack this in the project, you can find yourself turning into the sole developer of a given module. It’s a quick path to getting more pressure if something needs to be done there.

6. Are there regular retrospectives in the team?

Retrospectives are an excellent way to improve team productivity and figure out how team members can help each other. Pretty likely that you all are missing some low-hanging fruits if your team doesn’t discuss those possibilities regularly. Or there are some unresolved issues between team members that could be fixed if there was a place to discuss them constructively.

Technical

Even in the IT sector, some companies are behind the state-of-the-art practices of our industry. Not following best practices is a false time saver, as pretty soon, there will be a regression slipping through quality assurance and coming back as an emergency. The following points are crucial, and they make your developer’s life way easier.

1. Manual quality assurance (QA)

Manual testing is the first line of protection from regressions & unfulfilled requirements. From the developer’s perspective, it’s reassuring to have a colleague checking the application before my changes go to production. QA is another case of the company’s best interests being in line with yours. - it’s simply cheaper to find & fix bugs before they get to production. And it’s less stressful for all the developers involved.

2. Static analyses

Automated quality assurance on the fundamental level. Tools such as eslint & prettier on the frontend; Flake8 & black in Python help you ensure code-style consistency & protect from the simplest errors you could introduce to your codebase. Setting them up & applying all initial changes takes time, but the most difficult is to get all team members on board & get them to use those tools consistently - especially before merging the changes to the main branch.

3. Unit test

Another automated & fast tool to verify the code. Unit tests catch minor regressions due to refactorings, library updates, or people changing code before really understanding how it’s working. If your workplace lacks them, it's pretty likely you guys waste a lot of time fixing bugs that could have been found before it gets out.

4. End-to-end (e2e) or integration tests

Integration tests are the most demanding tests to write & maintain. While unit tests are testing code in isolation - with plenty of mocks & dummy data, here the idea is to test as close to production set-up as possible. So for a web project, you have tools like cypress to run tests against your frontend application, backend server & database. With so many moving parts, it’s more tricky to set up, but it can catch issues in any of those layers. One caveat to mention - once it finds a problem, it takes time to figure out which layer is causing the issue.

5. Continuous Integration (CI)

It would be impractical to run all those checks on developers’ machines before committing. But if you don’t run these scripts regularly, the codebase will deteriorate & issues will pile up. The solution is to run it on an external machine on every commit or branch created on the repo. An additional benefit is that we have an official log of the state of the code - so if some breaking change will get through, we can easily find the commit that introduced it.

6. Documentation

The only thing worse than writing documentation is not having one when you need it. And any nontrivial project needs at least a few words of explanation on how to start it & how it’s structured. I always think about documentation as a gift I have for my future colleagues, and it’s something they can lean onto when they try to figure out my work when I’m no longer part of the team anymore. Or when I’m on vacation, and the last thing I need is a call from work.

Long term

As in everybody's favorite interview question: “Where do you see yourself in 5 years” - make sure your company will not be pushing you towards the place you don’t want to find yourself.

1. How much can you learn?

You never stop learning as a developer, but not some places are better for learning than others. If you are surrounded by people with more experience & they are happy to help you out - that sounds like an excellent place to grow your skills. On the other hand, if you are working alone or doing repetitive tasks, your learning on the job will stop. In that case, you can learn after hours, but you could also be preparing for an interview.

2. Is the company paying you the market rate?

Unless you work in an NGO that matches your values, there is no reason to stay in a company that pays you below the market rate. To figure out your market value, you can use this resource and invest a few hours per year to ensure you notice when you become underpaid. Otherwise, it’s as if you are part-time volunteering for this for-profit company you are working for.

3. Are the skills the company needs overlapping with your preferences?

Is the company set on migrating to python, but you love your semicolons? Broken quality assurance makes you almost a service desk person instead of a developer? Or there will never be a dev ops person on the team, and someone has to learn it? In all those cases it can be that you are simply not compatible with the future the company has for you. A good reason to reevaluate if you want to continue there.

4. Is the company stuck with dead-end technology?

I’m an AngularJs dev in 2021, and at the same time:

1. don’t recommend the company to migrate to some other framework - too much of an investment
2. I wouldn't recommend this application stack to newcomers
3. I myself wouldn't learn Angular these days, let alone AngularJs

So depending on how you see your future in the industry, you can consider moving to more popular tools, or something with a brighter future than a stack that was fancy in 2013.

5. Is the team growing or shrinking

There is this thing of growing along with your company or team. Just because you started early, by default, you will be somehow in charge of people getting on board later on. So you can smoothly go from mid-programmer tasks to senior ones or beyond. The same thing applies in reverse - if your team is shrinking, you can find yourself with no juniors to mentor or programmers to manage. To summarize - a small but growing team is a perfect place to be for a career-oriented person.

6. Would you bet your own money on the project?

No matter your compensation model, even if you paid cash only, your financial success depends on the company. If the company is doing good & growing, it will be more likely to keep up with the market, and your piece of the pie could be growing, even if your share is not increasing. On one other end of the spectrum, if the company is shrinking, the money will be tight, and it can cause any of the issues discussed above.

Summary

It’s a good idea to evaluate the company you are working for from time to time. You should make sure you're not stuck in a worse place than you could be because nobody else will do it for you. Let me know in the comments how your company is doing, and if there are other things you would consider about your job.