Why you should aggressively invest in your coding skills – part 1


Introduction

Since the early 2000s, I started my software development journey as a hobbyist kid who used to develop small hacking programs using Visual Basic 6.0. I succeeded in writing a couple of programs that used to function correctly with extremely horrible code. It is a horrible code to the extent that when I plan to style a button in blue background color with bold text, I used to write the same code statement for every button I have in my VB forms, I had no clue about reusability. I was just a copy-paste programmer. The impact of this coding style was quite clear; changing a single feature was extremely painful. If I am planning to change button color, I must do it through the whole codebase! However, it was feeling “wrong” for me, and as a non-English speaking kid, I had nowhere to refer to, given the slowness of internet connection during that period and the lack of quality Arabic language programming resources.

As time progressed, I started learning a couple of other languages such as C++ and Java, my English were stronger, and I started to develop a more proper understanding of proper procedural programming. Therefore, I started reusing existing code into functions, refactoring things to assemblies, avoiding hard-coded parameters, and you name it. I also used what I thought OOP quite a lot. Things became a little bit easier, and many changes were centralized as long as they are just parameters or configurations. However, changing certain things remained a pain, fundamental shifts in business logic required almost a full rewrite.

However, I stuck on this level of a couple of years, until I started my professional career my understanding became quite better, I learned a handful of design patterns, applied many of them even though it was not easy and clear when to apply what. However, things became way better, and I was able to primarily write code with considerable extensibility, in what I thought OOP code.

However, when I compare my programming style with more advanced programming, I main the programming style you see in .NET libraries and well-know frameworks. You see the author is writing extremely elegant interfaces that cover wide enough responsibilities, highly maintainable code where everything is injected, custom business logic is always encapsulated in replaceable structs, simply programmer style that you admire and you can see how the software becomes easy to extend and change if you adopt it. I was aiming to raise my programming level to that extent, and I succeeded to large extend to do so, and I will share this with you soon.

Learning how to write a proper code is a non-trivial investment that requires patience, practices and lots of reading. Therefore, I would like to make a case and justify why we have to learn a proper code and what it costs to write a lousy code before sharing the tips.

Bad code costs money

Software code is a smart, intelligent piece of logic that is actively acting upon different sort of data, whether it is accounting invoices, telecommunication records, or banking transactions. If a piece of code fails to satisfy a specific requirement, it can easily damage the organization bottom line. I remember in one of the projects I worked on; The company found that they are losing tens of thousands of USDs due to variable types numeric truncations (using int instead of double!). If the developer knew the underlying usage of each variable type and its numeric accuracy, he would have avoided that issue. However, who would ever care to dig behind the meaning of every variable declaration?

Bad code costs lives!

Have you ever heard of Marine 1 destruction story? The spacecraft which got exploded within less than 5 minutes of its launch? What do you expect the issue is? Lack of fuel? Faulty engines? Wrong mechanical design? The answer is NO to all these guesses! It is a software bug in the navigation system that erroneously interpreted specific measurements to the wrong flight instructions, and a catastrophe happened! Can you imagine the extent of responsibility these trivial code lines can put on us! Imagine how much risk a buggy code can have on Airbus or Boeing navigation systems? Alternatively, a wrong variable assignment in a critical medical device or even in a nuclear monitoring facility? It can easily -God forbid- lead to lives lost, disasters and criminal charges!

This explains why specific industries are extremely aggressive regarding coding quality and accuracy, and it can make or break humanity.

Bad code destroys data

The thing I hate about buggy code is that it does not only irritate your customers business but also puts an extra effort on you on fixing the wrongly persisted data in the systems due to faulty business logic. It is exactly like a small child you took with you to a restaurant, and he destroys some cups, you are expected not only to please the angry host but also clean the residuals of the broken cup.

I remember previously working on a customer project where a faulty business logic was implemented, even though we fixed the bug, the customer complained about wrong data the system had, we had to manually check and query for all faulty records and fix them to restore the correct system state.

Moral of the story: Fixing bug prevents future problems, but it does not remove the past issues. Even though this is quite clear and obvious, you will be surprised how many developers overlook this part!

Conclusion

And that it is for today! In the next post we will continue with what negative consequences a bad code can have, and how can we avoid that. Until then, please share your experiences!