Having worked as an application developer for over 5 years now, I’ve noticed how, generally, there’s a lack of motivation and incentive to build robust, correct, secure and fast application software. While I’m fortunate that my team at GoDaddy does focus on these aspects, right from the design phase, it’s doesn’t apply to all. Furthermore, the higher a developer works in the application stack, the smaller the chance that they invest their time and effort into imbibing these characteristics into their code.

For example, the deeper an engineer is in the stack shown below, the more they’ll need to focus on performance and correctness, and the higher they are, the less they’ll need to consider the performance implications of their code.

Engineers
UI/UX
Frontend
Backend
Systems
Embedded
Hardware

As someone who’s curious about what goes on under the hood and tweaking things, I’ve become interested in diving deeper into the stack and explore systems programming. This will allow me to understand how the tools and technologies I use day-to-day actually work: the kernel, device drivers, filesystems, networks, Docker, Kubernetes, compilers, programming language runtimes, etc, and actually be able to write such software.

Most of these are written in system programming languages such as C, C++, Rust, Go (debatable if it is strictly a system programming language since it has a runtime and GC), D, Nim and a bit of Assembly. It’s been a long time since I’ve programmed in assembly, C and C++ (this was before the modern C and moden C++ standards), and I’ve never learnt Rust, Go, D and Nim beyond their basic concepts when they first came out.

So before I can write systems software, I plan to (re-)learn these languages and with this post, I begin my journey in systems programming.