Friday, September 15, 2017

What IS an engineer?

I had an interesting conversation with a colleague the other day as we were talking about engineering in the context of her grade-level standards. She was receptive as I kept tossing ideas her way. At one point she nodded and said, "I think I have to think differently about what engineering really means." She noted she thinks of engineering in terms of building something, like roads and bridges.

Yes, it is. But there are lots of different kinds of engineers: chemical, nuclear, wireless, landscape, environmental, railroad, industrial, and the list goes on and on. Even this definition is somewhat limited in scope.
One of the reasons this matters is because of the current interest in STEM and STEAM. The "E" represents engineer and so often educators, parents, and students have a narrow spectrum of associations with that term.

There was a time in my life I worked as a software engineer. I wrote code to solve particular problems and we followed a specific design process to make sure the solution worked as
expected. We called it a software design process even though it looked very much what people today are calling an engineering design process.

I would spend time with a customer and play a version of "20 Questions." Most customers had an idea of what they wanted the system to do, but it was vitally important to ask lots of clarifying and probing questions to make sure I understood exactly what they thought they wanted. Whether I worked alone or with a team, one of the next steps was to create a preliminary design document that would lead to a requirements design document that would lead eventually to a functional design document. Every step was clarifying the problem and the intent of the solution. Through those design document steps, we would brainstorm options, check them against the parameters, and analyze them before we selected what we thought would be the best possible solution. The functional design document enabled us to think through as many "what if?" scenarios as possible.

If the functional design document got the go-ahead from the customer (or whoever it was responsible for the green light), we would build a prototype and test it. The prototype and testing enabled to find out what we'd missed in our analysis but also test our hypotheses for our functional design. The iteration gave us the opportunity to fine tune our design solution.

When we had a working version of the prototype, we would put it through its paces with the customer. If the prototype performed as the customer hoped and expected, we were usually 90% to the end of the project, and sometimes closer.

The crux of engineering is problem-solving. Maybe this video will help.



We can go another step to compare the scientific method and the engineering design method. The presence of an iterative process is important because it serves to remind students there are
opportunities to check your work before proceeding.

I hear you. You're thinking, "Yea, yea, that's all fine and dandy for science and engineering, but I teach. . . ". STOP right there. Look at the engineering method steps again. How might a student use that as a framework for figuring out how to solve a math problem? Or deciding on an approach to writing a paper? Or analyzing a text? Or thinking about a particular historical event or the characteristics of a culture in social studies? The questions change and the iteration will look different, of course. Once students become
accustomed to a format, whether electronically or using a notebook or journal, it will be easier to ask students to use the design method for any and every class that might require a bit more time for researched problem solving.

Some steps will not be applicable for all problems. Some steps will require more information than other steps. Some steps will lead the learner to figure out something faster than expected. They should be expected to document their thinking for future reference regardless, especially if they keep their work in a journal. They will want to see how they have improved their learning using this particular methodology and how it can be used in other situations.

I suppose it's an oversimplification to say that an engineer is a student of any kind though, in many ways, it's true. But it's not an oversimplification to say that an engineer is a problem-solver who needs to be able to thinks critically and collaboratively with others, and is able to communicate ideas and solutions to others.

No comments:

Post a Comment