Most rookie FIRST Tech Challenge teams do not lose to a lack of talent. They lose to habits: starting the build too late, never practising with the driver, and trying to build a robot that does everything at once. The good news is that almost every regret a first-year team reports is avoidable if you know it is coming. Here are the mistakes new teams make again and again, and what to do instead.

Start building before you feel ready

The single most common rookie regret is starting late. Teams spend weeks on whiteboard designs, wait for the perfect idea, and only cut metal a month before their first event. A working robot in October beats a brilliant design in January.

Set a hard deadline to have a driving chassis within the first two weeks, even if it carries nothing yet. A robot that can move, turn, and be driven around your build space is worth more than any sketch. You can bolt mechanisms on later. You cannot bolt on the weeks you lost.

Practise driving until it is boring

Rookies underestimate how much match performance comes down to the driver, not the robot. A modest robot with a driver who has run a couple of hundred practice cycles will out-score a clever robot whose driver first touches the controls at the competition.

Build a practice field, or at least tape out the key elements on the floor of a classroom or garage. Rotate drivers early, then commit to a pairing and let them log real hours. Practise the boring things: lining up, picking up, parking before the buzzer. Load shedding will cost you some evenings, so protect the sessions you do get.

Keep the mechanism simple and reliable

Ambition is the third trap. New teams design a robot that scores every possible way, then run out of time and finish with three half-built systems that all jam. Experienced teams pick the two things that score the most points and make those two things work every single time.

Reliability wins qualifiers. A robot that reliably does one job across ten matches will out-rank a robot that attempts four jobs but breaks in half of them. When you are unsure, choose the simpler mechanism. You can always iterate once you have points on the board.

Protect the notebook, the code, and the knowledge

Three quieter mistakes cost teams their season in ways they only notice at the end.

The first is treating the engineering notebook as homework to rush the night before judging. The notebook is how judged awards are won, and judged awards are how rookie teams advance without the fastest robot. Write in it a little after every session, with dates, sketches, and the reasons behind each decision. It is a diary, not an essay.

The second is having no version control on your code. One overwritten file the night before an event can erase a week of tuning. Put your code in a shared repository from day one, commit often, and write short messages so you can roll back when a change breaks the robot.

The third is letting one person hold all the knowledge. If only one student can wire the control hub or deploy the code, your season depends on that student never being sick or buried in exams. Pair every critical skill so at least two people can do each job.

The full rookie-mistake checklist

Print this and check it before your first event.

1. Starting the build too late instead of getting a driving chassis done in the first two weeks.
2. No driver practice, or letting drivers touch the controls for the first time at the event.
3. Over-ambitious mechanisms that try to score every way and reliably score none.
4. Ignoring the engineering notebook until the night before judging.
5. No version control, so one bad file wipes out days of work.
6. Solo dependence, where only one person can wire, code, or drive.
7. Not reading the game manual closely, then losing points to avoidable penalties.
8. Skipping the autonomous period because it feels too hard early on.
9. No spare parts, so a snapped bracket on match day ends your day.
10. Messy wiring that causes random disconnects no one can diagnose.
11. Never scouting other teams before alliance selection.
12. Chasing only the robot game and ignoring outreach and the judged awards.

A South African reality check

Local teams carry a few extra constraints. Imported spares can take weeks to arrive, so order a small stock of the parts most likely to break before your season starts, and budget roughly a tenth of your kit cost for replacements. Plan build sessions around load shedding, and keep a charged laptop and a printed task list so a power cut does not stall the whole team. School terms and exams eat into build time, so map your calendar backwards from your first event and treat the December holidays as prime build weeks, not downtime.

Rookie teams also do better when their members already have coding and building fundamentals before the season starts. Younger students who have worked through structured lessons, whether on a beginner board like the sheenbot∞ or in a class setting, arrive knowing how to debug, iterate, and read a wiring diagram. Our academy and holiday workshops exist to build exactly those habits, so the season is spent competing rather than learning to solder under pressure.

Takeaway

None of these mistakes require money or genius to fix. Start early, practise driving, build one reliable thing, keep the notebook and the code safe, and share the knowledge across the team. Do those five things and you will finish your rookie season ahead of most first-year teams, whatever the scoreboard says. For more practical guides like this one, browse the sheen newsroom.