General Engineering Introduction/Tutorials

Actual tutorials exist!

Everyday, simple things, common sense things to one person are mysterious to another. Someone that can not name a screw driver is going to be mystified by all the tips. Playing with PID software is a mystery to those with out a controls course. Good tutorials require writing skills. Starting a tutorial does not.

Project Scaffolding

Scaffolding is where the instructor lectures to help push a project forward. The instructor may just write on a board. The instructor may pass out a handout or provide a hands on activity. The instructor may do this individually, to a team or an entire class. The point is that the instructor does so without creating a tutorial. The person or teams that benefit from this exercise are expected to turn the lecture into a tutorial.

The goal of project scaffolding is to get up to speed as quickly as possible in order to be productive pushing a project forward. Without scaffolding, most students will spend all their time learning about a project rather than doing a project.

Most freshman and sophomore engineering projects are not about scaffolding. The goal is to teach design and problem solving. Content is there only to serve these objectives.

Besides instructors, other engineers and even students may have a bit of gold to hand you that will push your project forward. Your goal is to capture, own and then deliver to the world this information. Otherwise the gold stays in people's heads, bouncing from brain to brain verbally and subject to the limitations of space, time and context.

For example, an instructor personally shows you how to test whether an arduino is working or not. You can turn on the ardenialin and record every keystroke, tell the instructor to slow down, force the instructor to talk to you rather than whiz around the keyboard. You can tell the instructor to show you what is possible and you will figure out the details.

What you should not do is say to yourself "Wow, the instructor knows this, therefore I don't have to. I can ask again when I need to do this again." Do not say to yourself "Probably everyone knows this, I am an idiot." Do not say to yourself "All engineers know this, so I can ask another instructor or tutor." Engineers do not participate in the group think, the group mind, group knowledge. Group think blinds an engineer. Group think makes all engineers the same. Mediocrity begins to dominate.

Do not plan on becoming an engineer by leveraging collective wisdom. When an engineer is talking to you, treat it as a gift ... a unique gift that only the engineer knows and is imparting to you. If anyone scribbles something on the white board and nobody in your team writes it down ... whether right, wrong, on target, useful or not. It should be recorded and ultimately in the team documentation.

When Scaffolding and tutorials are bad

When a problem is very stubborn, it is best to not look for tutorials or scaffolding. Stubborn problems are those that other engineers have worked on unsuccessfully. Listening to their stories, reading their attempts can infect the engineers new to the problem with the same virus that is blinding the previous engineers. When the goal is something radically different, engineers from radically different backgrounds are needed ... without the current scaffolding/tutorials. On the otherhand, if the goal is reverse engineering, if the goal is replicating then scaffolding and tutorials are absolutely necessary.

The really artistic engineers will refuse to document because they feel the next engineers should be free to create something entirely new. However this is not the prerogative of an engineer. It is the prerogative of the client .. the person paying the engineers salary.

When you don't know how

Rejoice. You are going to get to learn something new. You are going to expand your tool set. You are going to become a more valuable engineer. You may get a chance to do something first.

If you don't know how to do something, you should expect an excellent tutorial to exist on how to do it. If the tutorial doesn't exist, then it is the world's problem not yours. And further, you have the opportunity to improve the world by creating/editing the tutorial.

Example

Suppose you know how to hole through solder, but don't know anything about surface mount soldering. What is going to be more valuable?

a random youtube video on the subject
or a video showing how to use the equipment your school has accumulated

Your goal is to create a tutorial inspired by the random youtube videos. If one has already been created, your goal is to improve the tutorial or race through it.

Excellent Tutorial

An excellent tutorial looks like a tree. You start scanning at the roots and work your way up to a leaf. An excellent tutorial means you move up the familiar trunk into familiar branches until you find something new. You slow down and skim to a leaf. Perhaps the leaf is not where you wanted to go. You back track to the familiar, then climb towards another leaf. You continue identifying what you know you don't want to know until you have found what you want to learn. Then retrace your steps between the familiar and the destination leaf. Edit the tutorial using wiki mark tools as you work through the tutorial ... not afterwards.

Wikiversity Tutorials

Tutorials are articles in wikiversity. Wikibooks contains articles grouped into books. The General Engineering Tutorials are categorized on wikiversity. The best practice way to create tutorials is documented on wikiversity.

Not Text Books

Don't try to write a text book. Don't try to trace back to original root philosophical concepts. Don't try to be perfect. Record what was done by your team that led to success. Don't worry about your audience. Write for your instructor. If your instructor can follow it, you should get a good grade. Let other's that follow your steps improve the tutorial. Don't write for yourself. Your logic, your symbols, your gifts may be unique. Your instructor will have a better idea of what "complete", "detailed" and "standard" is.

Don't believe that text books have chapters that are logically related. Text books are often a survey of topics held together by a very thin logical thread that orders the sequence. Tutorials should not be treated this way.

Treat text books as a survey of topics just like search results. Jump to what seems relevant and then begin reading. Write down words you don't understand. Begin sorting and categorizing the words as if they are clues to a mystery. Build links to more detailed explanations.

Reuse

Tutorials are about science, math or technology. Tools and their use are part of technology. The same math is used in a variety of disciplines just like tools are used in a variety of different ways. The engineering project is what sets the context of tutorial use and reuse. Expect tutorial pictures to be reused and branch from one to other in a many to many relationship rather than a hierarchical tree pattern. Create main article page of steps and then link to the steps. Ideally someone else can create a main article page and include other steps or put the steps in a different, skip the steps, etc. The same steps become building blocks of other tutorials.

Capturing Learning Curve

Not everyone has the same frustrations. Not everyone gets stuck in the same place. It is amazing how different people are. Don't think because you don't get it you are stupid. The world is stupid and prejudiced for not anticipating your frustration. Fix the world. Improve the world. Capture your frustration before you forget it by immediately modifying the tutorial.

Don't wait for the perfection of the world or yourself before attempting engineering.

Organizing Personal Notes

Engineering notebooks are 90% wrong because they document where the engineer gets stuck. Reading engineering notebooks is totally confusing. Someone else's notebook is the wrong place to look for a tutorial.

But engineering notebooks, if written in while doing, will contain all the details necessary to create a tutorial. The tutorial steps are probably not in order. The details are probably wrong on 90% of the pages. The fruit, is probably in one sentence on one page of the notebook. Organizing this is the goal of a tutorial.

Don't make the mistake of trying to make your notebook look like a tutorial.

Individual wikiversity pages contain a reflection or extension of the notebook chaos. Information is better ordered chronologically like the notebook with an extension of pictures and links. A tutorial on the other hand is a list of steps or starting points.

Creating a Place Holder

The exact details of the tutorial are important. It is important to create the best tutorial you can. But the tutorial details are not the most important thing.

Most wiki article detail comes from one person. Others come along and make minor edits. The article may sit for 5 years before someone else looks at it. And most likely they are going to link to it.

Make history. Be the first author. Create a place holder for this tutorial by accurately describing the tutorials goals and giving it a relevant wikiversity article name. Don't worry if it is not perfect. Others will fix detail, clarify and add to it in the future.

A tutorial/article takes up space on a wiki. It is linked to. It's usage is charted. Individuals not crowds view it. Start the tradition of adding value where ever you go .. if you can. Both create the original and edit other people's work.