Are you working on the greenfield code that you always dreamed of?...
I didn’t think so… me neither.
”…nope, I’ve got a legacy codebase with nothing but 700-line methods, inconsistent formatting, raw code duplication, no comments, no documentation, hundreds of stored procedures, and no tests…“
You don’t enjoy it, it’s not enjoyable. It’s not why you got into programming. It’s not how you envisioned programming as a career.
What are your options?
- Try to get another job?
- Stay where you are?
- Go back to school?
- Try freelancing?
Working with shitty code can be an obstacle. In our minds, it’s keeping us from writing the beautiful code that we were destined to write. It’s keeping us from reaching the top of Hacker News tomorrow. It’s keeping us from saying “I can’t wait to get to the office and start changing the world…”
The truth - we are the obstacles. We know we can write the beautiful code we’re destined to write. We know it’s possible to find something good to say about this code after we’re done with it.
The only difference between a greenfield and legacy project is what we’re starting with. It’s what we do from that starting point that’s important. It’s not the code that keeps us from achieving greatness with it. It’s our perception that we can’t do anything great with shitty code.
We can change our perception of this coding situation and embrace the obstacle. We can perceive it as an opportunity to show everyone how resilient we are.
“There is no good or bad without us, there is only perception. There is the event itself and the story we tell ourselves about what it means” - Ryan Holiday The Obstacle is the Way
What can we do to change our perception of our shitty codebases?
Write tests. I know what you’re thinking - it’s not that easy. Worse, your boss may not let you. Write them anyway. Your boss can ask you to make 1 of 4 changes to the code: bug, feature, refactor, optimize. Fix the bug, but write your own tests. Don’t commit them if you aren’t allowed to, just use them to get your task done.
Summary
Testing is a ubiquitous skill that will help you advance your career. It’s also a place where you can write beautiful, greenfield code in your own sandbox.
We can still advance our careers and write beautiful code when we are handed ugly, legacy projects. Writing tests is a good way to change your perception and start shipping your best code - even when the odds are stacked against you.
Make sure you check out my new ebook: Intuitive Testing with Legacy Code for a plethora of deep-dives into this topic. Sign up for my newsletter for a free chapter!
Related Posts:
- What’s better: bad tests or no tests at all?…
- Cracking open a legacy code ‘black box’…
- Debugging all the time isn’t fun…
- New to Testing Time-Dependent Code?… Use NodaTime.Testing!
- Converting DateTimes by Offsets with NodaTime
- Intuitive Testing with Legacy Code
- How to Compare Object Instances in your Unit Tests Quickly and Easily
- Should You Jump into Unit Testing before OOP?
- How Working the ‘Vertical Slice’ Can Fix your Coding Mental Block
- Using TDD to Break Through ‘Paralysis by Analysis’
- Do I Really Have to Unit Test This Method?