Welcome to the dog days of August!

I know a lot of people are seeking jobs these days. And I also know a lot of folks who have jobs don’t feel terribly secure. The palpable uncertainty around white-collar jobs these days is a big source of stress for a lot of us. So I hope you’ll look at my newsletter as a bit of light reading to help you to decompress from the worries and strains of our current environment.

As always, we’ll have a review of a book (or a video or something else of interest to those of us who write software), we’ll have a puzzle and we’ll have something that, we hope, will give you a bit of a chuckle.

Reviews Dept.

Puzzle Dept.

“The shortest distance between two points is a straight line.” That particular bit of geometric observation is credited to Archimedes, the ancient Greek polymath and scientist. I was a bit surprised to find out that he’s credited with saying it; I had always expected it to be something from one of Euclid’s Elements before I looked up the details of the quote.

This month’s puzzle poses a slight variation on this ancient bit of geometry. For the following discussion, apologies in advance to any mathematicians who may see this because I’m going from my memory of high school geometry.

The line between two points a and b is signified ab. Now if there is an impenetrable barrier between a and b (let’s say it’s another line called cd), what is the shortest distance between a and b? Remember you cannot directly connect a and b. For sake of easing the solution of this problem you can make some assumptions about the geometry of ab and cd.

As I said a few assumptions can make this dramatically easier to solve. First let’s assume that the imaginary line between a and b is perpendicular to cd. Second, we can assume that ab bisects cd (and vice versa). Then the answer is straightforward; it’s simply ac + cb. Referring to the illustration below:

The distance between a and c is the square root of (ad² + cd²). Likewise the distance between c and b is the square root of (cd² + db²). It’s possible to calculate the distance without the using the simplifying assumptions I noted above but the solution is a bit more complex.

(The following puzzles were inspired by a blog post by Adam Aaronson.)

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:

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.)

I hope you find these little word puzzles fun! Feel free to use IMDB! Answers in September!

Cohesion

Continuing on the subject of learning software engineering this month I’ll discuss a concept which is sort of the opposite side of the same coin as coupling: cohesion.

You may recall from last month that coupling is a way of expressing the interdependence between parts of our code base. Cohesion is a way of expressing how much each portion of a piece of code contributes to its overall purpose. An example may help to explain this concept. Consider the following pseudo code:

fn add_numbers(n: integer, m:integer) : integer

{

return n + m

}

This is just about as cohesive as a routine can be. It has one purpose—to add two numbers—and it does solely that and nothing else. Contrast this with this less cohesive routine:

fn add_numbers(n: integer, m: integer, z: string ) : integer

{

print(z)

return n + m

}

This is slightly less cohesive because now rather than doing one thing I’m doing two things. I’m printing out whatever string is passed in the z variable and I’m summing up the two integers passed to me.

Some of you may be reading this and thinking to yourselves “Single Responsibility Principle!” and you’d be correct. However the notion of cohesion of a routine precedes the idea of SRP by at least 20 years or so. We (software developers) keep reinventing the same concepts with new names.

Probably most of you would look at that second code example and say “well that’s just bad coding” and I’d agree with you on that too. The thing is none of us set out to write code that’s not cohesive and that’s pathologically coupled to other parts of our code. It happens over time as code is maintained. For example if I discover some odd case of addition that I need to account for—let’s say I need to treat things differently if I pass a negative number then I’ll usually add that code to my add_numbers routine. Code tends to grow these warts while it’s under maintenance.

Humor (We Hope) Dept.

Several companies have very ideal sounding guidelines for their employees. Things like “We do whatever it takes to make the customer happy.” But the reality of their behavior often doesn’t match the idealistic language they espouse. (Like using the word espouse as a writer!) So in the interest of helping us literal-developer-sorts work through the difficulty of understanding what company guidelines actually mean, I’ll present some common corporate guidelines and their translation in plain English.

Like a family we expect you to act as if nothing’s wrong–ever. Have you ever noticed the company logo vaguely resembles a lot of people ignoring an elephant?  Well . . .  The phrase “Oh no that’s fine” should come out of your mouth as often as possible.

Also like a family, we expect you to show up for all our gatherings and act as if you’re having lots of fun whether you are or you’re not. And don’t be surprised if someone gets really drunk and starts spouting conspiracy theory nonsense. Be prepared with a “American laundromats are actually controlled by the Swedish Mafia? Hmm. That’s interesting!” response. Of course everyone knows all American laundromats are controlled by the Flemish Branch of the Freemasons but pretend they’re right. After all we’re family!

Also like a family expect to be treated like a little brother or sister by your manager. We’re doing our best to respond to the various incidents of “Why are you hitting yourself? Stop hitting yourself!” and “You’re wearing that for your date?” but it’s still a work in progress.

Like assets we’ve got you on a deprecation schedule. When it comes time to “trim the fat” (that is, our CEO needs a new yacht because all the dishes on his old one are dirty), well, sometimes you have to get rid of some assets to save some money, you know?

Also like assets we will invest the very least amount of money we can in keeping you going.

We also expect you to act like an asset. I mean, have you ever heard of an asset calling in sick?  We didn’t think so.

And remember the right thing is patching and patching and patching our systems without ever trying to actually find root causes and fix them. Who’s got time to spend on figuring out why things don’t work?

Put another way, what makes you think that 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, having a clerk manually correct any OCR errors, save the file as a text file, use another PERL script to turn it into a SQL script and then re-importing that data back into the database isn’t the right way to do things? We can’t imagine any way to cut time out of that process and neither should you!

In fact we’re so customer focused, we’re going to creepily stalk them around the web because we’re so focused on them! We just want to get to know our customers better—way, way better.

We want our customers to think of us as a very loving, almost obsessive friend (BEST friend) and a completely unavoidable presence in their lives. We’re hoping that they’ll remember what happened to the rabbit in “Fatal Attraction” and not ignore us.

Feedback Dept.

If you’d care to share:

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!

By the way if you’ve read this far, congratulations! Send me a quick email and say “Hey, Onorio, I read all the way to the end!” and you’ll have my undying gratitude and membership in the exclusive new Impractical Read Entire Newsletter to the End club.

The IRENE club is pretty exclusive (so far it’s only me); once you join you can experience the pride of saying to other developers “I’m An Irene!” as you pity their tragic and pathetic non-IRENE existences!