411 REFERENCE · Wikibooks
General Engineering Introduction/Tutorials/quiz
Reference material by Wikibooks contributors. This retains its source identity and is not 411 news reporting.
{Scaffolding is where teachers:
|type="()"}
- ask you to learn on your own
- where you develop tutorials
- where you read tutorials teachers have written
+ where you listen to a lecture and try to turn it into a tutorial
{Scaffolding is different from a tutorial in that:
|type="()"}
- was created by someone not on a project
+ was created outside the project context or peripheral to the project
- is something widely known by most students
- is something all students should know
- is something widely known by most engineers
{Scaffolding could come from:
|type="[]"}
+ teachers
+ engineers
+ other students
- team mates
{If scaffolding is wrong, if it doesn't apply to a project
|type="()"}
- it can be ignored
+ it appears in project documentation rather than tutorials
- is included in the finished tutorial
- it still needs to be looked up and referenced
{Scaffolding occurs when:
|type="[]"}
+ personally shows you how to do something
+ instructor lectures to the entire class
+ someone draws on the white board during project presentation
+ someone says "look this up"
{The best response of a student to an instructor sitting next to them and showing them something is:
|type="()"}
- take detailed notes
+ write in notebook only what is being learned personally
- instructor can duplicate this at any time, so I will just learn what I can
- everyone seems to know this, I am an idiot
{The group mind is not scaffolding. Why?
|type="[]"}
+ If engineers where homogenized, they would all produce the same solutions.
+ Scaffolding implies everyone is learning the same thing.
- Everyone knows, therefore scaffolding is not needed.
- Most everyone knows, so anyone can be asked anytime to learn.
{Scaffolding is always good and needs to be recorded.
|type="[]"}
- true
- false
+ only if pursuing scaffolding has been approved by client
+ only if it happens naturally during a presentation
{Scaffolding is the prerogative of the client.
|type="()"}
+ true .. you could have been put on the project precisely because of what you do not know
- false .. the engineer must decide whether they need to leverge existing knowledge
{Including scaffolding in project documentation is the prerogative of the engineer.
|type="()"}
- true, it may blind the project
+ false, any scaffolding by someone outside the project in response to hearing about the project, whether used or not needs to be included in the project documentation.
{Looking at past documentation is something that should be negotiated with your instructor.
|type="()"}
+ true, your instructor has read past documentation and may want to compare what you design with previous designs
- false, you need to see past work in order to improve upon it
{Letting the materials at hand inspire is bad for engineering for what reasons?
|type="[]"}
+ No documentation before, during. After documentation lacks enough context to be useful.
+ Requires a junk pile that is not replicatable or sustainable
+ Does not promote team work, just one leader and everyone else trying to figure out what is going on.
+ There is no design
{Prototyping Engineers often work without documentation because:
|type="[]"}
+ Goal is to create the first version as cheaply, as quickly, as simply as possible
- They are a special type of engineer
- Documentation cripples their productivity
- They are generalists and can do anything
+ They are more often very narrowly focused with technician like expertise
{When asked to do something you don't know how to do
|type="[]"}
- Panic, worry and try to find someone that does
+ Ask your instructor "Should I learn on my own or find a tutorial?"
- Worry about breaking, destroying things
+ Worry about safety, security, politics
+ Ask your instructor "Can I take it apart to learn?"
{Tutorials
|type="()"}
+ Document success
- Document alternative designs
- Document next steps
- Document decisions
- Document testing methods, test results
- Document failures
- Document frustrations
{Excellent Tutorials
|type="[]"}
+ short on words, long on video and pictures
+ offer steps using pictures in the frame wiki tags
- like a text book
- full of polished english
{Reuse
|type="[]"}
+ means leveraging the collective mind
+ means describing how every day objects were used in a different way
+ means describing easily available materials were used creatively
- means recycling
{Frustrations
|type="()"}
+ are worked through by creating lots of steps/pictures/video's
- are documented by a narrative in the tutorial
- are expected to be shared by everyone
- cost a lot in terms of time and therefore need to be included
{Tutorial can not be copied out of a Notebook because
|type="[]"}
+ Notebooks are 90% failure documentation
+ Notebooks are chaotic in terms of the order in which steps are tried
+ Notebook success descriptions do not fill up notebook pages
+ Details are scattered through out it
{Tutorial as a place holder
|type="()"}
+ Tutorials may not be perfect, not contain the best pictures, not be in exactly the right order
- Tutorials have to be perfect before being turned into an article