General Engineering Introduction/Notebooks/Problem Writing
Engineering moves through playing, doing it first, designing (doing) and finally to problem solving.
Before there are problems there are issues. Before issues, there are unknown pains, unknown improvements to the efficiency, productivity, and general quality of life. When an issue emerges, everyone begins to become aware of it. A language evolves that gives it a name. Consider farming. The issue emerged that a human can only accomplish so much during the day. The issue turned into a goal and was given words: "How can we produce more food with less human effort?" At this point it is still an issue because nobody owns the problem.
Problems have an owner. Someone has a problem. Everybody has issues. Engineers love to own problems. Engineers try to identify issues and turn them into problems. Most people avoid issues and think engineers are a bit perverse, a bit insensitive, and should mind their own business. Engineers should stop trying to change everybody and everything.
Mature engineers also know when they have taken on too much and need to leave issues alone for other engineers.
Non-engineers ignore and live with issues. They refuse to name them and list them in their notebook.
Owning a problem does not mean the engineer is responsible for fixing it. Owning a problem means defining the problem without visualizing the solution. The goal is to find all the tension, all the frustration, all the fog and confusion and describe the problem in a way that inspires many solutions.
Learning to own the problem without even thinking about solutions is the opposite way most of us are raised. Most of us think of problem/solution pairs and want someone else to list them for us. Engineers don't create the problem/solution pairs. Technologists do. Problem/Solution pairing is the result of experience and expertise with existing equipment. This has nothing to do with engineering.
Problems can be large and involve hundreds of engineers. Problems can be small. Large problems are known by everyone, they define the project, they involve customers.
Big problems are not often negotiated or defined by engineers. They follow a business process that starts with issues. Sometimes a “project” will evolve outside of the big “problem” context. Typically this is a non-engineering project. An engineer will begin the "project" by discovering the project's problems. Engineers stay out of the blame game. A problem statement is negotiated, engineering requirements are documented, alternative designs are created, etc. There are business process that engineering projects/big problems go through. Mature engineers talk about the business process associated with “big” problems, because this is ultimately what determines success.
A problem is not personal. Some students walk around saying '"My problem is "I am not good with cars." ' This is not an engineering problem. Personal fog or confusion may a personal problem, but it is not an engineering problem. An engineer never turns personal ignorance into a problem. If you don't know something, and there is not a tutorial that will teach you quickly, then it is the world's problem, not yours. Be an engineer. Create the tutorial. Solve the problem.
An engineering problem is outside of oneself. A little engineering problem is something one stumbles across, not something one plans. Engineering problems are discovered in the process of doing something. The unknown is an opportunity, not a problem. Engineers loose respect when turning things into problems that are personal.
Little engineering problems are those that can be discovered and solved by one engineer in an hour. Dealing with problems is what gives engineers the reputation of “fixing” things. In reality, engineers only fix what they are creating. Technicians are much better at fixing things in general. Engineering problem solving most of the time is not “fixing things.”
Little problems can grow by involving other team members. Enlarging a trivial problem can increase one's reputation if the problem is hard (outside of oneself, not associated with people), well defined and offered with no solutions. This kind of problem is food to engineers. The down side is that if the problem is trivial, problem enlargement can reduce reputation. If the solution is in another engineer's head and you haven't learned to respect that engineer (or talked to them), then your reputation goes down.
When a technician/technologist gets frustrated, they have someone to blame .. the engineer. And technologist/expert is almost always right. There usually is a problem with the design. An engineer has no one to blame.
Engineers have an ethical and legal obligation to refine the problem solving process instead of blaming. This is what keeps engineers individually out of law suites. Projects are collections of problems that turn into the project requirements. Designs are solutions to the problems. Each of the potential solutions may need to be checked out.
Underneath all of this is a frustration and tension that an engineer has to deal with. The goal of an engineer is to learn to live with this frustration. The first step in engineering problem solving is learning to manage frustration.
The problem is the goal, not the means to the goal.
The problem are the symptom details, not what caused the symptom, not what the solutions might be.
The problem is the issue, the possibilities and the hope, not the pain of change.
The problem is form and function expectations, not specific material lists.
The problem is the description of input (unit test in programming projects), and the expected output, not the algorithm.
A problem can not be associated with your learning curve. Instead focus on these three things:
- All of us have a fog of uncertainty, frustration and limited skill.
- The goal is to know yourself ... know what you don't know
- Everyone experiences frustration, figure out how to be inspired by it.
If both your learning curve and uncertainty drive your problem writing, you will earn respect among engineers … but not among the rest of society.
The world has problems, not you. If you can not understand, it is the world's problem. Make it the world's problem.
Don't express your learning curve or uncertainty. Leave blanks during presentations that stimulate questions. Use the questions "Does anyone here know????" to explore the scope and scale of your inadequacies. Be prepared to learn in the moment if there is an answer. Hope that nobody else knows. Maybe nobody else has any ideas. Maybe the issue really is so edgy that you are really getting paid for doing something first for the world! Your adrenaline should start flowing! This is what makes engineering presentations so important!
The problem must be described in terms that earn respect of society. This means you are limited to a physical, process or system description that has nothing to do with yourself. Get excited!
A problem is not an engineering problem until there are multiple solutions. Brainstorm all possible solutions. List them. You are not brainstorming unless there is more than one. Just name them. Don't try to flush out the details. Don't name trival ones like "give up", or vague ones like "find something else."
Listing one solution is not an engineering activity. Problem/Solution pairs are something technicians love to read, not engineers.
Don't present any solutions emerging in your head. Write them down, but don't talk about them. Talk about the problem. Let the world vote. How many are identical to yours? How many are totally different?
Don't feel inadequate if you can not come up with solutions. Maybe the problem statement is not perfectly formed yet. Present problems to the class/other engineers. During the presentation solicit, encourage and record solutions from the audience (which will include your instructor). Don't present a trivial problem such as "where do I plug it in" and expect to gain engineering respect.
Outline what the software objectives are in terms of input and output (unit test). Solutions are algorithms ... different algorithms can perform the same unit test. Visualize algorithms. Name them. List them the names, don't write the solution until the test has been written.
Solutions don't have to be realistic but they have to be plausible.
There are three parts to testing. One is describing the test protocol.
The second is physically performing the test.
The third is analyzing the results and deciding whether to redefine the problem, perform another solution test or come up with another solution. If this is done right, a path or direction will emerge in the solutions. When this happens, an attempt needs to be made to look down the path to see if there is success at the end. Otherwise a lot of time/money can be wasted.
A technologist stops at the first that works. A technologist will use bubble gum, hay baling wire, soda cans, WD-40 and duct tape to solve most problems. Their goal is to fix, not explore all the possible ways to fix. Do not expect to get credit if the problem is announced solved after just one test. You can get credit if a single test results in a restatement of the problem and/or inspires more solution designs.
Problems can occur at any time. Normally they occur during doing (design). In all cases they will occur while or in the middle of Project Writing. In all cases they will occur while working on a project.
Use the GoingtoDo, Doing, RANT triplets to record writing about problems.