Issue #5
Before anything else I want to say welcome to the IRENE Club to both Cameron Presley and Colin Patel-Murray! I hope to see you both at the club for some cigars and some fine bourbon very soon. Perhaps we’ll even get in a round of snooker.
If you’re reading the above and thinking “IRENE Club? What’s he talking about?” well you’ll have to do a bit of digging or ask me what it’s about. In the meantime, Cameron, Colin and I will be sitting in our leather wing back chairs and discussing the state of the next generation. “Bounders and cads” is likely to get thrown around quite a bit!
One more thing; I was recently invited to help organize MichiganDevFest 2025. Dave Koziol is putting this one together and from what I’ve heard so far this is going to be a great day of learning and networking! I’ll add more updates here as I learn more details but be on the lookout for this event! I am 100% in favor of supporting our local software developer community!
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:
"Kill It With Fire" by Marianne Bellotti
Full disclosure: I have had the great pleasure of getting acquainted with Ms. Bellotti via a few conversations over the years.
Ms. Bellotti is another developer who sort of came into the software development field by accident. Honestly I think to say she’s a developer is unfairly limiting to her; she actually holds a degree in anthropology and started out building software on the side for fun. She learned to code from her father. I will say that over the years I’ve found a significant number of developers who are self-taught who have a command of the ins and outs of software development that I frankly envy.
She spent a time working in the government doing legacy modernization projects. This book is an in-depth examination of the lessons she learned while modernizing software both within the government and in private industry.
I can’t speak for other developers but for me the words “legacy system” are one of the surest ways I know of to send a shiver down my spine. Watching a horror movie is a picnic compared to being asked to maintain legacy code.
Starting with an examination of the factors that lead code to become “legacy” Ms. Bellotti spells out practical and implementable ways of dealing with the tangled mess that such systems become. When I say “implementable” I mean there’s certainly a large non-technical layer to the decisions that get made in maintaining code bases and she offers good practical advice on that too.
The thing is most of us think of legacy as implying something written in VB6 (maybe COBOL, Fortran, or APL if we’re especially unlucky) and full of constructs that require lots of time to even understand what they’re supposed to be doing much less what they’re actually doing. And I suppose that’s true but it’s also true that code can be “legacy” three months after we last work on the system. And code can very much be legacy if it’s written by someone other than ourselves. Very early in the conversation the author points out that any code base can benefit from the practices she discovered in dealing with legacy systems.
One great point she makes is that lots of us are supporting “Frankenstein” systems. I made a joke last month about “. . . exporting a CSV file from a database then using a PERL script to change all the dates to European style and removing one letter from the end of every other line then using copy/paste to paste it into an Excel file (after the clerk has manually deleted the prior data), then printing it and scanning it into a PDF via an OCR program . . . ” I was deliberately exaggerating for comic effect but I have seen more than one or two Frankenstein systems over the years. The thing is as much as we despise such systems, they do deliver value to a business. While we think of them as the coding equivalent of a shotgun shack built on sand our end-users don’t care about the internal structure of what we do. This is part of what most of us have to fight. That is, while we care very much about the internal structure of our code it’s quite difficult to communicate the importance of internal structure to the folks paying to get systems built.
Even beyond her strong technical advice Bellotti is a great writer and it’s a fun read! I highly recommend this book to every developer regardless of whether they’re working on legacy systems or not.
5 out of 5 stars.
Puzzle Dept.
Solution For August’s Puzzle:
(The following puzzles were inspired by a blog post by Adam Aaronson.)
Word Boxes
This month’s puzzle involves what I’m calling word boxes. I’ll give you a theme and two words in a box format. Your job is to guess the missing two related words. For example, if I gave you the theme “Comedy” and then gave you the following square:
Pastry ---------- Argument
| |
| |
| |
| |
a ---------- b
I’d be looking for this as my answer:
Pastry ---------- Argument
| |
| |
| |
| |
Pie ---------- Fight
(Pie is a kind of pastry and a fight is an argument; pie fights often featured in slapstick comedy.)
Theme: Movies of the 70’s!
1.) Headliner ---------- Conflicts
| |
| |
| |
| |
a ---------- b 2.) Angry ---------- Largest
| |
| |
| |
| |
a ---------- b 3.) Witching Hour ---------- Nonstop
| |
| |
| |
| |
a ---------- b 4.) Beast ---------- Domicile
| |
| |
| |
| |
a ---------- b I hope you find these little word puzzles fun! Feel free to use IMDB! Answers in September!
1.) Star Wars
2.) Mad Max
3.) Midnight Express
4.) Animal House
My sincere apologies for not double checking how the word squares showed on a mobile device. I thoroughly reprimanded the person in charge of checking that stuff and I was very apologetic. I promised myself I’ll do better in the future. Still I gave myself two days off without pay just to make sure I don’t do this again!
September’s Puzzle
Consider that if I have two dots on a page I may draw a line to connect them. Like this:
One Line
Further consider that if I have three dots on a page, I may have one line, two lines or three lines like this:
One, two, or three lines.
What is the minimum number of dots which I need if I wish to draw four lines?
As some of you may have noticed I’ve got the artistic ability of a software developer and it shows!
Also there’s a special bonus puzzle this month. If you share this newsletter with three of your developer friends (if you care to), just let me know and, as a thank you, I’ll share the bonus puzzle with you! And when you’re ready, again, just let me know and I’ll share the solution as well!
What’s Happening Dept.
Selected Conferences and Event Calendar
Date/Time | Event | Location | RSVP/Details |
|---|---|---|---|
10 - 12 September 2025 | Goatmire (Elixir) (The name of this conf is just so cool I had to include it!) | Varberg, Sweden | |
4 - 5 October 2025 | (fifteenth RacketCon) | UMass Boston | |
8 November 2025 | Midwest Tech Conference | Fulton, MO | |
12-14 November 2025 | Clojure/Conj | Charlotte Convention Center Charlotte, NC | |
10 - 13 November 2025 | KubeCon + CloudNativeCon North America 2025 | Atlanta, GA | |
22 November 2025 | Michigan Dev Fest | Detroit, MI | |
12-16 January 2026 | CodeMash | Sandusky, OH | |
25 -27 February 2026 | Confoo Montreal | Montreal, Canada | |
4-6 March 2026 | dev/nexus | Atlanta, GA |
Hat tip to Mr. Chris DeMars for making me aware of three of these conferences!
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.
Complexity
A couple of months ago I shared a link to an excellent talk given by Rich Hickey called “Simple Made Easy.” And he elaborates quite nicely on why “easy” and “simple” are not the same thing. But wouldn’t it be nice if we had some way of determining how complex our code is? It turns out there is just such a metric.
The cyclomatic complexity metric was created by Thomas McCabe in 1976 (it says on Wikipedia!) You can go and read the Wikipedia entry but to summarize it’s simply a way of expressing how many code paths there are through your code. More code paths is more complex. It’s actually easy enough that you can calculate it by hand if you choose to (although it’d be mighty tough to do on an entire application so I suggest tackling the complexity of a function first). Start at the first line in the function; your complexity is 1. Every time you have a conditional (if, while, for etc.) add 1 to your complexity for each path the code can take. That is if you have an if with no else, add 1. But if you have an if/else combination, add 2.
These days many code analysis tools have cyclomatic complexity measuring tools built in. Like any other metric on code this shouldn’t be blindly applied without thought or context. Some code (especially higher level code which is closer to the UI layer) is just naturally kind of complex and hard to simplify. But if you’ve got a function that’s used all over the place and has a complexity of 30, then you probably want to take that as a sign you may want to examine that particular function. As with many other metrics, this is just a signpost to help us to figure out where we might profit the most with the least amount of effort applied!
Humor (We Hope) Dept.
I’m sure most folks reading this newsletter have heard of (and maybe even read) Aesop’s Fables. They are short self-contained little stories that demonstrate important little bits of wisdom that we can always use in daily life. In that vein I wanted to start sharing some Onorio’s Developer Fables to help developers to understand important development lessons. I hope you enjoy!
The Aardvark And The Lion
Once upon a time there was an aardvark named Larry who was a software developer for Antetr, Inc. Antetr was a B2B SaaS startup targeting the rapidly growing ant removal market. Larry had a nice apartment, a sweet girlfriend and not much free time due to Antetr’s incredible and rapid growth.
One fine Saturday having finally finished the latest project for Antetr, Larry decided to go check out a local watering hole. Literally a local watering hole. At this watering hole were zebras, antelopes, and a couple of rather large, tough-looking lions. One particularly fierce looking lion had a tattoo on his front leg. It read “No Regerts.” Larry being the smart software developer he is, immediately spotted the mistake.
“I say, friend lion!,” Larry cheerily called out, “Your tattoo–it’s spelled wrong!”
“What did you say?” growled the lion, somewhat annoyed at being distracted from his conversation with his friends.
“Your tattoo. It should be spelled ‘r-e-g-r-e-t-s’ not ‘r-e-g-e-r-t-s’!”
The lion regarded the tattoo on his front leg and then looked closely at Larry.
As the nurse was getting the wheelchair to help Larry to leave the hospital after his months of convalescence Larry reflected on the foolishness of pointing out a misspelled tattoo to a lion. From now on he’d only point out mistakes to mice, voles and other creatures much smaller than himself.
MORAL: Sometimes it’s best to keep your mouth shut when you spot a mistake.
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. Or if you’d rather, feel free to contact me on Bluesky. One of these days I’m going to get LinkedIn going too.
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!