Write Better Code Faster: 5 min read

5 min readMay 21, 2022

Trivial tips on how to code faster without compromising quality

Recently, I’ve read “Modern Software Engineering” by David Farley, which elaborates on durable principles at the heart of modern software development. I think this book is a great source for both experienced and junior engineers, though from different perspectives.

Fresh developers will find the book as good guide on how to design & develop a software without reinventing the wheel. Mr. Farley gives hands on instructions how to make reasonable decisions when you’ve just started writing first lines of your application code. As for an experienced engineer, the authors book would seem like a complex conversation about challenges & solutions in modern software engineering.

I want to share a few fundamental tips on how to write better code faster based on what was mentioned in the book and my personal experience as a software engineer.

Code for humans

“The primary goal of code is to communicate ideas to humans”

That is the most essential principle when you start writing your code, but yet many people are missing it. I’ve seen genius peers who could write complex lines of algorithms, yet their lines were readable only for them, and completely hidden for others. We ensure code readability adhering to certain patterns & principles, so tomorrow we can understand our own lines of program, or others can pick it up & continue working on it. And it is true not only for corporations where people change quite often, but also open source projects & even your own pet projects, which can grow & require additional hands of developers.

Think of prehistoric petroglyphs: they were inscribed a few thousands years ago, but yet we understand the message until now.

Figure 1: Prehistoric petroglyph in Acacus Mountains of Sahara, Libya

Test Driven Development

Testability strongly encourages modularity

As your code grows, keeping it readable means making it modular, Separating code into modules and then importing it piece by piece wherever needed is part of daily development process for many engineers. Developers must be able to test each module, so if any increment causes a bug they can notice it. But this is just a small piece of the story. Testability ensures that your modules are separated enough. In other words, rule of thumb is that the set of tests for a module are aimed at checking app’s specific functionality. If it is not true, then maybe one must revise his or her code.

One of approaches to develop right modular code is to follow Test Driven Development paradigm which means that first you develop your test cases per each module and then write your code. Thus you are more likely to spot problems with separation of concerns in your modules.

Avoid Self-Deception

Writing an application will soon or later involve some bug fixing process. When analysing bugs, many of us see obvious causes of it and jump on solution immediately. But it may be very deceptive as if the root cause of the problem is somewhere else then you’ve just wasted your time & resources. It happened to me very often, so that sometimes I would leave my code for days out of frustration. But whenever I came back and analysed the problem, it would be an easy fix & clean code in the end. In short, don’t let your first assumption to deceive you, otherwise you will end up with failing your deadlines & motivation.

High-Performance

“If you are really interested in the performance of your code, don’t guess about what will be fast and what will be slow; measure it!”

David Farley emphasises the importance of being empirical in the process of software development. His point is simple: do fact checking instead of relying purely on some theoretical hypothesis. For example, most of us know that multithreaded program is usually used to enhance the performance of our application. But is this true for all cases? Definitely no! Even in some trivial cases, single threaded program can be several times faster. In short, we do design high-performance application code based on theory & experience, but it must be validated through dozens of tests & measurements. In fact, measurement is an essential part of software engineering process in most of the projects.

Embrace the change but rewrite your code wisely

“Good teams will probably rewrite half the software that they are responsible for in months; low-performing teams may never rewrite half”

As we write our code, it is quite common to rewrite them again and again as we learn and understand the problem we’re solving over some time. But we must be able to do it wisely, so that it doesn’t cost us too much. Therefore our approach to coupling & code cohesion is very imperative in sustaining stable development. For example, if we use abstractions (i.e. abstract objects) to hide accidental complexities (i.e. a piece of code dealing with the connection to the database which entails a number of errors that are not under your control) and isolate third party systems or libraries, then it will be very easy for us to come back and replace the code. The key here is that rewriting your code is normal and we must be able to embrace the change, but we must learn how to design our code so that it is easier to modify it if necessary (hint: ask yourself whether your code is testable enough?).

Figure 3: Super hero dealing with an old code

Final notes

I have read Robert Martin’s Clean Architecture & Clean Code in the beginning of my Software Engineering career. After many years of experience, reading “Modern Software Engineering” by David Farley feels like an extension and exploration of similar topics from the perspective of modern software development dynamics. I suggest you all to read these books in your free time. Going over those pages seemed like having an interesting conversation about software technology with the author in the office kitchen during short breaks.

Further readings: