The Art of Efficient Programming: Why You Shouldn't Memorize Codebase and What to Do Instead

Yeah. It’s the one thing engineers hate the most. Documentation. It’s my Achilles heel. My Kryptonite. The chink in my armour. My soft underbelly. Well, you get the point.

The Art of Efficient Programming: Why You Shouldn't Memorize Codebase and What to Do Instead
Photo by David Matos / Unsplash

Starting a new codebase is easy when doing it alone. You may have planned what you wanted to do and written it in codes. Everything is in place. It could be easy, at this point to remember where things should be and how they would work. You probably can memorize which functions are at which lines in your codes

Then it grew larger and more complex than the original. When push come to shove, you had to increase headcounts for your project, adding another variable to the changes in your codebase. It then becomes increasingly difficult to keep track of everything in your head.

As the codebase grows, it becomes increasingly difficult to keep track of everything in your head. Trying to remember everything can lead to cognitive overload and information retention problems.

Instead, it's much more efficient to utilize documentation, code review systems, version control systems, and other strategies to help you keep track of changes in your codebase.

Document. Document.

Yeah. It’s the one thing engineers hate the most. Documentation. It’s my Achilles heel. My Kryptonite. The chink in my armour. My soft underbelly. Well, you get the point.

Yet, it’s one of the most important processes for a developer. It helps since you can now easily keep track of the changes made to your codebase. It will allow you to locate any issues that arise and make necessary changes to your codebase. Other programmers and stakeholders would benefit from this too! Anyone that reads would be able to understand what the code does, how it works and how it can be modified or improved over time.

Here are some ways you can start if you’ve never done it before.

  1. Choose your tools: If you’re starting out, Github wiki, Google Docs or Notion would be sufficient enough for documentation.
  2. Pick your poison: What would you rather do first? Decide on what type of documentation you’d create such as code comments, API documentation, user manuals or even a more verbose PR/commits.
  3. Decide on how detailed it should be: Depending on the stage of the development process you can start small when you’re the only person working on it and increase the details when other stakeholders join in. The best part is, you won’t be working on it alone. If it is something that you’d have to share with the public, it’s best if it’s as detailed as possible for the end users.
  4. Update, review and maintain: As your codebase grows, so should the changes to the documentation. It’s important to have up-to-date and accurate documentation to be useful for the readers. Regularly review them to spot any inaccuracies and maintain them.

Use an automated code review system

Identify errors, track changes and roll back if necessary. These are some of the features included in an automated code review system and here is why it is important when you do not want to memorise your codes.

  1. It helps to reduce the cognitive load that usually happens in a manual code review. Not only a manual code review is time-consuming, but it is also a mentally exhausting process, especially for large and complex codebases. Automating the process of identifying common coding errors, raising security vulnerabilities and violations of best practices reduces your mental load.
  2. If your organization has a standard/opinion on what a good/bad code means then the system would provide consistency and an objective approach to code review. Leaving one less thing to worry about as the system can block/raise errors during development.

Tools like ESLint, RuboCop, and PHPStan are some that I’ve used before.

Take frequent breaks

I’ve probably mentioned this in my previous article but I need to remind you again to take frequent breaks. It’s important to help prevent cognitive overload and information retention problems. It’s easy to get lost in your work and forget to take a break.

Taking a step back every once in a while can help you stay focused and refreshed. Grab a cup of coffee, stare at the ceiling while listening to some lo-fi music or take a walk. When I do this, sometimes I come back to the problems at hand with a new perspective. I’d also make fewer mistakes and keep myself productive.

Review and refactor existing code

Remember that one time you created a mess of a spaghetti code?

Did you hate yourself when you can’t understand why you did it that way?

Well here’s the thing just for you: Refactoring!

See if you can identify any unnecessary complex code in the codebase with the intent to optimize or improve the codebase. This may include simplifying complex functions, removing redundant codes or improving the readability of your code.

It’ll help the future you figure out how it works. It also helps to improve the quality of your code, reduce technical debt and make it easier to maintain in the long run. Don’t forget to update your documentation when you do this 😉

Seek advice from peers and experts

If you're struggling with a particularly challenging problem, seek advice from your peers and seniors. When you ask someone who has more context on how the code works, you can gain valuable insights into how to approach the problem. Collaborating with others can be a great way to solve problems and learn new skills.

“[I do not] carry such information in my mind since it is readily available in books.

Albert Einstein

When readable codes are in place and things are documented properly, there's no need to memorise your codes. It frees up your mental load to think and solve other problems that come your way.


Don't miss out on more valuable tips like this! Hit the subscribe button to sign up for my newsletter today. It's quick and easy, just click the link below!


Subscribe to mnorhamizan

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe