Issue #7
Welcome to November all!
Since yesterday was Halloweeen, I have been reflecting on the fact that when I was young enough to trick or treat, I can recall many Halloweens when I’d be wearing a coat over whatever smock my costume was. Being a child of the era, most costumes consisted of a smock with the name of the character. I loved my “Captain America” smock which had “Captain America” emblazoned all over it—in case you weren’t clear on who I was supposed to be. The smock and a stiff plastic mask held on the face with a grey rubber band held in place with two staples. High quality stuff no doubt.
But here in Michigan, November is, usually, the first month we get snow. We also get lots of grey clouds and the start of seasonal depression for some of us. If you want a place with four seasons Michigan certainly works. Of course sometimes the seasons last a day (spring especially) but there are four of them!
Oh and special Thanksgiving greetings to the IRENEs! I bet you thought I’d forgotten about you!
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:
"Finding Bugs Without Running or Even Looking at Code" by Jay Parlar (from Strange Loop 2019)
Once again I return to the Strange Loop video archives because there are just so many interesting, thought-provoking talks there. This is one of my favorites.
In this age of AI, it may feel as if there’s nothing for us as developers to do. But there is one realm that was hard and continues to be hard—building the models upon which we build our software. And when I say “model” I’m referring to model in the abstract sense. If I need to track customer information I’m likely to do that in a database table. But what I need to track and how I validate it and all those sorts of things are abstract from the actual table. A badly modeled system can cause errors that are not only hard to track down; they are extremely hard to fix. It’s analogous to someone asking me to build a mansion and I end up building them a doghouse. No amount of patching is going to make things right.
Dr. Parlar does a fine job of discussing why it’s important to lay out our ideas about models in advance of coding anything. But he also demonstrates how useful creating models after the fact can be. I’ve seen people create UML diagrams, I’ve seen large documents discussing models but the one thing I almost never see is a model that can be checked for correctness. And this is what Dr. Parlar is laying out in this talk—how to create a model within a tool called Alloy and then how to find the incorrect assumptions hidden in that model.
The way Dr. Parlar explains this (at first) is very much akin to rubber duck debugging. Except in this case the rubber duck can tell you the implications of the way you’ve structured your model. I love the quote he mentions “Writing is nature’s way of letting you know how sloppy your thinking is.” (Dick Guindon). I’m reminded of that every month as I prepare this newsletter.
This video isn’t really a tutorial on Alloy; you’ll have to look elsewhere for that. It’s more of an informed pitch for the notion of creating models that we can do some verification upon and then checking them so we can either avoid subtle problems or remedy them after the fact. Tooling of this sort is far harder to master and it also gives us the ability to track down much more subtle issues. This won’t generate code for you but it will help you to avoid building code with bad foundations baked in.
One thing that I find especially interesting is that he covers a case of using Alloy to create a model of an existing system. Via testing his model he discovered a pathological case that took several steps to occur. He didn’t inform the model to look for this case; it simply came up because his description of the software was accurate and the tooling looked at all possible cases. The problem the tooling discovered in his model of the system was indeed valid and it did save the developers from shipping code with a dangerous security flaw.
By the way if you’d like to learn more about Alloy here’s a great jumping-off point. It’s free but of course, like any tool, it takes time to learn.
4 out of 5 stars.
Puzzle Dept.
Solution For October’s Puzzle:
It happened a while ago that a census taker was proceeding along a street gathering census information. He finished with number 19 and moved on to the next highest address number on the same side of the street. A lady responded to his knock on the door. “Good afternoon Ma’am. I’m gathering information for the census. Can you please tell me the occupations of yourself and your spouse?" She responded: “He is a postman. I am a professor of mathematics.” “Oh, I have some background in math!” said the census taker. “Do you have children?” “Yes we do!” “How many?” “If you factor our house number, the larger factor is the number of males in our home and the smaller factor is the number of females (including me) in our home!” “Excellent! Thank you so much for your time ma’am!” He jotted down both the number of males and females in the math professor’s home and, whistling a happy tune, he continued on to the next house. How many daughters do the professor and her husband have?
Answer:
Since you know he’s on the block after number 19 we can assume that the first house number is 21 or greater. We can also assume that it’s not as high as 31 since it seems unlikely that the city addressing folks would completely skip the 20’s for the next house. Likewise we can also assume that the house number isn’t even because the census taker is working on the odd-numbered side of the street. If he moved to the even numbered side of the street we would have mentioned that in the problem. If the house number is 21, then the factors are 7 and 3 and the number of daughters is 2. 23 is a prime number so it factors to 23 and 1. In this case the smaller factor would be 1 and since the math professor indicated she has daughters, this cannot be correct. 25 factors to 5 and 5—neither of those is larger so this cannot be it either. 27 factors to 9 and 3. This is why we asked for the number of daughters because it has to be 2 again. 29 is a prime number which factors to 29 and 1. Hence it cannot be this for the same reason it cannot be 23. Hence the answer in this case is 2 daughters.
November’s Puzzle:
Word Boxes
How Word Boxes Work. 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: |
|
I’d be looking for this as my answer: |
|
(Pie is a kind of pastry and a fight is an argument; pie fights often featured in slapstick comedy.) |
Theme: Famous TV Shows
1. virtuoso ---------- walk
| |
| |
| |
| |
? ---------- ? 2. dusk ---------- area
| |
| |
| |
| |
? ---------- ? 3. duty ---------- infeasible
| |
| |
| |
| |
? ---------- ? 4. Chas' ---------- messengers
| |
| |
| |
| |
? ---------- ? What’s Happening Dept.
Selected Conferences and Event Calendar
Date/Time | Event | Location | RSVP/Details |
|---|---|---|---|
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 |
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.
Idempotence
I have to confess this is one of my favorite topics to discuss in the realm of software engineering. I consider that a knowledge of the concept and how it applies in different contexts is an essential arrow in the software developers’ quiver.
First what is idempotence? The term, which was coined by mathematician Benjamin Peirce in 1870, literally means "(the quality of having) the same power", from idem + potence (same + power). I find this easiest to define in terms of a function. Consider the absolute value of a number.
a = |-1|
Now if I take the absolute value of the result; that is |a|, a doesn’t change. In fact for any number n |n| = | |n| | = |||n||| . . . for any n. If I apply the absolute value function once or a thousand times, the result is still the same. So an idempotent operation is an operation that will make a change at most one time no matter how many times it’s applied.
Now let’s consider this in terms of software. Let’s say I have a process that sets the starting date (start) for some transaction to today’s date (today). If I call it and start is not today then start ← (becomes) today. And then if I call it more times during the same day it has no effect.
Why is this worth knowing about? Consider the case of updating a record in a database. Let’s pretend we have a number of items sold field somewhere. A query that sets items sold to 200 is idempotent. It doesn’t matter how many times I run the query items sold will always end up as 200. On the other hand, a query that updates items sold to items sold + 200 is not idempotent. Starting with items sold at 0 then this would be the result:
items sold = 200
items sold = 400
items sold = 600
etc.
This is not to say that one approach or the other is better. It depends on the properties of the system in question. In some systems, idempotence is desirable. If I’m setting up a build environment and I need to reset it to a known to be good state then I want that operation to be idempotent because I may need to apply it several times. If, on the other hand, I need to maintain some sort of state of the environment between uses then I definitely do not want an idempotent operation. I want the changes to accumulate.
Ultimately this comes down to making software that works by intention rather than by accident. It’s the difference between knowing that you can execute an operation multiple times and it will work as expected or that an operation can be executed multiple times and that it will accumulate changes. As long as you’re intentionally doing this (either way) it’s fine.
Humor (We Hope) Dept.
It strikes us (by which I mean me, the writer/editor/copy boy of the Impractical Engineer newsletter) that many captcha images are just too easy. With AI advancing as it is we need to come up with captchas that are really challenging! Like this one for example:
Hidden Spies Captcha
or maybe something like this:
Trophy Captcha
This one would be trickier too.
Enkidu Captcha
Gratitude Dept.
Since this will be the only newsletter in November and since, for those of us in the United States, Thanksgiving Day falls in November I just wanted to take a few moments to identify things I’m grateful for.
1.) The people who helped me out when I was first learning to code. A lot of folks were very generous with their time and patience. I would call them out by name but my memory being as weak as it is anymore I am afraid I’d miss folks and I’d feel bad if I did.
2.) The people who’ve put up with me over the years. I can be a bit difficult to live and work with (mea culpa) and I’m very grateful that I’ve met many people who were willing to put up with my “personality”. I think the Church is already starting on the beautification process (formally recognizing someone as a saint) for my wife.
3.) Smart friends. I have had the privilege of meeting and talking with a lot of smart people in my journey to being a better software engineer. I still talk with several of them and I find that every time I chat with them I learn something new and interesting. Life can be a banquet of cool ideas if you sit down at the right table.
4.) The time I had with friends whom I no longer have. A few of my friends are gone now. The wonderful memories of these great human beings is a priceless treasure to me. I hope that when it’s my turn as the guest of honor at the last party that some folks will remember me with some fondness.
5.) The chance to keep learning. You have to keep learning; this is truly a must if someone wants to get into the line of software engineering. In this one thing we bear a resemblance to doctors (if you squint really hard) and other professionals. I love learning new stuff and so the profession of software development has always supplied that part of my personality very well.
There are lots more things that I am grateful for but I will save them for another occasion. I sincerely hope that all of the readers of this newsletter have so many things to be grateful for that they struggle to enumerate all of them!
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!