What does it take to write good code? Why can no one seem to write it well?
You’ve probably had some ticket that you were working on where you had to decipher someone else’s code. Jumping between methods, classes, and interfaces you start to get lost in the details. What in the world does ComponentViewModelServiceFactory do? And why does it have a byte array called Icon? Weren’t you in a text processor earlier? You would have written this so much better.
You’re probably right. Looking at the code, you can probably see ways that it could have been written better had you started fresh. You probably see limitations in that code keeping it from being expanded upon. But the code is already written (and there’s no tests!)
Hindsight is 20-20
Think about any project that you’ve worked on in the past. Have you ever gone back to work on it, and that was almost impossible and really confusing? You have to remember why you wrote something a certain way, what those variable names mean, what each item in the tuple represents… it’s a lot.
When working on a project, it’s easy for deadlines to get the best of us and to skip over proper design processes. Sometimes something doesn’t seem to need to be abstracted in the moment. But you come back to it and all of this static code you wrote really should have been designed differently.
When you look at someone else’s code and get frustrated by it, you’re feeling that same frustration that you might feel with your own code that wasn’t written well. And that doesn’t necessarily mean that the code is bad—sometimes it just wasn’t designed for the new problem you’re trying to solve with it.
Features adapt to new requirements, structures shift, and your knowledge and experience changes. That’s why it’s important to try to separate things into different modules as much as you can. If there’s even a hint that something you’re working on could be used in another project or just with a broader or different scope, make it modular.
What is correct code?
School has taught us that we need to find the correct solution. We’re taught formulas in math and science classes, learn grammar rules in literature and language classes, and how history went down specifically. That… doesn’t translate to code… really at all. So what are you learning in programming classes? Why does it feel impossible to craft a pull request that your mentor is actually happy with?
First off, throw out the idea that there is one way to do things. Sure, some code just doesn’t work. A lot of code does though! Does your code work and can anyone (who is proficient in programming) understand it. That is your goal. You can learn design patterns and common techniques, but there won’t be a single correct solution to a problem.
Correct code is really a combination of things. Does it produce the correct result? Is it clean and understandable? Is there room for adapting it or using it for other purposes? If so, its probably at least decent code. For the majority of cases, there isn’t going to be a perfect version of your code. Think about all the ways that you can calculate if something is even. Is the correct way writing a function that uses the modulo operator (frequently %) like x % 2 == 0, or should it be a recursive function that subtracts 2 from the input number until it equals 0 or 1, or it should it be a loop version of the recursive function? The first version seems to be the best, but what if you’re practicing recursion or are expected to prove your understand of recursion? The “correctness” of code is always going to be relative to the context of the problem.
Correct code needs to have a thought out design. Proper model definitions, plenty of abstraction, and a clear separation of concerns.
The Team Setting
And even with all of that, you could follow all of this guidance and still have bad code when seen by someone else. Sadly, despite your good intentions after reading this article, you’ll still be expected to cut corners. Some people may have different ideas on how something would be structured. That’s ok, genuinely listen to advice, and then act on it as you see and how you need to.
Sometimes, following team guidelines can be more important than writing fundamentally good code. If there’s glaring flaws in the design, you may want to try to work those out of the system. For everything else, try to adapt your own approach to work better with the team. Teams need rapid productivity, and that usually will mean working with whatever structure the team already has in place.
Like what I write? Sign up for my newsletter bellow to get notified whenever I write!
