Code Simplicity & Perfection

If you are a software engineer and you have passed the stage of writing advanced Spaghetti code using big ball of mud design pattern, you reach a stage where you want to write the perfect code with proper design structure, using all fancy design patterns and abstraction.

But does it stop there? For some people and some organization, yes. Not sure it is for the best. Using advanced patterns with heavy abstraction everywhere usually comes with a cost, especially when it is not necessary.

At the end of the day, it is not only about how beautiful your code is. It is also about being easy to read and maintainable by someone else. Complex code takes longer to modify by someone else who is not the original developer. It adds the higher chance of your successor rewriting your code (breaking DRY) for the sake of simplicity for him/her. There is a balance to strike. If you don't know the balance, be err in favour of simplicity. More often than not, being (reasonably) simple is better than being perfect.

Fancy Vocabulary

Brilliant Jerk : a software engineer who is relatively knowledgeable and smart but refuses to see more than technical aspects.

This is someone who has strong technical skills but not willing to acknowledge that there is human aspects in the project. That person will fight with everyone to get the most aesthetically pleasing (to him/her) code.

Organizations may or may not want that kind of people as an employee but, as a rule of thumb, don't be that person. Better to stay as a team player, unless you are Maverick from the movie Top Gun.