‘Code is the ultimate truth’, he responded, when I asked my colleague, ‘What about knowledge transfer?’. This ‘Code is ultimate truth’ was the zen statement. My colleague (and friend) was about to leave a company, and I was supposed to get all the knowledge transfer for the project we both were working on and I was slightly worried about how I will be able to manage huge lines of code. This incident happened long back (around 4 or 5 years), but not only I remember this, but It curved on my memory like ten commandments on stone. Since then it helped me to concur the Damon of bugs or uncertainty or behavior in code.

Let me explain this zen statement. No documentation can cover 100 percent of what code is all about and how it will behave except the code itself. Assume that even if we have a document, with the change in few lines of code, the document becomes obsolete. The moment we update/change the code, it is also necessory to update the document as othewise, document will be obsolete.

In scenarios (which is common) that on the same source code, there are multiple authors (developers) contributing simultaneously, it becomes even more difficult. If there is discipline maintained about putting markup based comments which later used to create the document, then documentation is possible to some extent, but still, it is practice that depends on developer to follow, and if it is being skipped just for quick delivery then again document will become old. Also, any kind of documentation for code addresses abstract level information and don’t display the detail which developer really interested. So, for a developer, the code is only source and best document to get control over the code in order to fix the bug, extend the functionality, inject the feature, refactor existing piece, etc. Only code tells best what it does, how it behaves, when it crashes and when it is executed as expected. Even in systems where the code is not only responsible for performing tasks (unlike software developed at the application layer) like embedded systems, where a written code is meant to behave as per external trigger or send a signal to external hardware, code behaves exactly the way it is written. With the advancement of technology, now there is minimum room for compilers to generate executables that differ in behavior from what sources say.

So the point is - as soon as any developer understands the code, he/she can start contributing. If a developer has good control over the code, he don’t have to depend on documentation. But how as a developer I can get good control over the code? Specially when the code is being written by someone else.

There are many steps to get it but the first step for any developer is to READ the code. It will look trivial for the reader and some may find it as joke but what I have learned from experience and from other senior seasoned engineers is that - ‘ability to read the code’ is one of the primary requirements to become a good developer. It is like skill of reading book where writer is another person, he/she may be good or bad writer, but as a reader, we have to understand what he/she means to say. Sometimes, author is so good that we get it at first, sometimes it is like reading the same para multiple times to understand it. It may also happen that reader is not used to read a book, and in that case, he/she finds it difficult to understand the book. So either you are reader or developer in order to understand what author or developer has written, you have to read it.

So here are points -

• If you want to become a good developer, read other good developer’s code.
• If you want to learn the problems in code, read other developer’s code which contains code smell.
• If you want to learn the logic, read the other’s code.
• If you want to learn how other developer thinks, read the code of developer.
• If you want to solve the bug in the code, read the code.
• If you want to extend the functionality in existing code, read the code.
• If you want to refactor the existing code, read the code how it behaves.

Sometimes It happens that code is complex or maybe it is not written in a way that you used to read/write it, In this case, you may have to read the code multiple times. And it is okay to read it multiple times to understand it, even senior developers do it - only things is that they may grasp it faster as they may have passed through many different types of the codebase. And that is the key - if you cover different kind of code-base; your ability to read the code increases.

Here is hint - Remember when you started reading books? You started with a comic book and as you progressed, you reached to the stage of reading the novels of multiple volumes with complex themes and writing styles. In the case of novels, there may be only one or two authors, even then it may have a complex plot and writings. So, in the case of code - there are many authors who have contributed, so how it will be an easy walk for other developers to read it fast? Even after setting up development standards (like coding style, convention, coding standards, code review), it can be a fairly complex case of reading code.

But don’t afraid, keep reading it, keep repeating it until you understand it. Ultimately, ‘code is the ultimate truth’, it tells what is written therein code and not what document may be saying!