Making Great Code Greater

How thinking about architecture can take your code to the next level!

Architecture not code

• The code is a product of the architecture. Depending on how well a system was architected to begin with, will drive the quality of the code. A bad architecture will birth all kinds of hacks in the code to work around the system.
• Identify the root problem? This requires some practice but understanding the deeper constraints of the problem promotes your final solution to be simpler and often reusable.
• Always consider the overall system. Your code does not run in a vacuum. It’s part of a larger runtime and a bad implementation of a single component can bring that whole runtime crashing to its knees.

Architecture comes in many levels. A single algorithm can be thought of as an architecture and that is the point here.

95% of my code is written away from the keyboard.

Some of my best code was not written while sitting in front of the computer, but instead while doing anything other than coding; e.g showering, doing house work, exercising, etc...

Turns out there’s a reason for that. Your subconscious is where things like imagination and intuition are controlled. Deferring critical thinking and problem solving to your “background-thread” aka your subconscious, is a highly effective strategy for unlocking critical and creative thinking; contrary to the belief that all problem solving is a purely online or conscious effort. (see here for more).

So, think before you write!

Doing so will help you implement your problem generically and prevent regressing the architecture.

Get to know your language and its tools

• Language Runtime – understanding the low-level implementation details of what makes a programming language work is extremely valuable. By understanding how certain operations are implemented under-the-hood can improve the codes’ performance and reduce unwanted side-effects.
• Language SDK – get familiar with the standard tools and libraries of your language. For me, I write a lot of Kotlin so that means understanding the JVM. The Java compiler tools (javap; what is the Bytecode representation for this code?) are especially useful since Kotlin runs on the JVM. Like Java, Kotlin compiles to Bytecode. Kotlin Coroutines are a really powerful tool in the standard library and I wanted to know how they worked under-the-hood so I could be more confident with my usage of them in a production environment. The languages tools enable you to do things like that!
• Language Standard Library — Your language is equipped with a highly optimized standard library that encapsulates generic functions for common things like data structures, arithmetic, and date-time but also IO for Threading/Concurrency, File/Socket IO, and Networking IO, among many other things. By getting familiar with the standard library, your code will be more succinct, it will leverage optimized library functions, you will avoid writing code that already exists that you will have to test and maintain and lastly, if you ship your to mobile clients, the standard library is usually* dynamically linked at runtime.
• Idiomatic Code — Writing your language idiomatically is important, mostly because by writing the language in the way it was intended, the way it was designed, will by nature have a positive affect on your code quality. You won’t be going against the grain and you will be able to leverage the native features within the language more easily.

Read/Watch

• Clean Code — familiarize yourself with the book, but don’t get too preachy about the concepts in there. There’s some gold in that book but there are also some annoying concepts that continue to divide people (code comments vs self-documenting code). Ignore this stylistic stuff because that isn’t really the hallmark of code quality. Pay attention to things like “single responsibility”, “testable code” and “code smells”.
• Design Patterns (Gang of Four) — this book had a hugely positive impact on my code. A Design Pattern is a generic solution to a common problem space. The authors of this book invested lots of research in identifying solutions to common OOP problems. The outcome of that research is a set of “patterns” that can be applied to various problem domains. This had a profound effect on the way I think about code.
• Refactoring — If you‘re dealing with a codebase that is poorly written, this book gives you hope and provides effective strategies on improving that code in an iterative fashion. E.g using Adaptors to bridge the new architected code to the old, shitty code.
• Subscribe — be part of a community (online or offline). Watch tech talk on YouTube, read tech blogs, deep dives, look at contributing to OSS.

Practice – nothing beats practice, be deliberate and familiarize yourself with some of the things mentioned above.

Thanks for reading.

In a follow-up post, I’ll be talking about my experience landing a Senior position at a Big 4 Company, so stay tuned.