General Engineering Introduction/Differences

What is different about this text?

Do It First

The engineering narrative presented here is not applied science and it is not making things. The narrative is close to "Engineers solve Problems." Here is the full narrative:

a kid → plays → does things first → designs → solves problems

Doing things first is completely new. The connection to play has been made before. The ordering of design before solving problems emphasizes creativity first rather than business processes. Teaching "the design process" makes sense when introducing a documentation/deliverable standard. In this course, the design model is:

write in an engineering notebook,
make weekly commitments
be accountable in electronic documentation.

The instructor helps students customize the design processes to the problem at hand when choosing the weekly commitments.

Notebook Writing

The goal is to introduce forms or artifacts and grade or assess based upon their use, not totally upon group project success. Individual assessment is done by grading the engineering notebook three ways:

Notebook format
Project writing triplet
Problem writing triplet

There is nothing subjective here. If the triplets meet the critera, they are rewarded. Quantity is rewarded. The more subjective term Quality is rewarded below in electronic documentation.

Electronic Documentation

Most engineering design classes are assessed by the students filling out before and after surveys. Grading is done by group. Most other assessment is moving towards assessing student writing about their work rather than of their work. This course tries to extend the immediate, constant, personal feedback based upon individual work in the electronic documentation. Individual electronic work is graded in three ways:

Wiki Format and Templates used
Individual work planned and actual work done, next weeks work planned
Pushing project forward

Only "Pushing the project forward" is subjective.

Done

The goal are projects that well documented, worked on by different teams of students and grow for years. This means the projects are never really "finished". The goal is to draw a line in the sand, and call a project "done" at the end of about 4 weeks. In this environment, project success expectations are not as intimidating, have a better chance of being negotiated and end up being realistic. Team problems, preferences and logistics all have a chance of being dealt with in a constructive manner. Students need to be given the opportunity to continue on the project or jump to another project.

Most research has shown that small, short projects are better for freshman than one big long semester project. This text is designed to support short 4 week projects. On a semester system this leaves 3 weeks initially for everyone to do the same thing, then about 3 cycles through a four week project. At the end of each cycle, students have to create a “Done” report.

“Done” has been called “final report” but it is not final because students can continue working on the same project if they want. Done has been called “finish” but doesn't connect to the natural expectations students have in their minds that are similar to “final report.” Done includes a final report plus enough information to hand the project to another team of students … without any verbal communication required … think of diy sites like hackaday or instructables.

Students are motivated to fill out the wikiveristy "Done" form in order to get their "pushing the project forward" points and their "project writing" points.

Most students have never experienced an open ended project where a process is in place to enable different student teams to work simultaneously or sequentially on a project. The nearest class to this was at Harvey Mudd College. Students spent several weeks in front of different piles of donated junk. The instructions were basically "Get it to work." After a few weeks, everyone switched piles like musical chairs. Everyone left their notebooks in the classroom. Everyone read each others notebooks to get a jump start. Once a semester a team might get a pile working. The next team's goal was usually to test whether it was working which typically involved breaking it again.

Wikipedia Links

The world is changing. Engineering in its most pure general form is needed more than ever. Content does not need to be taught. Artifacts shared by everyone (archetypes) like a free-body diagram need to be taught for three reasons:

Point out their existence
Experience joy of figuring them out
Remembering key words to type into a search engine

For this reason, links to wikipedia and book links are scattered throughout the text. Previous engineers collected technical books. They did not choose content boundaries. Today's generation is all about creating content boundaries for themselves. Never again are they arbitrarily going to be set by a book. The goal is to support a generation that wants to explore, that wants to remember keywords. Remember wikipedia is now about 9 million pages and the average page is viewed almost 4 times per hour.

The Birds and Turkeys Story

An engineer found that the local hackerspace (not IEEE, not a user group) was celebrating the 60th anniversary of Hamming Codes by reading Richard Hamming's original paper.

There were about 6 people at the hacker space. They were seated facing each other at a table with a power strip down the middle. Each of the 6 people were at the top of their game, holding down jobs, contributing to the rent of the shared space. Some had families. Each had a netbook in front of them. They were reading the paper on line. They started off talking about far they got in the paper, where they got stuck, what was confusing.

The older engineer began talking. The hacker space members glanced at him and started chattering with each other across the table, typing madly at their computers. Then there was a collective silence and all of them looked at the older engineer. Then the cycle repeated itself until no one had anything to say. The older engineer left feeling like he had just fed some birds.

Each person had their own personal take on Hamming Codes. Some understood little at the end. Some understood a lot. They trusted the information they found on the net. They trusted that the collective mind in that room could figure anything out. They didn't feel obligated to understand everything. They had boundaries that the older engineer did not have.

The older engineer felt like the old myth of domesticated turkeys drowning because it starts to rain and they aim their mouths at the sky. The older engineer feels obligated to absorb any information they stumble across. The boundaries are set by the article, not something else. What set the boundary of the younger people?

These boundaries can be seen on the web. What web sites are popular? What are their names? What has a wiki page? The boundaries of younger people seem to be set personally. Brains are being structured to hold searchable keywords (artifacts, archetypes). Not content. Do we really want to answer the boundary question?