A new codebase can be intimidating. In it lies the unknown. Bugs, spaghetti code, badly named variables, etc. During my trajectory as a developer, I've had to work on many codebases spanning multiple languages and technologies. Working on a new codebase used to make me a bit nervous. It's why I developed a system to turn those feelings into a net positive. In this post, I will share with you my system. Read on, it's pretty simple.
Stick to the basics
Every codebase is made up of data structures and algorithms. No matter the language. Everything revolves around those two things. By focusing on those two basic building blocks we can navigate our way around a codebase to gain insight and confidence.
Take notes of the data structures and break down the algorithms from the point of view of how those data structures flow through the program. Use comments, breakpoints, and print statements to document the flow of data.
One common gotcha of really awful codebases (commonly written in PHP and Java for some reason...) is that the data structures are defined as database tables. Keep this in mind when you are looking for the basics. Make sure to check stored procedures as well. 😉
Build on past success
Impostor syndrome tends to hit extra hard when we start working on a new codebase. It's absolutely normal to feel like that because new codebases bring new challenges we haven't faced before.
The way to attack this head on is to look back into our past success. Think about past work you've done on other codebases. Work that made the client (company) happy. Think back to how at the start of that same project you felt similar to how you feel now. You succeeded in spite of those feelings.
Start the race from the finish line
What does the end product look like? What do you have to deliver? This is not about specifications. This is about the actual finished product. What is it?
Define the end product in extreme detail. Fixing some weird crash on Android? Then define what the end product will be without the crashing.
Figure out your interfaces. What will your fix look like from the outside? Maybe the crash is related to a memory leak. Your interfaces must then revolve around avoiding memory leaks.
Hook your interfaces into the codebase. Make them pass through. Meaning that you are calling an interface that does nothing. Then dig into whatever data is flowing through.
Add your code to the interfaces. At this point, you are done looking for the problem and implementing a solution.
Take time off and rest
Tired developers cannot be effective developers. Taking some time off when working on a new codebase will allow you to ease into it rather than jump. It's better to enter the ocean through a nice warm beach than to jump from a cruise ship.
Happy coding!
Top comments (2)
I used to get really caught up with the size of things, like a database with 100,000 rows and how big that was. I developed the philosophy of telling myself that the "bigness" of a number is completely psychological and there might be someone at Google who looks at 100,000 things and it seems like an incredibly tiny thing.
That's a really good point. In the end, it's just ones and zeroes.