5 Tips to Write Cleaner Codes for Better Team
Several weeks ago, I was thinking of hiring a senior engineer for our team. This is because of the increasing number of engineers who work on our codebase in the past 3 months, after team restructuring. They came from different backgrounds: mobile, network, and even machine learning. The Merge Requests increased significantly. So does the code review process were getting slower. Most of them are still adapting to our codebase.
Then one day, I found this blog post inadvertently: We Do Not Need Senior Developers, We Need Senior Codebases.
He argued that what we need actually is not a senior developer, but a senior codebase. But how do manage our codebase to be mature enough? Well, it will need joint effort from all of the engineers working on the code. Here are some reflections on our engineering team.
1) Keep Upgrading English Proficiency
What language do you write your code in? No, I don’t mean programming languages. Do you write in your mother tongue or English? Most of the time, we wrote our codes in English. For us non-native English speakers, it introduces another translation cost.
We gather requirements in Indonesia. We discuss the domain/business in Indonesian. Our ubiquitous language is Indonesian. But when we write codes, we translate them into English. This is a huge cost and sometimes we lost in translation.
The cost is getting higher when we’re limited in the language. The translation can be weird. What’s worse, we can lose the context and meaning of the original domain language.
For example, in Indonesia, the domain we talk about is “siswa menyelesaikan kelas”. What do you think that sentence in English would be?
- A student finishing the course
- A student graduating from the course
Which one is more make sense and contextful? Well, we need another talk with the domain expert. What do they mean by “menyelesaikan”? Does it when student finish their study and close their browser? Or does it when a student finishes all of the modules and then graduated from the course?
That’s one reason why we should upgrade our English proficiency. There could be many other reasons, but that will depend on your personal goals and organizational needs.
2) Grow The Awareness to Write Test
Writing codes are easy. Building maintainable software is not. Our software is getting bigger every day. New features keep coming as we know our users better. The changes are unavoidable. We want to solve their problem, without getting another problem on our own. But how can we make sure our changes don’t break the entire system?
Yes, that is one reason why we wrote the automated tests. To keep the system intact while we change some of its parts. It’s important to understand the importance of why we write tests. It will lead us to write better tests (and software) and not just write them as a formality. Moreover, testing approach should be dynamic. When we adopt new tech stack, we need to make sure that our current approach is capable to test it. If not, then we have to find alternate approach, so that the new stack will be testable.
3) Read Others’ Code
How do we know if our codes are clean enough? We can either have our codes reviewed or have a pairing session with others. Another way is to read others’ code. It can be our colleagues’ codes in the same codebase or other open-source codebases out there. By reading their codes, we can find new perspectives, and gather many code styles, patterns, or simply how they named variables or functions. Furthermore, we can understand what philosophy they tried to bring to their codes and its goal.
One of the open-source codebases I like to read is the Laravel framework. I love how they design the API to be expressive and elegant, simple yet readable and understandable. They made me think about how could I possibly write those kinds of codes.
4) Don’t Follow Blindly
When we read something or find something new, don’t follow it blindly. It could be a concept, an architecture, an awesome pattern, or a new library/package. First, we need to well understand the problem we want to solve. Those findings could be or couldn’t be the answer to our problem. Try to understand the context or the goal, then compare it to our current situation. Only then do we know whether that could help us solve the problem or not.
When we finally decide to adopt something, we also must be aware of the trade-off. Make sure that the trade-off is something we understand well and communicate it with other team members.
5) Empathize with Other Engineers
When you work in a team, you don’t write code for yourself. All other engineers will eventually see and read your code as well. Therefore, write your code as clean as possible. When I say clean code, I refer to Uncle Bob’s Clean Code book. He mentions many great principles, but there are two basic points I remembered:
First; always give variables a meaningful name. Avoid using a single character, single meaningless word, or uncommon abbreviation. Second; a function name should represent its job or intention. A function should do a single job well.
Well, clean code is not the only thing we could empathize with. We can offer help when our colleagues experience difficulty. Or we can proactively refactor old codes, create tools to make our jobs easier, etc.
At the end, whether we need to hire senior engineers are debatable. But I think having a mature codebase is a must. So that whenever someone joining the team, they can understand the codebase faster, which means also faster time to contribute on the product.
