What is “The Impractical Engineer?”

I’ve been wanting to put together a newsletter to help connect all the folks I know in software development in Southeast Michigan (and a few in Southwest Ontario) for quite some time. I decided to finally pull the trigger. For now I’m planning to write and mail this once a month. As you may see from some of the headlines below I’m going to try to include reviews of worthwhile books on software development; I may include some books to avoid as well.

I’m going to try to come up with a puzzle each month. I love puzzles and I don’t think I’m alone in that feeling.

I’m going to do my best to keep up an event calendar of sorts so that people will be aware of upcoming learning opportunities and other things which may interest our local software development community.

And finally if some of you send along letters, I’ll do my very best to answer the questions that people send to me. For now, anyway, it’s going to be a “letter from the editor” because I don’t have any genuine missives sitting in front of me.

If you consider this newsletter worthwhile or interesting, please feel free to share it with others. If you don’t consider it worthwhile or interesting, please accept my apologies!

If you feel you may have something worth sharing with the wider community, please reach out and let me know. I won’t promise I’ll share everything that anyone shares with me but if it seems of general interest I will share it and, of course, credit the author.

Oh and if you’re curious about the title; I am a huge fan of pragmatism and pragmatic approaches. But since I think I never manage to follow them I decided to call this newsletter after myself—impractical.

A Review Of:

Conceptual Blockbusting by James L. Adams

Yeah—that’s not really a software development book now is it? But some of the books that have helped me to grow the most as a software developer are not on the specific subject of software development. This is one of those books.

James L. Adams (1934-2022) was a professor emeritus of Mechanical Engineering at Stanford University. Adams worked for NASA’s JPL from 1961 to 1966 and as such faced several interesting engineering problems—some of which he describes in this book.

One of Adams’ first observations is that most of us don’t think a lot about how we think. If you want to become a better singer, you practice singing. If you want to become stronger, you lift weights. But what if you want to become a better thinker? What then? Most of this book is his answer to that last question.

One interesting observation is that there are different languages in which to express solutions. I use the word “language” guardedly because it has some connotations that may make folks misunderstand what’s being discussed. Most of us are accustomed to using English to explain our thinking; some of us may use mathematics to express ideas; a few may even use graphics to express ideas (UML diagrams anyone?). Some problems expressed in algebraic notation are almost embarrassing simple. Some problems expressed in English are trivial. However, it’s a rare individual who considers using different solution languages to attack different problems.

Adams spends several pages documenting the biases and habits of thinking we have that prevent us from considering all possible solutions to a problem. As he addresses each of these habits he gives suggestions as to how we might work around them.

Next he goes on to cover different thinking languages we might use to attack problems. He then covers ways of getting past our emotional and intellectual blocks as well as dealing with the issues that arise in group and organization settings.

As I said at the beginning this is not a book I’d recommend to learn how to create binary trees more efficiently. However it is a book I’d recommend to help you to learn the more important skill of knowing which approaches may lead you to a good solution to the problems you’re trying to solve.

4 out of 5 stars.

Puzzle

Consider the following sequence of numbers:

1, 1, 4, 9, 7, 25, 10, 49 . . .

What should the next number in the sequence be?

Answer in next month’s newsletter

Event Calendar

May 14 2025 – Detroit Tech Watch Meetup – David Baird : “Vibe Coding: Beyond the MVP”

RSVP and more details

May 21 2025 – MIDOTNET – Don Ward : “Beyond Code: Hidden Skills Every Software Engineer Needs”

RSVP and more details

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.

Dear Impractical Engineer:

Letters To (and sometimes from) The Editor!

Dear IE,

I am currently in a position that doesn’t offer me much room for advancement. What should I do?

Anxious For Advancement

Dear Anxious,

What you should do depends on a number of things. I can’t give you a clear cut recommendation but I’ll try to list out some of the things you might want to think about as you make your decision:

1.) Is the situation likely to change? Some shops reorg every couple of months and some have never changed in all of recorded history. If things are likely to change you may want to hang around. You may get the room for advancement you’re seeking just by staying put.

2.) How do you like the folks you’re working with? 8 hours a day, 5 days a week is a lot of time to spend with people and if you don’t like the people you’re working with it can be a major trial. On the other hand, moving to a new place can introduce a whole new group of people to get on your nerves. Advancement is important of course but remember having coworkers you can work with is pretty important too.

3.) Is there any way you can create your own advancement? I had a good friend who was talking to the CTO. The CTO expressed interest in creating training for the developers at the firm. My friend, wisely, said to him—“I can take that on!” He took on creating a training program and did so well he became head of the IT Training Team! Sometimes advancement is just a matter of helping your company to solve a problem!

I know from experience that feeling stuck in a dead-end is no fun. Good luck!

Want to submit a letter to the Impractical Engineer? Send your missive to the editor.

Tech Books We’d Love To See