7 tips to crush a large existing code base
Making more money as a developer requires maintaining productivity despite challenges.
Working with existing code is difficult.
But…
Productive developers can quickly analyze and work with existing code
True, some code is too broken to revive.
But, over the years, I’ve learned 7 tricks to boost productivity with existing code bases.
#1: Add documentation as you learn the code
Don’t waste time complaining about a lack of documentation.
Yes. Most code is poorly documented. But complaining changes nothing.
Instead of complaining…
Add comments as you learn the codebase.
Adding comments:
- Can quickly improve documentation.
- Organizes your thoughts as you learn new areas of the system.
- Boosts your memory retention and productivity when you go back to that section of code.
#2: After learning new code, add comments immediately
You’ll be surprised how fast you forget things you learn about a codebase.
Why wait to capture what you learn?
I hear developers say, “I’ll go back and add comments later.”
Sure you will…
Life is too busy. You’ll never go back and add meaningful comments.
If you do go back, your comments will be perfunctory.
The original frustration is gone. Your brain forgets the smaller details. Your delayed comments will be vague, general, less helpful.
If you never go back and add comments, then six months later you’ll be back in that same code again, and you’ll realize you’ve forgotten most of it.
Re-learning the same code twice is a waste of time.
Wasted time equals low productivity. Lower productivity equals lower income over the long-term.
Instead of delaying and hurting yourself, add comments to existing code as soon as you learn it.
#3: Maintain a private, personal knowledge base
Sometimes adding a comment isn’t possible or doesn’t fit. For example, maybe you learned about a whole new technology platform.
For knowledge that doesn’t fit in code comments, maintain a set of text files organized in a private knowledge base.
Use folders to organize sub-sets of knowledge.
As you learn how to do things, like build the code base, deploy it, attach a debugger, change settings, etc. document these steps in your knowledge base.
The advantage of keeping your knowledge base private is you’ll feel less pressure to make it polished.
Sometimes we don’t write documentation because we feel pressure to make it polished. It might feel less embarrassing to do nothing.
That’s why having a private knowledgebase can help make you more likely to do it.
#4: Learn the underlying technologies rather than tunnel-visioning for quick solutions
I’m shocked when developers get stuck fixing a problem, but hesitate to study the underlying technology.
For example, a developer needs to solve a null-reference exception thrown when calling an unfamiliar API.
So, he starts to Google how other developers solved similar problems with the API.
He hopes for a quick copy-paste solution, or an easy step-by-step guide.
Unfortunately, that doesn’t work.
Then, he starts setting breakpoints. Trying to switch to different, but similar endpoints on the API, etc.
The developer wastes hours — even days. But, he never stops to ask, “Have I read the Startup Guide and Technical Reference for this API?”
Often, you can save time by pausing and reading available documentation for dependencies
When you’re under pressure, pausing to study might feel like wasted time.
An ongoing log-grade delay might feel more productive than a complete pause to study.
But if you don’t understand the underlying technologies, you’re wasting small amounts of time every day.
Over time this starts to add up. It ruins your productivity and your quality of life.
Also, when you have a hazy understanding of what your dependencies do, you have more anxiety.
And when you have anxiety your productivity struggles.
In my experience, it’s better to take the day or two to learn an underlying technology.
True, you lose time up front.
But your joy and long-term productivity increase dramatically.
Each time you come across a new technology in the existing code base, you may need to repeat the exercise. But it’s worth it.
#5: Invest in quality tools
It’s amusing. Developers are some of the best paid employees in the world. And we make software…
Yet, we HATE paying for software…. Why is that? I have no idea.
When it comes to software tools that can boost your productivity, don’t make this mistake.
When you start working on a new code base, there may be tools you can buy to make it easier to:
- Navigate the code
- Debug the code
- Lint the code
- Etc…
SPEND THE MONEY! Either you buy it, you get your customer to buy it, or you get your company to buy it. (It’s usually tax deductible for somebody!)
If you’re making $50 to $100+ per hour, paying $100, $500, even $1,000 to boost your productivity is nothing.
Being productive leads to faster pay raises and greater job security. This is true whether you’re an employee or self-employed.
I’ve found that you more than make back the money you spend.
#6: Don’t be afraid to print and use a pen to hand-annotate code
As programmers, our work is digital.
Sometimes we forget that pen and paper is still useful!
For example, if you print a complex piece of code, you can spread it all out on a table and see many pages (hundreds of lines) at once.
On paper, you can:
- Circle areas
- Draw lines to connect pieces of code
- Underline
- Highlight with different colors
- Write notes in the margins
Also, hand-written notes stand out easier on paper.
And you can always flip back and forth from your paper copies to your digital copies in your IDE.
Remember, just because we code on a computer doesn’t mean we can’t use paper any more!!!
#7: Draw flowcharts, dependency graphs, and diagrams (especially sequence diagrams)
As you start to understand a large code base, visual representations are faster to refer to than lines of code.
For example, if 7 or 8 methods coordinate to accomplish a task, you’ll be happy if you diagram it as you learn it.
Creating diagrams helps you grok the flow & dependencies faster.
Also, your diagrams become visual documentation you can refer to whenever revisiting that code flow.
Either on paper, or using a diagramming tool, build visual diagrams that describe the flow of code
Sequence diagrams are one of my favorite types of diagram.
But basic flowcharts are great as well.
Bonus tip: If you use paper to draw diagrams or take notes, take pictures with your cell phone and save the pictures in your personal knowledge base.
These are just some of my tricks for successfully tackling a large pre-existing code base!
I hope these help you!
What tricks did I miss?
I love learning from other successful developers!
Are there tricks you use to work with existing code bases?
If so, please let me know in the comments!
