Technical writing is very useful in both college and life. It teaches organizational skills along with project management. You will need these as an engineer.
A few things (I’m on mobile so sorry if formatting is undesirable) to help with a good notebook (from a consistent award winning organization):
-Read the rubric as a main guide
-Include an in depth game analysis: frankly, you can’t compete in a game you don’t understand, and the judges need to gauge your understanding
-Reflect often: we do them very often, and you should be reflecting at least after competitions anyways. Reflection proves that you’re thinking smartly and rationally, and using your performance to figure out how to improve. Whether or not you notebook you should be doing this.
-Keeping an engineering notebook isn’t about showcasing your success. It’s about failure, too: include your scrapped designs. Talk about why they were scrapped. What makes the new one better? This is all, after all, about learning and the engineering process.
-Have everyone contribute at least SOMETHING. Even if it’s a quick sketch on a sticky note that you include and later improve. Judges like proof of equal work.
-Prove that you understand your design. Math is good for this
this
-Actually talk about your code. Don’t just print it with it’s comments, but explain it Why did you do it like this, why does that method exist?
-Use color, but don’t go crazy either. Be neat, but I’m sure you know that
-Should mostly be hand drawn, but a few images are usually appreciated
Anyone who says that the technical communication skills learned from the notebook are unimportant has never had a job in a technical field. 45% of my time goes to planning the solution, 45% goes to justifying and communicating that solution to my boss, finances, maintenance, and other interested parties. 10% goes to physically implementing the solution.
Be able to do the math.
Be able to communicate your design.
Be able to do it.
The technical communication will serve you a lot more than the wrench turning. The wrench turning is your reward for successfully designing and communicating your solution.
As a former coach and Design award judge, I offer these suggestions:
I think it is very important to brainstorm and document strategies for that season’s challenge at the very beginning of the notebook. I immediately notice notebooks that define and understand the scoring strategies of the challenge.
One area that I closely look at when evaluating notebooks is the reflections after a competition. it is important to understand how your designed and built robot actually performed at a competition. So I believe it is critical that at the first meeting after a competition, the team discusses and documents what went well and what did not go as planned and then outlines what changes they want to make.
And remember, the notebook is not a journal!
After every competition, and sometimes after every match, we have our teams review where they failed, and what they can do from a design perspective to not fail in that same way again. Unfortunately, that rarely made it into their notebook.
Help them set up a reflection page. I like to do (top to bottom)
Stats from the comp (wins, losses, opr, dpr, ccwm), vexDb type stuff
The good: What went well? Did you discover a new strategy, make new allies? Did you get an interview, an award? What good matches did you have? etc.
The bad: What went wrong? Did some system prove inefficient? Were you unable to play against defense? etc.
Programming: How did autons go? What was inconsistent about them? What other higher scoring autons did you see? etc.
And finally, most important:
What’s your game plan from here? When is the next competition. What can you do until then? Be reasonable about what you can actually do in time.
It’s like any basic reflection, really.
should note, saying “my teammate was terrible” should never be in that reflection. no matter how true you believe that to be.
Agreed. Also don’t shove blame to an alliance. You are never perfect
nor should the “we lost because of our alliance partner”… Usually, it means you did not put enough effort to work with your alliance partner as a member of your team.
The reflections should be personal reflections. Never mention someone else as a factor, practice some introspection and examine how you could have done better.
Reflections should always start with an assumption of positive intent of all involved. At work, I always begin any retrospective with what I call The Golden Rule of Retrospectives
" We believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
If someone can not agree with that, they do not participate in the retrospective. “Everyone” in this instance are team mates, alliance partners, competition, refs, judges, etc.
I have a similar philosophy. Based on some facilitation training I’ve had, we call our reflection a “plus/delta” analysis. We first do the “plus” part. What was good? - our autonomous was reliable, our robot didn’t fall apart, etc. Then comes the “delta” part. What could be do better? Different strategy, faster mechanism, etc.
The plus/delta focuses on the positive - what went well/what can we do better and stays away from the negative (this is why we sucked). It has proven to be an uplifting exercise after each tournament. Lots of times, the team comes away thinking the day really sucked - but on reflection find that they can put more things in the plus column than the delta column. Then make an action plan of the things that need to be improved.
The few times I wind up judging instead of reffing, this is also the first thing I look for. It’s even the first thing most kids do when they see the game for the first time… they just don’t write down their brainstorming! Which is what the whole document is about: showing the start-to-finish of how you solved and understood a problem (along with postmortem analysis and refinement later in the season). When doing coaching or pointers, the “how do you win the game” question is the first one I always ask, and the answer to that should be the first thing that shows up in a notebook before any robot design is talked about.
- you get more points for having a bound notebook. I HIGHLY recommend a graph paper notebook for better sketches/data/handwriting/organization.
- use a scrap/brainstorm notebook to jot down ideas @ beginning and decide how you want to organize the notebook, perfect sketches, ect. BEFORE adding anything to the competition notebook.
- give all the details : pics in color, code snippets with HANDwritted comments on the side bc judges often don’t know code, daily logs w team roles/jobs explicitly stated, goals/tasks for the week/month/leading up to a competition,
- color code with a key shown at beginning of notebook for reference.
- while you need proof that all team members are involved in the design process (and the notebook tbh), have 1 person on your team w good handwriting to do most of the writing. When a teammate has something to add, have them send pics and notes to the notebook person for them to add w reference to who’s idea that was.
That’s all I can think of rn. Overall just keep it organized and easy to understand for judges to know you get it even if they don’t know VEX that well.
The bound notebook adds 3 points, and is SPECIFICALLY so that you do not work out all the details and assemble a cleaned up perfect product.
I personally prefer that the notebook have lasting value to the team/organization, and I would consider it worth losing those 3 points to have the most fluid and flexible option possible.
I have been a Design Award judge for the last several years. I totally agree with what you said.
When you say the notebook is not a journal, do you mean that in the sense that you don’t like seeing huge paragraphs, or do you mean that in the sense that you don’t like daily logs and whatnot, or both?
To my understanding, daily logs and the like are very commonly used for patent proofs in real engineering notebooks. Would you be less preferential towards notebooks that do so?
You have to remember that with the rules about bound notebooks they have completely given up on preparing you for an engineering job in the modern world.
Its already a lost cause. If they wanted to verify you did everything by certain dates as promised and prepare you for the real world it would all be done on Git. Or some other version system so you could actually prove when parts were written.
Trust me if someone turned in a git hub link to a latex document. They would earn so many points in terms of documenting who wrote what (because git tracks that) and cleanliness /professionalism the bound notebook bonus would probably be insignificant.
Let me make a note of that in my “bound engineering notebook” currently sitting on my desk. 
Perhaps you should avoid making sweeping statements about what the modern world is like until you’ve experienced it for 30 years or so. My company is as modern as any other, but my inspection notes on welding and coating inspection (while not at neat as a VEX judge would like to see…and I’ve been a judge for several years) are legal documents that can be subpoenaed by the court in the event of a lawsuit. And they will hold up in court better than electronic documents or even photographs, all of which can be altered.
But arguing about “bound handwritten” or “unbound” really misses the point. Here’s what it comes down to: you need to prove to me (the interviewing judge) in less than a minute or two, that you followed the engineering process from start to finish, and didn’t just write up a “professional looking” presentation just before the competition. Believe it or not, the bound-handwritten notebook does that pretty well. Yes, there is a place for professional presentations, and there is a place for personal notes, like a bound-handwritten notebook (or even a file folder in your desk drawer with sketches and stuff). The judges want to see that “working document” not the professional presentation.
I think a git repo with version history shows history better than signed piece of paper. The whole signing and dating thing adds 0 credibility to me. Maybe other judges feel different. When someone asks me what I was working on I show them this. Proof of what I accomplished and when I accomplished it.
**
**
I also don’t like the way physical notebooks lock you into organization. A lot of teams learn lessons over a year. If you start your notebook and organize it by day and instead what to change it to be organized by component, you just cant. Same thing with style changes, you just can’t. If I have a digital version I can make small changes (that are obvious in the source history) as I get feedback from judges.
Look how powerful this is