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.
Top comments (11)
At work we live the scout principle. Leave the codebase in a better state than you found it.
This could be small things like formatting the code as of the current atandard but these things add up in the long run. And you really can embrace change. (Also acceptance tests are a wonderful way to gain confidence in the changes you make)
But deprecated runtimes years in the EOL are a warning sign that there is something wrong imho. That needs to be addressed on a management level and ressources have to be aquired to fix the issue.
We would all be in a happier place if everyone lived by the scout principle. Also, I completely agree with: "But deprecated runtimes years in the EOL are a warning sign that there is something wrong imho. That needs to be addressed on a management level and resources have to be acquired to fix the issue."
I think everyone sincerely does. Its just that many juniors (including me) should not have been allowed to commit for some time after they (I) were hired. Many of us (if not everyone) thought at some point that using syntatic sugar and ternary to make methods shorter is cool (like in hacker cool) - honest commitment to boyscout rule that results in a horrible codebase. I think in our industry we all thing of ourselves as unique artists with vision and dont like our code to be critisized. Of course this is only one of many problems in this disturbed industry )
How do you go about it in practice though? Do you include the refactorings in the feature branch you're working on, or do you commit them separately?
It depends on the change. But seperate commits is imho the go to. This way you can distinguish between the actual "issue" and the house cleaning. If you touch logic it may make sense for a seperate branch so a coworker can review it
I have a different POV, refactoring on its own is pointless. Its always a part of a feature. Cleanup of a code that is relevant to a feature you touched should not confuse your coworker. Refactoring of a feature that never gets a business requirement is pointless - its already good enough, as it doesnt require attention ))
We really do have a different point on view on that part. It's totally right that we are mostly hired to create business value.
And we should only do things that create business value. Getting more pace at the development process imho creates business value. If we talk legacy code it is not only about new features. If multiple contractors worked on a piece of software over multiple years things tend to have some ugly places. You could fight it with every bugfix or new feature again and again or you can make a difference.
And i git is a wonderful tool if you want to keep track of why something happend. And housekeeping and the work for an actual fix are two different things because you obfuscate your intent.
Imagine you're fixing a little bug. Let's say it took one line. Then because you're convinced that the code should be formatted as of current standards. You run a tool in your IDE and boom thousands of files reformatted (extreme case but gets my point accross). It get's really complicated to reason about the change and find the spot you actually changed.
At the end of the day it's about making your and the life of your coworkers easier. (More readability, safer code, etc). You are not obligated to do that and go the extra mile but in my opinion it is totally worth it.
reformatting the whole codebase is definitely not something that should be shipped with one-line bugfix. neither it is something one person should author (as an idea, not as commit’s author)))
so codebase re-formatting is super specific edge-case. In most of day-to-day situations, however, its possible to make small steps. so small that they could be embedded into feature PRs )
I agree, but working on legacy jQuery projects isn't really a transferrable skill. You'll be left in the dust if you spend too much time at a company hacking their legacy codebase. At some point you'll probably leave that company and have to invest a ton of time into catching up with the rest of the industry. Unless of course you're happy getting comfy at a big company with steaming pile of jQuery and coffee script.
I agree mostly, but do disagree a bit. The actual experience of jQuery may not be as transferrable, although learning solid JS principles, learning how to work on a team, how to take part in a code review and a lot of other skills are very transferrable. Additionally, if you are part of the work of upgrading the codebase, those skills I believe are very in demand: How to understand what another programmer wrote, how to refactor it meaningfully and efficiently, etc.
You'd be surprised at how many places outside of silicon valley/major tech hub cities are still heavily dependent on using classic templating (jsp/jsf style coding), asp.net razor templating, jquery based ui's etc. For example, tons of bootcamps focus on things like ruby on rails, react, vue, etc...however in many many places outside America, the number of companies you find using those sorts of tools drastically goes down. Not saying I like the situation...as i'm an avid fan of React and node, however saying "you'll be left in the dust" feels a tad hyperbolic.