One Trick to Move Faster as A Software Engineer
There’s one “trick” that I’ve been practicing over the past 3 years. Every time I start work on a new project, the very first thing that I do when it comes to code—before anything else—is to clean up code in the area that I’ll be working in for this project.
I will usually spend as long as it takes to do this. It may be 2 hours, it may be a week. All in all, it is a requirement for me. And it’s counterintuitive because it feels like this would waste time. The time it takes to refactor a bunch of code that people wrote ages ago could, in theory, be used to actually do the project you’re supposed to do in the first place. However, in my experience, it has helped me move faster, and I will tell you why.
But first, why should you listen to me?
Plain and simple, I’m a senior software engineer at one of the big tech companies, and I made it to that position in roughly 2 years since I graduated from college. I’m not going to lie to you: I had pretty strong imposter syndrome when I was promoted back to back from L3 to L4 in one year and from L4 to L5 also in one year, but over the past year (a full year being an L5), I feel confident to say that I am a senior software engineer.
Maybe I will write a longer blog post about how I got there, but that’s a story for another day.
the only constant in software engineering is that the code is always changing
Clean code before you write code
This is my principle. When you work on a large codebase—ours is literally millions if not billions of files—you simply cannot understand how everything works. Over time, you get an understanding of the different layers, but there’s no way you can understand every single systems.
However, when you are set to work on a new project, it often happens in parts of the codebase that you’ve never worked in before, and it’s a mistake to not try to understand what that codebase is doing before you add your own code on top it.
Of course, reading the code in and out can help, but in my experience, that usually isn’t enough to actually understand what the code is doing. When you simply read, you will tend to skim through key details.
Instead, one effective way to do understand the code that has worked for me is to clean up the code.
There is always something to clean up
If you think that there isn’t anything to clean up, then look again. There is always something. I can’t remember which book I read this from (it was one of those popular book, either Design Pattern by the Gang of Four, or Refactoring by Martin Fowler), but the only constant in software engineering is that the code is always changing. Therefore, stuff someone wrote anytime in the past is likely outdated.
When you refactor the code, you “dip your toes” into it
It has been my experience that I get a much deeper understanding of the code after I go in and change it in small ways. That’s because when you refactor the code, you now have an added task/challenge: while you got there in order to understand it, now you have to make sure that your changes don’t break it.
This adds just enough mental overhead for you to know what it’s doing. Often, it might even feel like you wrote the code yourself. In a way, the difference between just reading the code and actually refactoring it is like looking at the ocean vs. dipping your toes in it.
Refactoring requires understand outer-context
Most often, when you are working on a “smaller” scale project, most of the changes that you need to make will happen in 1–3 files at best. However, when you refactor the code, you often need to look at the callers of the functions in the file that you’re currently looking at. This means looking at every other file that uses the files that you’re trying to change to finish your project. By doing that, you understand the outer-context of the file: things like what its clients expect from it.
Refactoring and cleaning up code makes you a better software engineer faster
Wherever you’re working, there likely are many experts who wrote the code you’re now about to edit. If you’re lucky, you would be reading one of these experts’ code and learn from what they do. In software engineering, there are just some subtle things that you have to take into account.
For instance, I recently decided to leave code duplicate as is—to not refactor the code. In a vacuum, this would be considered dumb or foolish; however, I weighed the pros and cons of combining the code and realized that removing the code duplication would actually lead to much more complexity down the line (since one part of the duplicated code is actually going to change and merging them would lead to creating branching decision in the merged code). This is the type of nuances that you learn over time.
If you’re unlucky, you may end up in plain bad code, in which case it’s still a great opportunity to learn. Bad code is often ripe for the use of design patterns to solve the problems. The ones that I have encountered countless times, in order of high-to-low frequency, are the Factory Method, Abstract Factory, and Strategy, but I’ve probably seen them all in our codebase (either seeing the design pattern implemented or seeing bad code that can be solved using any one of the many design patterns). Cleaning up code can give you the opportunity to learn these design patterns which eventually help you become a much better software engineer.
As a whole, you get ready to actually solve your problem
After doing all of that refactoring and learning all of this information, you get a much better understanding of how to solve the problem you came here to solve in the first place. If you tried to solve it head on without understanding the code, you end up having to learn little pieces of key information here and there that slow you down and force you to change your original approach.
Instead, when you truly understand what the code is doing—which you do by first cleaning it up and refactoring it, you end up becoming a subject matter expert in that little area and you figure out exactly what you need to solve the problem you came to solve. You are thus empowered to move fast because you’ve gathered all the key information while you refactored.
Conclusion
There just isn’t enough opportunity to learn if all you’re doing is solving the project at hand. You have to always be learning in order to succeed at doing this, and one effective way to do so is to clean up the code. The best time I’ve found to clean up the code is to do it right before a project, and it does save time in the end! So put your gloves on and start cleaning :)
