Over the last couple of years, my answer to the question on what good code is, has constantly be changing, is this a sign of growth ? am i getting better ? or am i seeing things from a different perspective ?
If you had asked me 5 years ago, i probably would have told you that good code is code well designed following OOP principles. I would have told you to throw away your procedural code, and favour OOP principles, lay out classes with clear defined access modifiers and proper encapsulation, anything short of this would have looked like terrible code to me.
2 years ago, i would have told you, that any code that dosent follow best principles, "CLEAN" code by uncle bob, DRY principle, SOLID etc is garbage code. My mind was conditioned to think that there is a "Way" to always build solutions.
1 year ago, and even until now, i would tell you, that the best code is code that is simple to navigate through and efficient in execution, thanks to my obsession with performance.
Thinking through on how my definition on "Good Code" has changed over time, i see that it has always been relative to the situation i have been in, there are many lenses to view what good code is.
The problem is, as long as experiences differ, judging what code is good and what code is not good would always differ. Every now and then, people who are introduced to existing projects, always come sitting on their high horses, with a lot of ideas on why the code is not good and garbage.
One other important factor people fail to realise, is that engineering solutions is always relative to the constraints and conditions in which the solution was built. For example, in many early startups, there is a constraint on resources, business requirements might not have been also well defined, so expecting to see code bases as structured as say Google or Amazon is far fetched. There are also constraints on the tech available as at the time when solutions were built. Prior to when Garbage Collection assisted languages were invented, building secure, memory efficient applications were very difficult, so judging what is good code and what is not is very difficult.
In summary, i think the answer to what is good code, and what is not is very difficult. Engineers should just be in tuned to the fact that, it is very ok for codebases to evolve with time, the more you learn, the more you can evolve your code to better handle the business requirements you have. So any code that dosent handle the business requirements as defined as of now, is probably useless.
Top comments (0)