The Value of Code Consistency is Underestimated- 2 mins
The value of code consistency is underestimated
I worked on a friend’s design not too long ago. His design drove me crazy because the lack of consistency. The margins, paddings, font sizes, and colors were all different in different pages. I ended up eyeballed everything because I wasn’t sure which page to follow. Keep things consistent seems easy and doable to designers. In reality, only very experienced designers come along with consistent designs. A good design isn’t something how it looks; it’s how it works on many different levels.
A good design starts with a thoughtful process, careful planning and an intention to details. At last, it’s how it looks. That is why a good design takes time, and it should take time. In the world we are in now, it’s nearly impossible to have designers to think thoroughly before they start working on it.
As same in design, code consistency is hard to keep as well especially when developers come and go. Writing maintainable code with code consistency really matters to the team in a long run. The value of code consistency is way underestimated today. QA developers spend a lot of time to verify bugs on the outside, code consistency is certainly a way can reduce amounts of possible bugs on the inside. It is also far more efficient and effective than code refactor, which can be considered as one of the passive ways to match code consistency. Developers come from various backgrounds, having different developers following one rule is nearly impossible by telling them what to do or ask them to read the damn documentations. It may end up making they think you micro-manage them, bringing negative atmosphere to the team.
So, what’s the correct and the best way of building a team with a healthy and creative vibe that also is very friendly to developers? First of all, proper training. Yes, we are talking about serious and thorough training that are tailored to developers, not a short time, not a few links of long and boring documentation. In fact, decent sized companies should have dedicated developers work on the training programs. Second, linters and build systems. Yes, I know developers don’t like linters, but think broader, in a long run, team benefits from it. Third, proper education of team cultures. It will never work by just asking developers to do things. Explain pros and cons to them. They will understand when it comes down to the team effort because today everyone claims they are team players.