Welcome to the second installment of my series about why it’s essential to aggressively invest in your coding skills. In the first article, I shared some of the extreme consequences that can arise from bad code, from high costs to destroyed data to lost lives.
Here, I’d like to explore some of the professional repercussions faulty code can hold for your business — and your career development as an engineer.
Bad Code Hinders Innovation
Lousy code can severely limit your opportunities to upgrade to newer technology.
Imagine that you use a regular ASP.NET web app with a deployment model on IIS, and the underlying code is highly reliant on file logging directly, without using any proper interface injections for the loggers. (Meaning: You can’t change the logging mechanism via dependency injection.) In this scenario, you’d now like to containerize your code and use the Docker deployment model instead.
But surprise! File logging is not the way forward at all with Docker. Containers are meant to be ephemeral, without underlying OS dependency. Now you’ll have to refactor your whole logging mechanism and replace it with something that does not use underlying OS resources, such as logging to Azure Applications Insight or Amazon Cloud watch.
If your code from the beginning were using dependency injection properly, it would be simply a matter of concrete class replacement. Easy.
Bad Code Impedes Business Growth
The digital world is aggressive. Opportunities for business appear and disappear overnight, with rapid-fire mergers and acquisitions, moves to scale up or down, requirements to adapt to governmental regulations and the important matter of responding to customer feedback.
All of these factors put high pressure on underlying systems to become adaptive, lean and stretchy like gluten. Well-developed software should be scalable, easy to change and a breeze to understand so it can serve a business in any dimension.
Let’s say your company develops a particular payroll module that is hardwired to a specific company with nasty if-else logic that has an almost infinite, cyclomatic complexity. Then your company gets a lucrative business opportunity to expand to another region with completely different payroll calculation rules, and the business asks you to adapt to the system.
Unfortunately, making such a change to your software is crazy and expensive, and you sadly respond to your manager or client: “No, it would be almost impossible to do this within the current time frame." Imagine how much disappointment, shame and business loss your firm will have.
From my experience, software should be designed to be changed and improved. Rigid software is a killer for the business, and there is no such thing as a product that is “done.” Flexible software systems can be expensive to develop at the beginning, but they reap their value by orders of magnitude later.
Bad Code Limits Career Opportunities
When you write ugly, problematic code, and you’re the only one in the building who can understand it, there is a reasonably high probability that other developers will simply try to escape from that code and resist changing it. It will become the small magic box that no one knows how to open except you. Whatever bug needs to be fixed or new feature needs to be implemented, you will be the one contacted for help.
Naturally, people will make sure you are available, pull you from your other engagements to assist in fixing your legacy crime, thereby limiting your career and growth opportunities. This is why you must make sure any code you write lasts as long as possible and is easy to change by other people — not just for other people’s sake, but also for your own and the growth of your organization.
Bad Code Can Make You Noncompliant With the Law
Software systems are used as a store for data in files, warehouses, lakes and more. This data will logically contain sensitive business information such as client names, salaries, contracts and confidential agreements. As a developer of the system, you have the ultimate responsibility to ensure that the data meets confidentiality, integrity and availability security requirements. You can easily introduce a bug in your code that corrupts data, exposes sensitive information or even affects system availability, which can ultimately lead to fines or damage to your organization’s brand.
Bad Code Becomes a Habit
You’ve probably heard Lao Tzu’s old proverb: “Watch your thoughts, they become your words; watch your words, they become your actions; watch your actions, they become your habits; watch your habits, they become your character; watch your character, it becomes your destiny.”
I’d alter that slightly to say, “Watch your code, it becomes your habit.” As developers, we spend most of our day writing and analyzing code. If we’re spending most of our time writing bad code, quite simply it will become a habit. And the more senior we become, the more difficult it will be to change that habit. Fortunately, it is still possible to grow good coding habits even if you’re not used to them — as long as you are determined to do so over a long period.
Bad Code Damages Your Reputation
How do you feel when you read, review or debug a legacy code that has been written many years ago, and it is incredibly cryptic and full of nested if-then conditions? We call this sort of thing “Spaghetti code,” by the way, as shorthand for complex, highly nested code bases.
Whenever I see such code, I just feel something in my stomach: What the hell made that programmer write such low-quality code? It could be an extremely tight deadline. It could be lack of knowledge. It could be laziness. Whatever the case, the impact at the end is the same: I really struggle and pain analyzing and troubleshooting that code. And worse, it’s easy to think negatively of the person who wrote it.
Don’t let this be your story! With a bit of commitment — and an aggressive investment in your skills — you can develop a great reputation while also improving your organization’s bottom line and setting yourself up for future growth opportunities.
