I was wondering if any teams had a version of an engineering notebook that worked. I tried to set something up for my team where we had an online folder for each subteam, but it didn’t end up working out too well. Are there certain requirements that you have for what you put in the notebooks? Do you have a place for each subteam? Do you fill them out as an individual or as a group? I’m at a loss on how to get the team engaged in doing one, and have the information that is in it be valuable for future team members to use.
A strategy that worked for us was to hold a weekly meeting that summarized what was done in the previous week and assigned tasks for the upcoming week. A slideshow was created with all the details that was then shared with anyone that couldn’t attend. The slideshows then became the material that was inserted into the engineering notebook. Starting with one that is done by a mentor can help get it going for the first year. Once students have a model and they see the value in something they are more likely to take ownership of it in the future.
Here is our notebook from this year:
https://drive.google.com/a/tldsb.net/file/d/1tHep5arpeJ3sQN_zaU0omEirD10Q6Fps/view?usp=sharing
We won the industrial design award at Georgian College and are pretty sure this document helped with that.
So, I think this is really the core issue. If folks aren’t engaged in the underlying need to track the info, you’ll be fighting tooth and nail no matter what tool you choose.
First is to understand what info is needed, which is largely driven by who will consume it.
In general, for tracking requirements internally in the team during the season, we use whiteboards. Lots of whiteboards. We can never have enough whiteboards.
We draw design ideas, want-lists, tables of data, flow diagrams… anything and everything. It’s mutable on purpose - requirements change rapidly during the season. The most “correct” version is the one currently written on the whiteboard. We’ll often go around taking pictures of whiteboards to help document current status, or save info before we erase and write new stuff - these all get dumped into a google drive folder and frankly rarely get looked at. Whiteboards work for us because anyone can rapidly use them, it’s really easy to walk over and point to what you mean, and the results are large and public and visible and hard to ignore.
Certain subteams maintain their own tools for issues list tracking, change management, etc… but all these derive from whiteboard data.
Now, separately, when we look to publish a fixed hunk of requirements for someone outside to see, that’s a separate document and separate process. This makes sense because it’s also a separate audience - people who weren’t there with us during the build season, and didn’t see the evolution of the whiteboards. This activity of distilling down to a concrete and nicely-formatted set of requirements is a separate technical writing task usually done by one or two people - not a whole-team effort.
EDIT: @gerthworm nailed it, engagement & audience is key
Engineering notebooks are first and foremost for the engineers themselves.
These engineers are in training; they don’t know what’s important to write down yet. They need suggestions from more experienced engineers in real time about what they should write down, then reinforcement that it was a good thing to write it down from another party afterwards.
I am a professional Engineer and still barely use a formal notebook, instead prefering digital tools.
Design reviews, technical binders, progress reports - those are for other people.
“Progress reports” or “Design Reviews” feel silly when you’re presenting them for the mentors who are in the room when you built the thing.
Can you identify an audience (media team, parents, rookies, key title sponsors) to direct the reports or reviews towards? Even better, can that sponsor provide feedback and guide the students towards providing valuable information?
99% of the time my students don’t realize exactly how much technically detailed knowledge they’ve used in delivering their robot, don’t remember all the technical things they did that week, DEFINITELY can’t verbalize any of it while under Stereotype Threat*, and bottom line just don’t realize how much they have to brag about. It’s just normal for them to be achieving so much! Having the notebooks to refer to while preparing for a Design Review can be helpful here.
Some leading questions during Review can help pull this out, as can suggestions about “what did you write in your notebook about this topic?”
(but be CAREFUL, it’s very easy to communicate “you did it wrong” if you didn’t tell them to write anything down while you solved the problem earlier that week & your tone is off - it can discourage rather then encourage. High schoolers are insecure, my high schoolers have often been told they’re dumb by people they trust, “I did that wrong” quickly becomes “I’m dumb just like _ told me” and spirals)
Tangent on vocabulary
Many of my students have vocabulary several grade levels behind where mine was at the same age - that’s okay, they’ve just been put through different experiences and need time to finish learning vocabulary. Normally it only takes mentioning the right words ~twice and then they are good the rest of the season.
I’ve adjusted my expectations to reflect that reality and accept all types of language in our reviews, with an ear towards suggesting the Technical English words they’re looking for when it comes up.
*If you’re unfamiliar: https://en.wikipedia.org/wiki/Stereotype_threat
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.