General Engineering Introduction/Solve Problems

From Wikibooks, open books for an open world
Jump to navigation Jump to search

quiz

“It's broken. “ These are the words of freshman engineering students looking at their instructor. The instructor's eyes twinkle but say nothing. Anticipation, excitement builds, the question “Why” starts to float unheard in the air. Will engineering life begin?

Mention problems and freshman students will think of solutions. A competition may be triggered with the winner fixing it first. Problems are immediately followed by solutions in presentations and notebooks. This is a technician attitude, not an engineering attitude. Engineers don't fix things. Engineers solve problems. There is a huge difference.

Engineers live for problems. Problems turn into projects. Engineers don't say “It's broken” to other engineers. The words “It's broken” hand off the tension, the responsibility, the engineering opportunity to someone else.

Engineers spend much more of their life in the tension of problems. The engineering competition triggered is who can think up as many totally different, possible, wild, crazy solutions ... multiple solutions. There is no "fixing" because typically the object doesn't exist yet. The first solution may not be the best. The problems may not have solutions. The problem may have never been solved before. There may be a problem with the current problem thinking. Below are details that illustrate technician and engineering troubleshooting differences.

The mere formulation of a problem is far more essential than its solution … 
To raise new questions, new possibilities, to regard old problems from a new 
angle requires creative imagination .. Albert Einstein

Scope Differences[edit | edit source]

Big problems involve lots of engineers and require managers/project managers/engineers coordinating teams of engineers. The goal of this course is to teach engineering through small problems which can get confused with technician troubleshooting.

Design Drift[edit | edit source]

Technicians can fix with solutions such as shake it, hit it, take it apart and put back together, stick a pen in it, use chewing gum, wrap some wire around it, drill out the hole, spray WD40 and slap duck tape on it. Technician fixes cause the functioning machine or process to drift away from the original design. Engineers fix the design itself. Engineers understand that after 25 years of fixing, the fleet of identical units is now unique. Retrofitting the fleet will first involve inventorying the evolved chaos and finding the most cost effective common design once again.

Speed[edit | edit source]

Technician pride is associated with how fast they can identify and solve the problem. Engineers want to savor the problem like a wine taster smelling but not drinking. Choose inspiration, not speed. Choose elegance not utility. Play with all the tools, not the one tool that usually works. Explore all possible solutions, enlarge the scope (hardware, software, expectation, procedure). Engineers can not be limited by training and certification.

Ease of Repair[edit | edit source]

Technicians complain about how hard it is to take apart, how much time is wasted and question any new tool, jig or form that is required. But technicians don't have to assemble in the first place or plan failure modes. They don't have to worry about recycle and/or salvage. Technicians are not educated on the entire design scope. Technicians don't have to worry about selling the design to investors and government regulators. Engineers are responsible for everything. Ease of repair is not the only concern.

Troubleshooting[edit | edit source]

Technician and Engineers troubleshoot in overlapping, similar ways. For this reason the public thinks "Engineers fix things." The reality is that enginers "can" fix things, but you won't want them to. They are more likely to break it completely. Engineers don't fix because they are have not practiced and gained the expertise of a technologist. If engineers do fix, they will fix not just your problem, but the entire world's various versions of the problem ... and it might take a year.

For example, a technician can usually swap. An engineer can never swap. Swapping is a troubleshooting technique of technicians. Engineers can not "fix" problems with bubble gum because they are designing things that don't yet exist. Technician expertise grows out of work-around solutions. Engineers mine this expertise, but can never implement a work-around solution. What do engineers do instead? Write about the small problems in the engineering notebook. Then they model the problem in software. Get the software to replicate the problem. What does the technician do? Chase power through the circuit; push on the circuit board with a stick to see if anything is loose; wave hand over the circuit to see if any chips are abnormally hot or cold; reflow all the solder joints. It is always helpful as an engineer to learn technician troubleshooting, but this is just one stomach of the engineering cow.

Little Problems[edit | edit source]

There are big problems and little problems. Big problems involve other people. Video is from russian engineers. Little problems are typically something small that triggers a feast of solutions (glue, weld, start over, must be something better to look for, etc.) Don't choose one solution, test it, test another and compare. Find the best solution. List the possible solutions. Write about them. The writing could inspire someone else.

Attitudes[edit | edit source]

These are some other attitude traits of engineers versus customers:

Engineer Normal
Persistence Either you know or don't
Own the problem Play hot potatoe
Check the facts Make judgements
I can I cann't
Work Hope
Find alternative solutions Jump to conclusions
Keep track of progress Don't know where to start
Check and recheck Make assumptions
Everyone is suspect Repeats what others say
Excited by symptoms Seduced by solutions
Keep Trying Broken
Has to exist Doesn't exist
Look until exhausted Can not find
Involves others Gives up
More work! Excuses
Irritated, in pain Denial
Has Clarity Goals Lives without knowing, in a fog
Dilbert Issues

