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.
Ben Orenstein's Refactoring Rails course is a great place to start. It's got a bunch of good refactoring techniques that you can use every day.
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.
Top comments (15)
Thanks for sharing such an impactful story! I agree that a good refactoring is so rewarding! I like to try to set my projects up for easy refactoring as much as I can. In the beginning everything may be in one file, but settings are stored in a data structure that lends itself to being pulled into a settings file or a database, not haedcoded in. Functions are small manageable pieces with sane default inputs. Code smells such as data clumps are avoided as much as possible, or are setup for annexit strategy if certain things grow legs.
It's important to not necessarily start out with the final draft, because it's common to make the wrong call. Things become too abstract and hard to follow. Too many separate functions with things put in odd places make them hard to find. It's much easier to see the logical architecture after getting started for awhile.
💯
Crazy this is almost exactly how my current internship is going
Same.
I hear what you say and sympathize.
At the same time many mature projects come with technical debt. One project I started working with had almost a million lines of code and no comments when I joined almost 15 years ago. At that point the project was maybe 5 years old and already had technical debt. But the project is still alive today and the codebase is 20 years old.
However, experience in the field has taught me that most mature projects have this and that you just have to deal with what you get.
I made a bit of a name of myself in this project when (during the first months) I was able to refactor a major component of the software and make it much cleaner and more understandable. It was no easy feat but made the code much better. I later went on to rewrite another feature (improving it at the same time) and allowing them to remove several thousand lines of code. The lead programmers even accepted my radical changes because they were compelling enough.
However, I've also learned that a lot of refactoring means that you spend less time making new features that will make you competitive in the marketplace so we need to take care where we're spending our resources. Many companies went broke doing this. Some famous cases come to mind like WordPerfect and Netscape which engaged in full rewrites.
Architectural Erosion is often a fact of life in large projects with many developers coming and going. So as new programmers we need to learn how to fit in and contribute. That is not always easy, especially if everyone is terrified to touch anything, but its a fact of life in mature products.
Been thinking about this, if code needs weeks of handover and the lead dev still feel they can't relquinsh control of the code base is this a reflection on the developer's drive to lead, lack of trust of the rest of their colleagues (who are all proven developers), or a sign the code base has far too much tech debt in it?
Man, what a great read! Love the expression technical debt! It makes sense. I like to start off with concepts that make sense and branch off into some dependency. For me, it helps me understand how scalable my code really is. Not to say, I don't go back and refactor :-)
That was my experience too. I started ny career as software engineer at Ericsson.
It was super exciting at the beginning. Maybe in 4/5 months the sad reality comes true.
Old tool, old people, old software, bad processes...
I left Ericsson two years later starting my own company that build developer tools to solve the problems I experienced in my previous experiences.
In some way it was tough but useful for my life.
I remember working there with you and totally agree that custom Perl ORM/Web framework monolith we used had a lot of issues. At least it was good impactful work. Hope you're well!
James! Long time no chat! I'm doing fantastic. We should definitely catch up sometime.
It sure had a lot of issues, but it was incredibly important at the same time. Just makes me imagine what could be done with good code and impactful work.
Ya for sure I'll let you know if I'm in your area. I'm traveling more with a solar camper van I built.
One of my previous lives I worked for a national loyalty company steeped in a decade of tech debt. Someone quit every fortnight, to the point where people purchased stamps or stickers for all the leaving cards.
For a solid year they worked to phase off of old tech and promised to never return to the days of so much tech debt.
However they had cheaped out on the new stuff and most of the platform never passed the MVP stage before it started to crumble.
New management changed all of our contracts to reflect that we would support MVP systems.
They still have super high attrition and most of their projects are in development hell.
This is literally the reason why I quit my job. Only one person other cares about it and he ended up redoing our flagship product without all the garbage and debt so that we'd have an actual product.
THANKS!