Issue #8
Happy Holidays all!
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:
"Facilitating Technology Change Through Cultural Change" by Grant Maki (Elm Conf 2018)
Full disclosure: I am acquainted with Grant Maki.
In this talk Grant addresses how to get your team to try out new ideas. Grant worked (and may still work) at Ford at the time. It’s hard to imagine a more paradoxical place—at least to me. At the top levels Ford is incredibly hide-bound. As someone once said to me “Making a change at Ford is like turning a cruise ship around. It can be done but it’s not easy.” However at the lower levels Ford is constantly trying new things. I can recall software companies boasting about being used by a Fortune 50 company—and they were often talking about Ford or GM. The fact that one team in one part of the company bought a copy of your software isn’t exactly “Oh they’re using us all over the place!” but on the other hand the only way to change the course of the cruise ship is to create value and let people above you see that you’re creating value.
He starts out by addressing why some teams are better at trying out new ideas than others.
A bit of a digression here: I once heard Uncle Bob Martin talking about what he terms “The Churn”. This is his phrase for the eternal search for that next bump in productivity via newer tooling, newer languages and newer paradigms. And he’s not wrong—lots of developers (mea culpa) are guilty of chasing shiny new software development objects. But to write off any sort of change as a result of software developers chasing the next dopamine rush is a bit too cookie-cutter for my liking. If we never changed anything we’d still be coding on green screen terminals with COBOL. The trick isn’t to avoid change or to constantly change either—it’s to find a good balance between the two. We cannot improve if we stay static but we also cannot improve if we never settle on standards and good approaches.
So why are some teams better at trying out new ideas than others? Because they try new things out! But, of course, it’s not that simple. Grant shares some of the lessons he’s learned over the years about the forces that keep people from embracing change and how to deal with those forces. He’s quite realistic in discussing the hurdles to making change. Knowing what the hurdles are is a great step to addressing them.
Overall this talk is full of pithy, practical advice on how to get your team to try new ideas. Of course, all teams are now moving to AI so it will all get pushed out a year or two until people realize that AI isn’t going to replace developers. But this stuff will still apply then too.
5 out of 5 stars.
Puzzle Dept.
Solution For November’s Puzzle:
Word Boxes
Theme: Famous TV Shows
1. virtuoso ---------- walk
| |
| |
| |
| |
? ---------- ? 2. dusk ---------- area
| |
| |
| |
| |
? ---------- ? 3. duty ---------- infeasible
| |
| |
| |
| |
? ---------- ? 4. Chas' ---------- messengers
| |
| |
| |
| |
? ---------- ? 1.) Star Trek
2.) Twilight Zone
3.) Mission Impossible
4.) Charlie’s Angels
December Puzzles
Since it’s the Holiday season I thought I’d share a little extra with all of you my loyal readers! So two puzzles this month!
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.)
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?
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
Because I really don’t have any ideas to share this month let’s take a few moments to talk about a neglected but essential practice in software development: naming stuff. You may read that sentence and think to yourself “Really? He’s going to talk about naming stuff?” but it is one of the hardest things to do and more importantly it’s essential for making your code maintainable.
Consider that Steve McConnell in his seminal work on software engineering, Code Complete, devotes a whole chapter to the topic of naming variables. Also consider one of the best observations about software development is Phil Karlton’s immortal aphorism: “There are only two hard problems in software engineering: cache invalidation and naming stuff.” and I think you’ll agree this is a topic that’s worthy of some attention.
This month (I think I may have enough to span a couple of months but we’ll see), I’ll start with names to avoid.
1.) Avoid single letter names. Unless you’re encoding the solution to the quadratic equation or you’re dealing with a very well defined value that’s a single letter (Euler’s constant e comes to mind) a single letter name is almost never a good idea. Consider the following pseudo code:
t = t1 * 1.06Now consider this—what’s 1.06? What’s t? What’s t1? This code is much easier to understand (and more importantly to maintain) when we use good variable names
TotalWithSalesTax = Total * 1.062.) Avoid short names. Using short names is one of those premature optimization things that novice developers seem to think will speed up their code—as if the variable names are carried into the binary that eventually gets built.
I once worked with a developer who used variable names like x, xx, xxx etc. I never got the chance to point out to him how hard it was to read his code because I only heard about his rather poor naming practices after I had moved on from the company.
3.) Avoid abbreviations. You may know that EBIT means Every Body Is Thrilled but others may mistake that abbreviation for something else. If you absolutely cannot avoid using an abbreviation then at least leave a comment in the code to indicate what the abbreviation represents
// Earnings Before Interest and Taxes
EBIT = . . . .4.) Avoid misspellings and be consistent. This can be a tricky one for some of us. However consider what you would do if you ran across a variable like this in code:
IsValceOpen = and further on you find:
IsValveOpen=(Author’s note—it can be really hard to contrive examples!) Are those two different variables? If they’re both referring to the same thing why are they spelled different? If it is a mistake why hasn’t anyone fixed this before now? If it’s not a mistake then why two different variables that are named so similarly?
Speaking from personal experience this is one of the maintenance developer’s biggest headaches to deal with.
As I say, there’s a lot more to say on the subject of naming so I may continue this one next month. For now, I think four good points are a good start!
Humor (We Hope) Dept.
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!