I want to share a brief experience from a past project at a previous company, which I won’t name explicitly.
Firstly, I am very thankful for this experience because I had the opportunity to work with various technologies. These were defining moments in my life where specific projects provided me with strong hands-on experience in React for the frontend and Node.js + Express for the backend. I began learning React in late 2019, and the challenges I faced were significant.
It just didn’t make sense to me why a particular project that could easily be done with some monolithic architecture would be better off with an architecture that would require maintaining two codebases. I guess it was the trend in those days, and many might argue that it’s the best approach to making good software.
Nevertheless, this frustration started when I was left with this project where my boss asked me to add one field to a specific React Component that functions like a Field Builder. This react component allows you to dynamically add multiple fields by clicking a plus button, which I do think is pretty cool.
I thought, it’s just one field to add, how hard could it be? Boy, I’ve never been so wrong. While I was trying to read the code, I just couldn’t understand a thing. Not to mention, the meaningless variables that were being used (e.g., var c = null, var d = null), you get the idea.
It took me about 4 hours to insert one field into the code, which to this day still frustrates me. I never thought that you could make React so disorganized that it would make you vomit just by looking at the folder structure in VSCode. One thing that I’m only thankful for is that at least the previous person who wrote the code didn’t abstract too much. If they had, it would have intensified the already haunting nightmare I find myself trapped in.
This experience was one of the reasons I took a break from web development or coding for a while. It has made me realize that software teams worldwide should prioritize code readability above all else. You won’t be the only one reading your code at an enterprise level; many others will read it now and in the future. Therefore, it’s essential to make your variables meaningful and to include comments where necessary. Otherwise, adding features would be harder than it should be.
I’m a firm believer in prioritizing code readability because in software development, we can’t always expect software to remain at version 1.0 forever. There will always be a need for improvements and additional features. When bugs inevitably crop up, code that’s easy to read and understand can make a huge difference for both the current developers and those who inherit the code in the future. No doubt, it’s tempting to focus on making code faster or using fancy variable names to show off smarts. But it’s really important to make sure those variables actually make sense, so people can understand what’s going on.
If, as the boss, you’ve allowed your programmers to toil in such chaos, you’re setting your business up for long-term damage. Consider this: when your top developer decides to move on, you’ll inevitably need to find a replacement. However, if your codebase is a tangled mess, onboarding new programmers becomes a tedious and time-consuming process. They’ll spend countless hours deciphering the labyrinth of your codebase, slowing down the release of new versions and updates. Worse still, they may reach a breaking point and advocate for a complete overhaul—a move that can directly impact your business’s bottom line.
Final Thoughts
So, if you’re a developer reading this, do yourself a favor and prioritize making your code readable. Trust me, you’ll thank yourself later.
Picture this: six months to a year down the line, your boss asks you to fix a bug in the code you wrote. If you didn’t prioritize readability, you’re essentially shooting yourself in the foot. So, save your future self the headache and make your code readable now.
Happy coding!