by Chris Oliver
Founder, GoRails.com
When I got my first full-time development job, I thought things were going to be great. I thought I’d learn all kinds of things, see how a real development team worked, and that I’d be building cool features to help our users.
Boy, was I wrong.
You see, my first job was a huge mess of technical debt. The team assigned me tickets in hopes of me quickly learning how their day-to-day went.
A ticket would come in asking for a bug fix and I would ask a coworker for some help to send me in the right direction.
What usually happened was the coworker would ask another couple people and then we’d find out that the code probably couldn’t be changed easily without breaking other people’s needs and we’d just have to close the ticket without actually resolving it.
One example I remember vividly was a ticket that came in asking for a small change. My coworker was like “wait, someone is still using X feature? We could rewrite this in 4 lines with our new code we’ve been working on.”
I was thinking to myself “Fantastic! We can refactor this old code and we’ll have cleaned up a 400+ line of code script and replaced it with 4. Maybe they are making progress here!”
Nope.
After a few minutes of chatting with him, the conclusion was it was too risky to actually replace the 400 lines because there was a chance it could break things.
I was pretty disappointed.
Needless to say, I didn’t last long at that job. The sheer amount of technical debt made me feel like I couldn’t contribute to anything as a junior developer. To be successful there, you had to have years of knowledge to actually get anywhere and even if you wanted to clean something up, you’d get shot down for fear of breaking something.
This experience stuck with me ever since.
I never want to write code that couldn’t easily be changed like that.
Technical debt is something that creeps up on you. It takes diligence to go through and routinely clean up your code.
Writing code is like writing an essay.
You start out with a rough direction you want to go and slowly start to make it work. The exact details become more apparent the further you get along.
In school, we’re taught to never use our first draft. We should write it once, read our work, and then write a second draft that emphasizes our points better.
That’s exactly what refactoring is. It helps your code reach a level of clarity that you can’t get the first time around.
If you’ve got a lot of technical debt, good news! You don’t have to quit your job like I did.
Part of what made that job so hard was they never refactored code properly… or at all from what I could tell. The requirements were in people’s heads, not in the code, and not in tests.
Refactoring code is some of the most enjoyable work that I do today.
I love writing code to add a feature and then refactoring it so it’s cleaner, simpler, and often times can do more than my original draft.
Refactoring is easier said than done, however. It takes time to learn different patterns that can help clean up code and make it easier for future development.
As long as you keep these techniques in the back of your mind, they can help you every single day when you’re writing code. That’s the great part of refactoring.
Chris Oliver is a Ruby on Rails master programmer, and one of the generous sponsors of Break Diving’s coding team. If you want to learn more about refactoring rails apps, he recommends Ben Orenstein’s Refactoring Rails course as a great place to start. It’s got a bunch of good refactoring techniques that you can use every day. You can also learn more about Rails at Chris’ awesome video tutorial site, GoRails. — a site that regularly helps the Break Diving coding team stay on top of its game.
Break Diving, Inc. is a tax-exempt 501(c)(3) charitable organization.
Read all about our amazing mission at www.BreakDiving.org
Join our free community at www.breakdiving.io
Like what we do? Please make a feel-good donation!
Remember to tell your friends about this www.BreakDiving.blog
Photo by JESHOOTS.COM on Unsplash