What is Good and what is bad?
This is an argument as old as time. As long as humans have existed, we have tried to classify events, people, and actions as good or bad. Our perception can influence or sway how we act in relation to those events, people, or actions. This same thing happens with code; our perception of what is good or bad can change the outcome of how we approach code reviews, feature planning, or even just triaging a defect. We can become so obsessed with the idea of good or bad code that it clouds our judgment and distorts our actions. But what really is good or bad code? The definition is often fluid and changes with time, experience, tech stack, or maturity in the field. What is considered good code now can quickly decay into a "smell" in a few years.
Stop thinking about code in absolutes
We spend a lot of time defining what code should be. Design patterns, frameworks, style guides, manifestos on how to write code, and how many lines a function should have. I'm guilty of this trap too, thinking that some defined pattern is going to make my code better than it was before. I'm not ignoring the benefit of having a shared set of guidelines and standards when working with a larger group of developers. This is an essential part of keeping code maintainable, readable, and the cognitive load low, but is it a measure of good or bad code? It shouldn't be.
Maintainable code, lacks complexity, and functions as intended has reached its designed purpose and completed its part in the ecosystem of whatever code you are working on now and in the future. Is that code good? To me, it may be, but to the avid believer of functional programming, it may be terrible, or to the Typescript purist, it may seem foolish and poorly structured. It is all subjective and mind-numbing, a distraction from what software should be, a solution that solves a problem in the least complex way.
There is nothing inherently good or bad about code; it is a set of instructions designed to solve a problem. The idea of good or bad is a purely human construct, probably born with our obsession with labeling and classifying the things around us. This struggle is nothing new; from Greek and Roman philosophy (Marcus Aurelius wrote "progress for a rational mind means not accepting falsehood or uncertainty in its perception") to modern day, the battle of good and evil and the human drive to understand these ideas is easy to find. What does it actually accomplish when it comes to coding? Do you code review a developer that you think writes good code with less attention than one you feel writes bad code? Are you so blinded by your perception of a section of code that you can't see the simple fix right in front of you, and instead insist it has to be started anew? Often, the way we perceive something as good or bad will significantly change our actions, coding, and working with other developers is no different.
What if you stop thinking about code as good or bad? Instead, think of it in good faith; this was, at the time, the best code a developer was able to write to solve a problem. Its story might be years of additions and decay, compromised by hasty bug fixes and out-of-scope changes. Again, it's not good or bad and is not some terrible thing someone did that should impact your actions. Instead, take it for what it is: someone's best effort at solving a problem. Don't let your perception of the code or the developer cloud your judgment and actions; that helps no one.
Code is subject to entropy just like anything else; what was great code 10 years ago becomes bad practice and lessons learned. It's easy to forget that and label it as bad code with no hope, needing to be rebuilt from the ground up.
Be a mentor
Once you escape the thinking that code is good or bad, it is easier to become an effective mentor, it is easier to be judgment-free, and focus on the things you can control or teach. When you realize that object oriented code or functional code both can solve the same problem just as well, or repeating code is not evil but actually lowers micro-context switches and cognitive load, and that maybe the developer just doesn't realize there is a more efficient or performant way to solve a problem but this is still their best effort and to them represents the sum of their knowledge and experience, you will start to change how you approach these interactions.
When I think about imposter syndrome and how it impacts developers throughout their careers, it is buried in the idea that something is not good enough. Their code, their leadership, etc, imposter syndrome is centered around the idea that they are bad and everyone else is better, so they don't belong. It is a wild obsession we have with trying to fit things into a good or bad box that follows us throughout our entire careers. Instead, we should all just let go and take it for what it is, a solution to a problem. Being a better mentor and moving away from that idea of good or bad can significantly impact imposter syndrome and change the course of a developer's career. Understanding that something isn't good or bad but needs help to be more efficient or performant will change how you interact with your peers and with code. It will change how you look at legacy code from 15 years ago that you're stuck refactoring. Moving past the blinding answer of "it's bad and just needs to be burned down" will yield surprising results.
Try it out, stop thinking about code as good or bad, and see what happens. It might surprise you.
Top comments (0)