Issue #9
Welcome all to 2026! Let’s hope it’s a lot better for most of us who ply the trade of software development than 2025 was.
If this newsletter has been forwarded to you and you like what you see and you’d like to see more please subscribe at https://impractical-engineer.beehiiv.com/subscribe. It’s free and it’s very simple to unsubscribe should you decide it’s not for you. And if you subscribe please drop me a note. I always love to talk to other software developers!
Reviews Dept.
A Review Of:
"Systems that run forever self-heal and scale" by Joe Armstrong (Lambda Jam 2013)
I am a fan of Joe Armstrong. I wish he were still with us to share his wisdom with us (he passed away a few years ago.) Luckily for us he left us a great book and several great talks that help to understand how he created the excellent industrial strength software he created.
It’s not an exaggeration to say that Erlang and the BEAM (which is the purpose-built VM which Erlang runs upon) has been used to create real world systems that have run for literally years without down time. Read that again. YEARS. Anyone who’s ever gotten the “holy crud, the system’s down” call at 2 am will appreciate the wonder of having systems that run for years without tinkering and without failing.
So how did Erlang achieve this miracle? Did they write code that they burned into an eprom and all it does is print “Hello world” trillions of times in an infinite loop? Nope—Erlang was created to run phone switches. If Erlang fails you can’t make phone calls. Again it’s not an exaggeration to say that Erlang literally runs on more than 50% of the phone equipment in the entire world.
So how did they achieve this seeming software development miracle? Well that’s what Joe Armstrong discusses in this talk. The thing that really appeals to me (and why I was and am a fan of his work) is that he didn’t approach the problem from some theoretical, abstract CS approach. He (and Robert Virding and Mike Williams, the co-creators of Erlang) had a practical problem to solve and they created Erlang in order to solve it. They didn’t set out to build some world-killing technology—they set out to solve a difficult engineering problem and just happened to build one of the best engineered solutions I’ve ever seen.
So what are some of the use cases that would lead us to use distributed systems? There are a couple that come to mind without thinking long and hard:
LLM’s: Training LLM’s is hardware intensive. If I can deploy 100 machines to training an LLM then I can have the trained model that much faster. If I can deploy 1000 machines—10 times faster.
Uptime: As Armstrong points out there’s never been a time when Google is taken down for a software upgrade. Since 1998 there’s never been a time when I went to look for something on Google and seen the message “Google is down for maintenance; come back later” Distributed computing allows you to keep things up and going because you don’t have to take things offline in order to upgrade machines.
In sum this talk isn’t some simple step-by-step “How to build your own distributed system” talk but it is a great introduction to the subject—why it’s tough and what we can do to make it easier to solve. Plus Joe was a great speaker who was very good at explaining a pretty tough concept.
4.5 out of 5 stars.
Puzzle Dept.
Solution For December’s Puzzle:
Puzzle 1:
Pretend that you are a point on a plane. You move two units to your right (the actual units are immaterial—they can be inches, or pixels or whatever you like). Then you move two units up. Two units to the left. Two units down.
Now, you move one unit right. Next one unit up. Then one unit right. Then one unit up. Then one unit left. One unit down. One unit left. One unit down. Where do you end up in relation to your starting point? Is it the same place after both trips? (Try to do this one in your head if you can.)
Answer: For both trips you end up at the starting point. My apologies for my incredibly weak drafting skills but I hope this will show you what I mean!
Puzzle 2:
Consider the following concentric circles. Yes, I realize the proportions aren’t correct—play along with me.
What is the formula for the area between the inner circle and the outer circle?
Answer: The formula for the area of the outer circle is πr2. The formula for the area of the inner circle is π(1/2r)2 or π1/4r2. The area we’re trying to find is simply the difference of the outer area and the inner area or πr2 - π1/4r2. I don’t trust my algebra skills enough to reduce that expression any further!
January’s Puzzle:
Consider the following chords on a circle:
As you can see, in drawing 1 I have chord from a to b. Then in drawing 2 I add a chord from c to d. Now in drawing 3, add a line connecting e and f without crossing ab and cd.
(Author’s note—again as you can see my GIMP skills are just not up to snuff. I am going to hire a graphic designer sometime and when I do I’ll pay him/her twice what I’m paid! Of course two times 0 is still 0 but I think it’s the thought that counts!)
What’s Happening Dept.
Selected Conferences and Event Calendar
Date/Time | Event | Location | RSVP/Details |
|---|---|---|---|
12-16 January 2026 | CodeMash | Sandusky, OH |
I know there are a lot more interesting events in the world and if you have more events you’d care to add please send them to the editor.
Learn Software Engineering Dept.
Naming
Continuing on the topic we started in December, let’s think a bit more about naming in software development. I’m not going to bother to recap what was said in December; I’m just going to continue on some of the things we can do to make our names more effective.
We’ve avoided single letter names. We’ve avoided too short names. We’ve avoided undefined abbreviations. And we’ve avoided misspelling of names. Ok, so I lied about not recapping. If you’re offended, write me and I’ll send you a refund. — Onorio, the Impractical Engineer
By the way while I’ve restricted myself to discussing variable names up to this point, all of this discussion applies equally well to functions, classes and pretty much anything you need to name in source code.
1.) Avoid names that have to be explained. Consider this code:
const int RIPBeethoven = 32627;
While you may consider that calling 32627 “RIPBeethoven” is a great joke, other developers will likely have a hard time figuring out that you know that Ludwig died on March 26, 1827 and hence they’ll find this pretty darned confusing.
2.) Avoid using characters which can be mistaken for each other. What is this variable name:
string 0ol1 = “a”;
Many developers use a special font so they can obviously see the difference between o and 0. But can you tell me the difference between O and 0 without double checking? This is not an absolute rule, of course (no rule should always be applied without thought) but it is a way to make it less likely that others will mistake your name for another name. l vs 1 is another source of perennial problems. (By the way in case you’re curious why I didn’t put that code sample in a code block:
string 0ol1 = “a”;3.) Avoid names which are so generic as to be useless. Data, process, stuff — valid names in some contexts but we have to be very careful with them. What would you guess this variable expects:
dataToBeProcessed4.) If you don’t know what Hungarian notation is, be glad. Never use it unless you work for Microsoft and you’re maintaining old code.
Ok, so I’ve had my little joke. For those of you unfamiliar with Hungarian notation, it’s a style you may see in VB.Net code or in old C# code. Basically every variable name is prefaced with the type of the variable. So instead of 0ol1 I’d have str0ol1. This makes a lot of sense in a weakly typed language like C. It makes a lot less sense in strongly typed languages like Java and C#. In fact it can be a hindrance if I need to change a variable from one type to another. If I need to change intCount to a long type am I going to change all the variables to longCount? As I say if you’ve never encountered this one, be glad you haven’t.
Humor (We Hope) Dept.
My Resolutions For 2026
As the calendar turns from 2025 to 2026 (or should I say from 7E9 to 7EA) like many people I take some time to take stock of things I’ve been doing that may not be anything to be proud of. And I make some resolutions to try to do better. But unlike the average schlub I’m going to post my 2026 resolutions here so others can hold me accountable!
1.) I resolve to stop referring to people I don’t like as “chinless, walking pools of recessive genes.”
2.) I resolve to stop being so damned irresistible to badgers (or maybe they’re wombats? Who can tell?) Maybe it’s the soap I’m using?
3.) I resolve to lose 40 lbs. I also resolve to find it again.
4.) I resolve to bring happiness everywhere I go. Or alcohol. Probably alcohol. At least I’ll be happy.
5.) I resolve to finish what
6.) I resolve to create a new language this year. This one will have no word for the color blue but it will have twelve words for what animals leave behind. We need a rich vocabulary to describe our work.
7.) I resolve to work on being a rockstar developer! I am going to get hooked on drugs, destroy hotel rooms and drive limousines into pools! Oh yeah and I will learn to play three chords too. All while writing software. Impressive I know.
8.) I resolve to become more of a people person. Or at least to work on my burning hatred of humanity.
Feedback Dept.
If you’d care to share:
feedback
suggestions
events
questions
or anything else, please contact me, Onorio Catenacci, editor of the Impractical Engineer at my email.
If this newsletter has been forwarded to you and you like what you see and you’d like to see more please subscribe at https://impractical-engineer.beehiiv.com/subscribe. It’s free and it’s very simple to unsubscribe should you decide it’s not for you.
And if you’re a subscriber and you’d like to do a small favor for the editor, please share this with your developer friends!