The seven habits of highly effective people

Creative Thinking[edit | edit source]

"I'm stuck" is music to an engineering instructors ears. An opportunity to begin engineering exists! Don't be surprised if your engineering instructor starts dancing to this song:

Why are you stuck?
I'm just stuck.
Where are you stuck?
I can not get started.
What are you stuck at?
This problem.
What do you expect me to do about it?
I need a tutor.
No you don't .. not if you want to be an engineer.

Most links to creative thinking don't hit this angst head on. There are two questions. What do you expect of the world? Do you want to be an expert? There are frustrations everywhere. Any decent paying job is going to have frustration associated with it. The real question is what frustrations do you want to deal with. Engineers have the most fun frustrations ... they don't involve people!

Big Problems[edit | edit source]

Most engineers want to talk about big problems because engineers help the world in a big way. The following topics are associated with big problems freshman probably will not get involved with. They are included because every engineer needs to be working on both big problems and little problems simultaneously. Big problems equal big rewards, big respect, big service to the world. Freshman engineers are probably more interested in energy than world peace. They may be more interested in transportation and engineering the atmosphere than the environment. Work on both little problems and big problems simultaneously!

Closed Ended Problems[edit | edit source]

Most K-12 labs are closed ended. The teachers have done them before. There are a bunch of instructions with little boxes where answers are to be written. There is one answer that can not be debated. Finding the answer is the most important thing. Engineering can not be learned in this environment.

Open Ended Problems[edit | edit source]

Solving problems requires penetrating traditions, opinions, sorting through numerous extraneous facts and surviving the seductions of solutions proposed too early. It requires persistence. Open Ended Problems are never “finished.” There is always a better bolt that could be found or better bridge designed or better program written. The scope, scale, butterfly effect can make a formerly good solution an environmental toxin. The gun with 45 moving parts can be reduced to 17 moving parts. The life cycle can be shortened, lengthened. The end can be flames, permanent storage or recycle. Open Ended Problems go on forever.

Support Engineers[edit | edit source]

Support systems have to be designed. This means planning how problems are going to be escalated. Who should the problem be escalated to? Support systems typically have a tiered escalation structure. At the first level someone collects information (warranty, purchase date, call back information), checks simple solutions and assigns incident numbers. If they can not solve the problem then it is escalated to technicians, then support managers, and finally support engineers. Depending on how unique the product is, there may only be engineers in the support system. In the case of space vehicles, the first level of support may be scientists.

Many companies charge $200 or more per incident and refund the money if the incident has not been documented (published online). Engineers (you) should have read through the documentation and found the existing solution. Engineers and technicians create the knowledge base or documentation.

In the physical world, spare part inventories have to be strategically pre-shipped to staging areas to support customers. People have to be trained and put on retainer. These logistics are part of engineering.

Support engineers design/grow the support system. Technicians specialize in one area, support engineers are responsible for knowing everything.

Existing Systems[edit | edit source]

No matter what the problem is, become a detective. Separate fact from opinion. Talk to those familiar with the problem. View the problem yourself. Confirm everything everyone says. Suppose for example “the network is slow.”

Like a detective, an engineer does not believe anything a single individual tells them. The “network is slow” could mean anything. There might be 100 problems. There might be none. There may be very minor problems that are not worth fixing. Everyone is a suspect. Everyone has to be interviewed exactly like a detective.

First the problem definition was revised from "the network is slow": A real-time computer was not recording experimental data.

Possible solutions:

  • configure the real-time computer to ignore incoming arp requests
  • disconnect unconfigured devices (in this case color laser printers) from the network
  • stop configuring desktops with two nic cards. Accidentally they could both be activated and top secret and public networks bridged. Purchase separate computers for each network.
  • Move from hubs to switchs.

Of these solutions, the last was the public face of the problem. The other three solutions would have caused too many external political problems and internal issues.

The initial trouble with problem solving is wading through what is true and false about everyone's opinions. Sometimes it is better to assume nothing and begin figuring out what the problem is by isolation. What is this problem not about? List off everything. Circle the problem like a predator stalks it's prey. Start in the physical world.

Wikipedia has a great problem solving overview.

Work on Problems in Your Spare Time[edit | edit source]

Karl Duncker's work continues to inspire people. Many business such as Google are giving engineers one free day a week to work on their own projects. Why? Listen to this Tedx video. This is why you want to be an engineer!