Becoming a better software developer – with science

Wow, now that is a title.

I have spent a good chunk of this year reading books about software development. The latest one (which I am still reading at the moment) is called "The Programmer's Brain" by Felienne Hermans and has reactivated many memories. I did my Master's degree in Linguistics and Web Technology back then and focused on web development (what a surprise!) and cognitive linguistics. Many concepts in "The Programmer's Brain" align perfectly with what I learned there. Also, many recommendations support the core thesis of both "The Pragmatic Programmer" by Andy Hunt and Dave Thomas and "Clean Code" by Robert C. Martin. In addition to those books, I consulted "Cognitive Linguistics: An Introduction" by Vyvyan Evans and "Software Engineering at Google" by Titus Winters, Tom Manshreck, and Hyrum Wright to write this short (but hopefully sweet) blog post.

So, let's look at what will help you write better code.

Knowing your brain will help.

Okay, you don't need to know all parts and functions of your brain. You only need to know some basic cognitive processes. Three, to be exact. You have a short-term memory (STM), a long-term memory (LTM), and a working memory. Knowledge from your STM and LTM combines in your working memory, where all the magic happens.

I won't go into detail here because that's an extensive topic and a little beyond my expertise. Still, here is a brief example of an interaction that might occur. You are reading a piece of code. Your STM stores what you have just read (variable names etc.), and your LTM reaches back to hard-practiced knowledge such as syntax or implementation details from months ago. All this information flows into your working memory, where you think about the current task.

The capacity of both the LTM and the STM is limited. You have to repeat things to keep them active in your LTM. The STM can only hold very limited amounts of information. In fact, your STM's capacity only consists of two to six elements. Therefore, combined knowledge of STM and LTM in your working memory is necessary to do anything meaningful. Luckily, our brain is really good at bundling information. Bundled information is called a chunk, and chunks help you to hold more information at once. For example, if you know the strategy pattern or the syntax of a programming language, then that is information that can be bundled and retrieved from your LTM.

In general, research supports Go's approach to software development. You may have heard the Go mantra "less is more" before, or at least you may have heard that Go has a very opinionated approach to software development. In his book "Learning Go", Jon Bodner states that "the first choice for a book title was Boring Go because, properly written, Go is boring." Go tries to be as predictable and straightforward as possible. Therefore, the language syntax is rather minimalistic. Unnecessary braces, like those around conditionals, are omitted, and the language comes with an autoformatting tool. Also, Go does not have "real" classes, and inheritance is impossible. That is a good thing. You should always prefer composition. Furthermore, comments in Go have a unified structure that almost all packages adhere to.

We can summarize these findings as follows.

• Learn software design patterns.
• Learn coding standards (both general and language-specific ones).
• Familiarize yourself with new concept reguarly.
• Practice things you already know to keep them in your LTM.
• Use Domain Driven Design (DDD) to make concepts more tangible (and "chunkable").
• As recommended in "The Pragmatic Programmer", consider writing an Engineering Notebook. This allows you to keep track of design decisions and business logic. You could also use a note-taking app like Joplin or a company-wide wiki to achieve the same.
• Add meaningful comments and omit comments if naming and context make things clear.
• Use meaningful variable names if there is no convention. For example, use i in a for-loop, but use basketItem instead of bi.
• Comments and meaningful variable names can help you chunk up information.
• Use automatic code formatters.
• Do not switch editor color themes and fonts all the time.

Reading code will help.

Developers spend more time reading code than actually writing it (current estimates state that you probably spend 60% of your time reading code). In "Software Engineering at Google" the authors make it undoubtedly clear how much emphasis is on code review. Code reviews help you share ownership (taking pressure off the individual) and knowledge. Also, the best code is code whose original author is not shining through without git blame.

That's one thing. The other thing is that, sadly and funnily, developers do not spend as much time reading error messages as they should. A lot of helpful information is regularly disregarded during debugging sessions simply because of all the noise surrounding it. It is better to take a short break and refocus than just look at an error stack without actually reading it.

Lastly, developers tend to reinvent the wheel. As I mentioned before, learning software design patterns is tremendously helpful in becoming a better developer. However, knowing the ecosystems and existing solutions for problems is equally important. I myself had been very guilty of this until, during a feedback session, a more experienced developer told me that I tend to reinvent the wheel from time to time. He was right, and the quality of my work improved after I started exploring the ecosystem more and relying on battle-tested solutions to problems.

We can summarize these findings as follows.

• Make code review a top priority.
• During code reviews, try to understand the code as thoroughly as possible. Talk to your colleagues, and feel free to disagree. Make them convince you, or convince them that one solution or compromise is better than the other.
• Read error messages and stack traces.
• Take short breaks to reboot.
• Do not reimplement the wheel 🙂 Consider other developers' solutions and try to understand them.
• Really get to know the ecosystem of the languages you are using. For example, spend 10 minutes in the morning to read the documentation of a framework or subscribe to newsletters.

Wrap up

There are so many more things that should be mentioned in an article such as this. For example, the importance of software tests and pipelines probably deserves some space. However, I tried to keep this short and give some meaningful tips backed by actual scientific findings and case studies on how to improve as a developer.