What Makes Good Code? (1/7)
Introduction
I had a job interview and was asked the question in the title. I had the impression that it was the most pivotal question for them not hiring me. I confess that my answer was not convincing, but their feedback was that I did not have the skills for the job. Now, I have this thought that haunts me: do I not have the skills to make good code or do I not have the ability to express it or both? I believe it traumatized me, because I got stuck rehearsing the situation in a loop thinking of what I could have done to make things different. One of the things that I would add to my answer is that the question was too vague and that I could write an article about it and it would be hard for me to summarize it in a few minutes. So, I am writing this article in seven parts to get that out of my head and maybe you could learn a thing or two about how to make good code.
I started coding when I was a teenager, making small games and toy apps in Delphi. At that time, good code was simply code that worked. It was a good standard for me, and it is still valid, good code is code that works. I was working by myself; nobody was reading my code and the projects were small. Then, I got involved in Web Development, making dynamic sites and they grew gradually. I noticed that some decisions impact on how long it takes to fix a bug or to add new features. So far, all my knowledge has come from experience, a couple of books and internet forums from the early 2000’s. One important tip that I learned was “don’t repeat yourself”. When you are learning to code, you just want to see things working and then play with the code to make sense of what is happening. You can get used to the habit of copy and paste code. This leads to a lot of problems, including that whenever you change something in a part of your code that is repeated you must remember to update in all copies.
My first professional experience was in a software department that had systems designed around Oracle databases and Oracle Forms as the front-end. They spent a lot of effort to deploy the executable files and making Web Systems was the natural evolution. So, they hired a bunch of interns (me included) to make those web versions. I inherited an almost ready to publish system. The system was working, but basically it was a single file! The same file had authentication, request flow control, database connection, business logic and front-end code. It was before the concept of WEB 2.0 had spread, so Ajax requests were the new and promising way to build interactive sites. It made everything worse, a single file with PHP, HTML and JavaScript code in it. The programmer who was leaving the project told me that it was easier to find stuff when everything is within a single file. Despite being surprised with that statement, in a way, I could relate to that. It took me back to the early days of making small games in Delphi. Then, I realized that there is a difference between writing code for yourself and for other people to use. So, a good code is readable. A book has pages index, layout, chapters, side notes just to make it easier to be read. Your code needs other elements with that purpose. There are many elements in this topic, I will come back to it later.
I think all these concepts that make good code are broad concepts that can be applied to anything in your life. Good code is code that works could translate to “something in your life is working, then this thing is a good thing”. “Don’t repeat yourself” is also related: one of the basic instincts of human nature is to get bored with repetition, if there is a repetition in your life that is not providing any improvement of skill, then you should work to get rid of it. A real-life example of this is when you write down a shop list that you keep in the kitchen, but the person who does the shopping copies it before going shopping. Suppose that the person copied the night before, but early in the morning you remember something that you would like to add, and you add it to the list in the kitchen. Now you need to warn that person to add it to their copy otherwise you will not get your item.
When you write a whole system in one file, it is like having a messy room that you can find anything with ease, but anyone else will have a hard time to do so. To organize any room, basically, what we do is to put everything in the right spot and take out the unnecessary and annoying things. So, anyone with basic understanding of the patterns applied will soon be able to find anything in the room. Marie Kondo is an organizing consultant that is very influential, she wrote books that are sold worldwide. Check out this inspirational quote from her:
Robert C. Martin, also known as Uncle Bob, wrote an influential book on code quality called Clean Code. The title of the book already suggests a resemblance to Kondo’s ideas.
If we mix these two ideas we can say:
The objective of writing good code is not just cleaning the code, but to feel happiness working with the code
If you want to write good code, your job is to be Marie Kondo of it and to minimize the WTF moments for the user of your code. In the next section, we will continue this discussion with how programming languages work and how they influence the quality of the code.
