How to Program Good
Programming, as it exists today, is not a real engineering discipline. There may be real Software Engineers working for like NASA or something, but I've never met one. Most programmers seem to treat the practice more like arts and crafts.
"This feels nice... this will go fast... wouldn't it be cool if it did this?"
"Hey, there's a cool new technique I saw in a video, we just need to get this new tool."
"It's my life and I can build a fire hazard if I want to!"
This may sound harsh, but I don't think it's totally our fault. Computing has only been around for like 70 years, while every other kind of engineering has hundreds, if not thousands, of years under its belt. When a civil engineer designs a bridge, no matter what, the bridge definitely 100% must not fall down. All bridges since the beginning of time have had this fundamental requirement. By now there are some well proven rules and patterns which the engineer adheres to when designing a bridge, and if they don't adhere to the rules then they stop getting invited to the fun civil engineering parties.
Programming doesn't have these rules. How could it? When a bridge falls down people can die. When my REST API runs out of memory due to a cache leak it gets automatically restarted by the process manager. It's self-healing! Sure, there will be twelve people who failed to save very important phone numbers to their contacts app at that moment, but they won't notice that the saves failed because the UI doesn't handle the error correctly anyway, so it's fine.
This attitude of low-stakes programming is what prevents us from ever discovering the rules and patterns which will regularly produce programs on which people can actually rely. To agree on a rule is to agree on entire categories of things which we will NOT do, but if what we do doesn't matter then we'll continue to simply do whatever we feel like without limitation.
About This Series
How to Program Good is not about introducing a new "whatever-oriented" programming paradigm. It is not about acronyms or languages or frameworks. How to Program Good is a series about setting limitations, and then combining those limitations with simple tools and ideas to create Good Programs. The primary goal is not to be divisive or ground-breaking - I don't think most experienced programmers will find anything new here - but rather to be cohesive and clear.
The journey will start from first principles (what even is a Good Program?), introduce the fundamental building blocks which will be used, describe different ways of visualizing these blocks which will better clarify their usage, and in the final chapters dive into the nitty gritty details to fill in the blanks. At the end the reader should have a clear idea of what a Good Program looks like, how to proceed in writing one, and be able to explain and justify these ideas to others they are a sharing a codebase with.
This series is not for complete beginners. There is an assumption of basic familiarity with concepts, vocabulary, and challenges faced when writing programs. The target audience I'm writing for are those who are capable of writing a program to complete a basic task, but find that as their programs grow past a certain size they become unweildy and buggy. Programmers in this category might be called "low to mid-level" in the industry, though that terminology is quite nebulous and subject to budget constraints. That said, I think more experienced programmers could also benefit from this series; it's helpful to have already-known concepts be articulated in a clear way, both for personal understanding and to help explain them to others we work with.
Chapters
These chapters have been written and published.
Chapter 1: Why Are We Doing This?
Chapter 2: Data and Interfaces
At time of writing I've mapped out (more or less) the topics of the different chapters in this series, and completed the first drafts of some. I intend on publishing new chapters as they are written, and also intend on going back and revising chapters as I work on the new ones. Even once completed I will likely come back and make revisions based on new experiences and feedback from others. So while this series presents itself as an in-browser eBook, it would be better to consider it as living documentation.
If you wish to stay up-to-date with new chapters and future revisions you can follow this site's gemlog or RSS feed, which is how I notify readers of new and updated content throughout this site.
Who Am I?
My name is Brian, though on the internet I go by mediocregopher. I began my programming journey at 10 years old doing Lego Mindstorms, began doing "real" programming for fun somewhere around 2008, and began my career in 2011 when I was hired at a music streaming startup as a backend programmer. Since then I've remained a professional backend programmer, working both in the capacity of a staff engineer and manager. My specialty is in breaking down large projects into digestible parts, building reliable and maintanable codebases, and working with others to show them how to do the same.
Outside my professional life I have never stopped exploring the different worlds of programming. Games, frontend UIs, embedded systems, smart contracts... I've dabbled to varying extents in everything.
This is all to say: I have a lot of experience, and all throughout these experiences I have maintained an interest in the higher level ideas and philosophy at the heart of programming, both for personal development and sheer curiousity. Are there concepts which are universal to all programming languages and fields? Is it possible to develop a theory of programming which can serve as a foundation for consistently building high-quality programs? How do seemingly secondary tasks like testing, documentation, and task tracking fit into this picture?
While I don't have the full answer to any of these questions (and don't expect that a full answer even exists) this attitude has led me to the point where I can write a fairly cohesive guide on how to consistently write Good Programs. And so, in the spirit of open-source and good will, and also in the spirit of only wanting to explain myself once, this series is born.
Hi! I'm available for remote contract work. You can learn more about me and my skillset by browsing around this site, then head over to my resume site to find my work history and professional contact form.
This site is a mirror of my gemini capsule. The equivalent gemini page can be found here, and you can learn more about gemini at my 🚀 What is Gemini? page.