Bob Schmidt - The Dog Barks When the Phone Rings: An Engineers Guide to Solving Problems

The Dog Barks When the Phone Rings: An Engineers Guide to Solving Problems

Bob Schmidt

Kokomo Press, LLC

First published by:

Kokomo Press, LLC

P.O. Box 3593

Carmel, Indiana 46082, USA

http://www.KokomoPress.com

First Edition

Copyright Bob Schmidt, 2013

All rights reserved

Publishers Cataloging-in-Publication data

Schmidt, Robert Warren.

The Dog barks when the phone rings : an engineers guide to solving problems / Bob Schmidt.

p. cm.

ISBN 978-0-9887476-0-9

eBook ISBN: 978-0-9887476-1-6

Includes bibliographical references and index.

1. Engineering. 2. Problem solving. 3. Engineering systems. 4. Mechanical engineering. 5. Electrical engineering. 6. Computer engineering. I. Title.

TA147 .S2 2013

620 --dc23

2013902479

The author and publisher of this work recognize and support valid fair-use exceptions for copyrighted material. Permissions may be obtained by request through http://www.KokomoPress.com.

The scanning, uploading, or distribution of this entire book without the permission of the publisher (also known as piracy) is illegal and definitely unfair.

Table of Contents

)

About the Cover

The cover art for this edition was created by Amber Schultz. It depicts the moment of panic, which can strike a problem solver, when a new and particularly difficult problem is first presented.

You have probably never been standing high up on a ladder, just trying to clean some leaves out of the gutter when the earth began to shake, and your ladder fell away. With only one hand having a grip, the gutter began to fracture, and a river of lava opened up beneath you.

Okay, neither have I, but some problems definitely feel like that at the beginning.

The blue sky and clouds come from a photograph. They are intended to represent a counterpoint of calm and peacefulness.

It is my sincere hope you can learn some methods from this book to increase your moments of peace and greatly reduce those moments of panic.

Introduction

Listen, he said.

The storyteller dropped his voice a little below its usual quiet calm. Without even realizing it, we all leaned in a bit more to make sure we could hear.

This was going to be another classic. It would be one of those tales of puzzle and personality; a story that would have a solid moral if we could dig deep enough. The tale would save us from some weakness or mistake of our own if we could just listen closely enough, and learn from the follies and misadventures of others.

I have come to believe that all professions share these nuggets of wisdom, passed from generation to generation. They are part myth, part fact, and a bit of fancy, all woven together in sturdy tapestry by the wisdom and experience of the teller.

We laugh at the humanity, recognize our own traits in the stories, and carry them with us to each new job. Sharing the stories and jokes, we spread them like a virus, mutating and molding them to the new audience.

Always there is at the heart of each story some inner meaning, some lesson or moral that we might not even recognize in the laughter and delight of the story itself. But eventually (hopefully) the wisdom of the tale leaks into our own efforts. If experience is what we get just after we needed it, then these stories pay it forward, giving us the benefit of somebody elses experience, without all of the pain.

Someone once told me that a parable is an earthly story with a heavenly meaning. It is from that idea that I have come to refer to these tales as parables in problem solving.

This kind of spirit and passion (or is it an affliction?) infuses certain practitioners of any profession or hobby.

Because I am condemned to a lifelong love of things electrical and electronic, that is where many of my stories live. But if you are quiet and contemplate the stories for a while, you may find echoes of your own particular passion in these little mysteries, comedies, and tragedies. There may be a moral in here that resonates with your spirit. I hope that you will be as fortunate as I have been to have heard and learned from some of these storytellers.

Listen

Executive Summary

I once had a boss who found my emails to be long and detailed. Perhaps they were even painful. He requested that I put an executive summary at the beginning of any long emails.

He did not want to wade through all the details just to know whether he needed to take an immediate action.

This was a very good idea. It forced me to think hard about the shortest possible message I needed to convey and to quickly discuss the main point I needed to communicate.

So here is the short story: I want you to master a basic problem-solving method, which could also be called the five questions:

Wow. That looks pretty basic, eh? If you are an engineer, you have already gone through at least four years of education doing these same steps over and over again. If you are an engineering student, you are in the middle of a lot of classes covering these same techniques. The names of the variables and constants change, but the methods are pretty consistent. For lots of engineering and science problems, you are really just writing down equations (rules) that you have learned, filling in the constants and variables (stuff you know) then doing the math to solve for an unknown quantity (stuff you dont know).

Design is very much a human activity. Like all human activities the process is subject to error. When we design systems, we are solving problems and also creating new problems. Some problems will be the result of old mistakes that have been made before, while other problems will be new.

Even very good designs might have components that eventually fail. This creates new problems that we should solve.

The key idea you need to take from here is that debugging (or troubleshooting, or fixing stuff, or whatever you want to call problem-solving) is an intrinsic part of the design process.

When I was managing an electronic hardware design team, I told them I wanted the team to make lots of mistakes, but I wanted them to make those mistakes quickly. Then I added that I wanted those engineers to find the mistakes and fix themfaster.

Asking the five questions is great for solving technical problems. It works extremely well on complex systems of machinery and electronics. This method can produce spectacular success in diagnosing the most subtle bugs in computerized (virtual plus physical) systems that confound many projects. Occasionally, these methods can be used to diagnose very difficult health care issues.

(Disclaimer: Unfortunately, these methods become unreliable in dealing with human type people problems. Sorry about that boss. Nothing in this world is one-size-fits-all.)

If you are a non-technical manager, you might not have enough time (or enough interest) in all the details to read this entire book. Let me save you some time and effort.

You could possibly get maximum entertainment and minimum learning by reading this executive summary, then skimming through the remainder of the book.

If nothing else, please read to get the central story. Also, as you flip through, look for the universal Fast Forward symbol: