Back when I just started my career as a software engineer, the company that I worked in had a result-oriented culture. People don’t really care how you get your tasks done but more importantly what you can deliver in a given time. There was no code review, no chatgpt, no copilot back then, you have to complete the tasks using whatever resources you can find or asking help from seniors who are also piled up with endless tasks and hopefully they have time to entertain you. We barely communicated with each other, everyone was mindful of their own parts but not yours.
Tasks after tasks, when multiple people work on the same codebase, problems start to surface:
- Redundant codes here and there as a result of copying whatever works before and paste to new features that we are working on.
- Some functions without any references - either someone thinks they might be using them in the future or someone developed a utility function that no one bothers to use.
- Long lines of code that no one bothers reading - as long as no issue arises, no one will care to refactor the code as a wise man once said “if it’s working, don’t touch it”.
- Ironically, things started to break apart when you started fixing bugs on your end.
At one point, I was so frustrated that I had to rewrite whole things when changing a few lines of code would just end up breaking other parts of the system. And thus, I began to look up on the Internet on how others would maintain their code. In my next 5 years of programming, I have put several principles on practice and here are the top 3 principles that I think every junior software engineers should be taught (and yes, I being educate these principles to my juniors on their first day before they have any chances to put their hands on our codebase):
- DRY - Don’t Repeat Yourself
- YAGNI - You Aren’t Gonna Need It
- KISS - Keep It Simple, Stupid
DRY - Don’t Repeat Yourself
It’s a very straightforward concept as the name implies - avoids redundancy at all costs! Most people think that the DRY principle only applies to coding, in fact it is a very universal concept that you can apply to almost any process. By reusing code, you reduce the chances of errors and make it easier to maintain your application. When you need to make changes, you only have to do so in one place.
YAGNI - You Aren’t Gonna Need It
Ever find yourself in a situation where you found a function that got no invocation in anywhere and when you look up in your repository’s Git history and confront the author, the author replies with “Ah, I thought it would be great to have it, maybe we will use it down the road”. That is a sign of over-engineering.
The YAGNI principle encourages developers to focus on implementing features that are currently required, rather than anticipating future needs. Adding unnecessary complexity can lead to increased development time and potential bugs.
KISS - Keep It Simple, Stupid
In software engineering, KISS principle advocates that systems should be as simple as possible. Avoid unnecessary complexity, as simple solutions are easier to understand, maintain, and debug.
For example, if you have a team of 3 and your team is assigned to develop a note taking application. Although microservices architecture is the new kid on the block, there is no reason for you to implement such big complexity to your system. The cost of maintenance would easily overkill the benefit it produces. Thus, you should stick with a more simple and straightforward monolith architecture to save you and your team from the hassle.
