I recently read a post on a career advice board from a software engineer who was worried his job was hurting his career. He worked with “legacy code” at a boring company where nothing ever changed. They were stuck with outdated systems and poor development/IT practices. He felt behind in the industry and was worried that this was going to limit his future job prospects. Can working in this type of environment hurt your career? The answer is yes… if you let it. There are really only two options to avoid this.

Option 1: Leave

The first, and most commonly-taken route, is to leave. I don’t know an engineer who doesn’t regularly receive messages from recruiters on LinkedIn. If you don’t like the work then leaving may be a viable option. And in some cases (toxic environment, dying industry, bad pay/benefits) it may be the only option.

Option 2: Improve

The harder yet infinitely more rewarding option is to stick around and take some initiative to improve it. It’s not easy. It will take time and require you to completely change the way you work.

If you continue to approach your work as “just legacy code” then you’ll always do the bare minimum to make your changes work. Which, unfortunately, exacerbates the problem. Technical debt will continue to pile up as you work around existing limitations. Your processes and technology stacks will never improve. The fires and heroics will continue and probably even worsen.

But if you change the way you work and look for opportunities to make small and measurable improvements you can make a lot of difference really fast. And I do mean small improvements. Don’t go in there and immediately preach DevOps, Docker, or whatever the buzzword of the day is. Preaching is a good way to get people to ignore you. Demonstrating results is what will bring people over to your side.

Where do I start?

Here are a few ideas:

• Got bugs? Take an afternoon and fix all the little ones that have never been deemed important enough to prioritize. Clearing out that list could be a huge morale booster for the team.
• Is your “legacy code” missing unit tests? Next time you touch it, budget a few extra hours to refactor a small component to make it testable and write some tests.
• Does your dev environment break a lot? See if your ops people will let you spend a day or two helping them script its creation/configuration using infrastructure as code tools, so destroying and recreating it is faster than fixing it.
• Do you have an automated build/deployment pipeline? Why not try building one that deploys your code to a dedicated dev environment?

Once your team and managers see the fruits of your labors they will get excited and start making small changes themselves. Pretty soon the whole organization is riding the improvement wave. You’ll enjoy the job more. You’ll learn a ton. And with measurable improvements, you’ll have something to add to your resume or leverage for a raise in a performance review.