## The perks of reading other people's code

Tags: development improvement
Categories: None

## Three basic rules for reading someone else’s code:

3- Focus on read good code, and learn from it.

### 1.- Always work on your ability of reading someone else’s code.

This code might be messy, it certainly have different structure than yours, different rules, since it has been conceived form a different mindset.

The story
I remember I entered this in-progress project with friends, I was unemployed at the time and they gladly welcomed me to their team, so I can get a few extra dollars until my nex job.
The moment I started to fix bugs I entered into a process of investigation backwards starting from the interface:
1- The html template was using variables set in javascript.
2- Such js variables were set into their respective files.
3- Those variables were coming from Ajax requests, from an API endpo, so I had to look into the respective PHP controller file (The endpoint was written in MVC structure).
4- The controller file was using a model object, so I had to jump into such model class file, and so on…
You got the idea. Sometimes fixing a bug in the interface, requires to open an array of files that represents the sequence of the information flow.

The learning
When you’re reading someone else’s code, is like if you were doing cave diving, entering into the unknown, prone to coming across with either ugly traps, or beautiful landscapes.
In order to explore safely and sucessfully, you need to have a life rope, which you’ll stick into rock every few meters. This is your way out.
When reading that code, your rope can be list of files and the order they call each other. That list can be either in your mind or in a digital file, that’s up to your memory.
The point is that, no matter how messy or tricky the code is, you can always find your way out, if you follow a good process.

The story
I remember clearly this occasion I was very angry when reading bad code:
I was young, 25 y/o, (2007) and I was working with a .NET C# project, in which OOP and ORM philosophy was required. A new team member was added to the project. We asked him to build certain methods in some DB models to serve a set of services to the interface layer.
The day when he finished had come. I was the guy that was going to consume the class methods.
Long short story, I was expecting a static method among the set of requested methods, when I realized he built an instance method. In order to consume the method, I had to create an instance passing no ID to the constructor, to just call a generic method which could be called as a static one.
Obviously this guy had no idea of some OOP principles, and I was mad by realizing it right after he already spent time writing wrong code. His error had caused me a delay in my own tasks. Right away I started to rant about the guy in the office, saying to my coworkers how ignorant he was about OOP principles, and how much in time this was costing to the team.

The learning
I was being a douchebag. But at that time I didn’t know.
First of all, you have to understand that other people’s ugly code has nothing to do with you. You’re not a king to whom people should present their best work at. You’re not a holy soul, and ugly code should not hurt your vision.
There is and there always be ugly code around, even you will write it, a lot. Deal with it.
Your job is to write good code, and sometimes, fixing bad code.
Everytime you come across bad lines of code, is better that you fix them, in order to ensure neatness in your work environment. Think of the basecode of your project as your own house. This is where you live, where you spent most of your time, why should you allow it to be dirty ?
If finding dirt is an obstacle to you, then your reaction it’s a problem you should work on. Grow up, and move on. And even better, improve the situation.
I did.

### 3- Focus on read good code, and learn from it.

The story
I remember I called myself a senior javascript dev, just because I spent more than 5 years writing it.
I sniffed into the github repo, looking for some of the so-called high-end lines of code that these guys wrote.
Then I remember I stumbled upon something like this:

It happened that, when runAnotherThink was only called when x was true.
This was more audacious than just writing:

Why that guy was writing code like that ? At that point I didn’t know, but I learned something new by reading someone else’s code. Sure I did.
Next time I stumbled upon code like that I won’t be shocked.

The learning
Open Source code can teaches us a lot of things.
We can correct, improve, or modify our style by reading someone else’s code.
The style can be contagious.
Next time dare yourself to go into a strange code repository, or even a tool you use a lot: like some npm module. And wander within those lines. You’ll be impressed of how much you can learn of it.
If you’re reading stranger’s code, and suddenly you cannot understand the lines you have upfront, try to guess what it does, tweet it, ask a friend, ask a mentor, challenge yourself to understand something new to your naked eyes.

Did you liked this stuff ? send me a tweet @alexserver