The Eternal Struggle

One of the main struggles when it comes to maintaining long term projects is the inherent difficulty of working with code where the functionality is not immediately apparent. Reading lines of code written by yourself two months ago, or written by another developer yesterday, can be a major time investment depending on how that code was designed.

Writing easy-to-understand code is an essential skill for new developers to learn- and it’s a skill that if not learned, will cause you and your teammates a lot of unnecessary struggle, productivity loss, and ultimately will cost your company money. Maybe even a significant amount at that.

Many new developers think it’s “cool” when they look at the top answers on leetcode and see what amount to programming hieroglyphics. And with the confusing and generally misguided importance put on passing algorithm challenges for new developers it’s not surprising that a lot of them lack solid design chops.

But alas, there is hope for the young developer who recently wrote a single function comprising 500 lines of code, or for the senior developer who has been flying by the seat of his pants for many years and just finished typing out the 30th if statement in his most recent function.

Writing Better Code

One of the easiest ways to write better code if you are new to software design is to write more functions. Everywhere, all the time, for everything you do.

This has the following benefits (with some examples):

• Functions are self documenting: If a function is named well you can take a glance at it and have a good idea of what it does without needing to read and understand the code inside it.

Consider the following example:

Compared to this example where we’ve extracted some logic into a function:

Having it cohesively organized under a specific name that describes its purpose will allow you to read it faster. In large programs the practice of making code easy to read becomes much more important. Neglecting it will create technical debt that slows down your team exponentially.

• More functions means more testable code: Your surface area for unit testing increases if you write more functions, plain and simple.

Consider again the example above with the incrementOrderQuantity function. Because we wrote this function, we can test the logic inside:

• Functions are DRY: You will sometimes find you need to execute the same block of logic in various places in a program. Creating a function to handle that piece of logic will reduce duplication (reducing bug surface area and making future changes trivial) and reduce the lines of code in your program.

• Writing more functions will make you a better developer in many ways: When you start challenging yourself to abstract more of your logic into functions you will naturally develop the ability to identify and group together cohesive pieces of logic. This ability is fundamental for memorizing specific design patterns and will make you better at solving problems with software in general.

Toeing The Line

When it comes to learning any new skill there is often going to be the process of over-reaching and under-reaching when trying to improve. Whether it’s with singing a little too ambitiously, or using too little weight in the gym.

When it comes to improving your software design skills as a complete beginner I encourage you to over do it with writing functions. You should constantly be trying to abstract functionality into testable, small units inside of functions, even if it seems overkill. A good rule of thumb is that if your functions require several comments inside of them to be readable they probably include too much functionality.

Overtime you will naturally come to find a balance point between abstracting logic and writing slightly larger (but still cohesive) functions.

Good luck and enjoy the learning process!