There can exist a chasm between what you learn in bootcamp and what you will work on in your career. In bootcamp you might have spent your educational time studying the latest and greatest in languages and frameworks. You are ready to implement code that follows a strict separation of concerns. You want to keep your applications DRY and your APIs RESTful.

Then, you start your new job and you encounter a real production codebase.

If you enter a position at a well established company you will encounter software that has been worked on for years. It has gone through refactoring multiple times. It has been contributed to by numerous people. If you enter an engineering team at a non-tech company, chances are time and resources (or just business decisions) did not allow for solid TDD principles to take root. People may have contributed code in various formatting and you may be hard pressed to find consistency across the code base.

You prepared for Python and you discover you are working on a deprecated version of PHP. You were excited about React and find yourself writing a lot of jQuery. How do you approach this reality? Is this just something you have to deal with? A necessary evil to entering the industry? Do you count the days until you can find a position working with the latest and greatest?

I'm here to offer the counter-intuitive idea that this opportunity is a fantastic one!

Why can this be a great opportunity?

• There Is No "i" In Coding

Okay, yes, there is an "i" in coding.

But, my point still stands. Whether you are working on a project all by yourself or part of a team, you are utilizing code written by others and you are contributing back to that process. Those Node packages you always turn to? How about those Ruby gems you can't seem to live without? Those were written by other people and worked on by lots and lots of others.

Programming means being a part of the global community of people writing code. Getting the opportunity to join a professional team with a codebase that has been worked on by many other individuals gives you the chance to actively join that community. That is an invaluable experience. The more legacy the codebase, the more people who have worked on it, the larger the community of people you will be joining.

• Legacy != Bad

We can get accustomed to writing code that has a very short lifespan. There is nothing inherently wrong with that. In fact, in many cases that makes a lot of sense. Things change fast in our world and our code needs to adapt. Yet, there is something disruptive when we encounter legacy code. It swims upstream against a current of constant change. It reminds us that there are things, even in our industry, that can have a lasting impact. We see legacy code for its downsides: clunky, outdated, buggy. We can also see legacy code for its upsides: practical, enduring, resilient.

If you knew you were writing code that would still be around 3, 5 or 10 years from now, what would you do differently? That is the question legacy code calls on us to think about.

• Writing Code Is Only Half The Battle

There is one skillset that involves writing fresh code. This includes the ability to map out a problem, conceive of a possible path to solve it and execute on that path. There is another skillset that involves editing existing code. They are not the same thing.

In fact, I would argue, the latter can be more challenging than the former. The latter requires you to step into the mindset of the other programmer. You need to adopt their frame of reference and their viewpoint before you can actually touch it. Why did she choose to address that problem in that way? Why not one of the other possible paths? What can be done to improve upon the solution already implemented?

We can spend 1 hour writing code and 10 hours perfecting it. Joining a team with a large legacy codebase gives you that opportunity in abundance. It's an opportunity to exercise a part of the coding brain muscle that can always benefit from more of a workout. We'll be better programmers because of it.

In short, legacy ought not always automatically equate to dread. If you are working on a legacy codebase embrace the opportunities it provides. You might be surprised what benefits it will yield for you now and in the future.