Avoid code inconsistency due to developer biases

In this article, I share my thoughts about how in general developer biases lead to code inconsistency over time and even though we code with the team we would see different patterns for doing similar things. This article doesn’t conclude what is right or what is wrong it is just my perspective how developer biases impact.

Photo by Smartworks Coworking on Unsplash

What do I think of Developer biases?

Developer Biases are in general development practices that we think are correct and would have picked it up from previous work environment or some article or our own experiences and implemented it without consulting it across the team and which down the line leads to inconsistency in code even if we follow the same architecture as a team. These are low-level practices that need to be followed to keep the code consistent.

Listing out a few things which I have seen from my own experience as a Software Developer.

Naming Conventions:

• Over time you would see that in the same code base we have Activities named with different conventions e.g. XYZActivity, XYZScreen, some keep it simply as XYZ.
• In general, you would see few would use ISomeRepository when naming interface and some use normal names without I as SomeRepository and the implementation class follows something like SomeRepository and SomeRepositoryImpl.
• These are just very few naming convention scenarios there are in general more examples where we might not have consistency.

Coding Conventions:

• If your team follows clean code-based layer separation there is a probability that you would see code where some people add Usecase and some people think it is of no use and communicate directly with Repository.
• Some would think we should not write any logic in View classes and some would think the following is completely OK.

• Some might use Resource convention to manage states and data for network calls whereas some might use Either or some might completely have a specific implementation for each network call even though it might not be required.
• Logging there is a probability that there is already a wrapper built on top of logging in android or logging library like Timber or something else is used in the project but still, a developer might end up using Android logger functionality and think it is OK as it just one line for now.
• Dealing with Exceptions we might see some developers using specific exceptions and some using parent Exception and might have a point that it is good to have parent exceptions and code will not crash for the user and some might think we should only catch the known exception and we would know the other exception so that we can deal with it.

Language Feature Conventions:

• With Kotlin we have the option to wrap null checks with .let {} at times we see as a developer we might end up using .let everywhere even when normal if-else will do the work.
• With Kotlin we get extension functions and at times some developers in the team are not aware of existing extension functions and keep using conventional ways thinking it’s OK for now.

Handling Error States Conventions:

• In same project you might see how differently the error states are shown to the end users. At times it might be required but at times it is just how developer thinks how it should be handled.

Even if as a team we follow some architecture our code is not consistent across the project. Some conventions might be wrong. For new joiners who join the team it would be hard for them to get started and specially who join team straight out of college. In code reviews we might think particular approach is not correct without proper discussion and conclusion.

How to we deal with developer biases?

• As of now as an individual I cannot conclude what is good or bad it all boils down to the team and how as a team you guys see things.
• Standardization, having guidelines document which can be prepared post having discussion with everyone in the team and then everyone can refer and keep updating and follow it. Sharing it with new team mates when they join the team.
• Doing code reviews with guidelines as reference.
• Writing custom lints if possible.
• Consulting with the team when adding new things into project it can be anything like some library, practices etc.

In the end, I think the code should look as if it is developed by a team rather individual developers

That’s it for now :) If this helped you please share it with others as well and do give some claps. Also, do share your biases and how as a team you guys manage and keep your code consistent lets connect on Linkedin and Twitter.