These days I don’t have much problems reading other people’s code. I’ve seen so much bad code, that I can even diagnose what sort of evolution led to any I find.

More often than not, professionally bad code is code that started out okay, but best practices, requirements, or skillsets moved out from underneath it. Sometimes it is just someone who is bad or new to the language, but that’s pretty apparent too (and uncommon in a professional setting). The more I understand why code rots, the less I question the competence of other programmers.

This may be the result of this development process.

In the last 2 years I have working with other people code. I have debugged it, fixed bugs and made improvements. In my experience I usually think that the code is bad, full of bugs, slow, consumes much more memory than needed, used programming concepts inappropriately, really bad formatted (this is hard to live with), not commented and the logic flow is a mess. What if I tell you that I found one function with 5k lines of code?

So in my experience I usually question the quality of code. If something is hard to understand, because it is complex, it make sense after you understand it. But if it is just bad it will always be bad.

Short Answer: Mostly we don’t like it or get very critical on why coding is done this way, and not the other way around. However, more you read other’s bad code, faster you appreciate well written code 🙂

Although it may sound obvious but the best way to get better at reading people’s code is: by reading people’s code. The problem is that when people typically read other people’s code they don’t try to “grok” it, i.e. become intimately familiar with it; they do the equivalent of speed-reading poetry.

To grok someone else’s code you may try the following:

• Refactoring the code.
• Choosing a feature to add that requires going into the depths of the code.
• Writing comprehensive unit tests for the code.

All of these steps will force you to read the code in greater depth.

There are also some tips how to maximize the understanding of a code-base, that you have been introduce for maintenance and support:

Once you have a basic idea of what’s going on, you may want to take a good look at the data storage (the persistence layer). That’s another great way to get an understanding of what’s happening, but make sure the things you are studying are actually in use. I can remember a few times really getting to the bottom of some classes with this approach, thinking I’ve understood the system – and then realizing later the classes weren’t used at all.

It may seem like a daunting task – it does take time and no fancy tools can remove the need for intelligence – but it can also be very rewarding. As you go, you will probably find a lot of bugs in corner/edge cases, and see ways to improve the code. One piece of advice – don’t go too heavy on refactoring / changing until you have a good understanding of the code. Often what looks like a mistake or just plain bad code when you first see it, turns out to be subtle genius at work upon later, enlightened investigation. Also, removing unused code is so satisfying, and great for any future maintainers. Of cource, with the assumption that all code base is version controlled.