Building Version Two

Part I: When “Finished” Didn’t Mean Finished

When I first joined FIRST Tech Challenge (FTC), I had a fairly simple picture of how building a robot worked. You start with an idea, spend weeks designing and building it, test it a few times, fix any obvious issues, and eventually, you’re done. Sure, there might be a few tweaks along the way, but once the robot worked, I assumed the hard part was over.

That wasn’t what I found.

As the season went on, I noticed something that initially made very little sense to me. We’d finally get a mechanism working exactly the way we’d hoped, celebrate for all of five minutes, and then someone would suggest changing it.

“Can we make it lighter?”

“What if we changed the gear ratio?”

“Could the intake collect game pieces from a wider angle?”

Before long, we’d be back in CAD, changing dimensions by just a few millimetres, replacing parts that weren’t broken, or rewriting code that already did exactly what we needed it to do. Sometimes the improvements were obvious. Other times, I couldn’t even tell the difference between the old version and the new one.

At first, I found this strangely frustrating. If something already worked, why weren’t we moving on? Why spend hours improving a mechanism that had already done what it was designed to do?

Looking back, I think that was the moment I stopped asking questions about our robot and started asking questions about the process itself.

Why is the first version almost never the last?

Part II: Building the Next Version

The answer, it turned out, was surprisingly simple. The first version was never meant to be the final one.

Its job wasn’t to be perfect. Its job was to answer a question.

Would this mechanism fit the way we imagined? Would it be fast enough? Strong enough? Reliable enough? Sometimes the answer was yes. More often, it was, “Almost.”

That “almost” was enough to send us back to the drawing board.

We weren’t rebuilding because the robot had failed. We were rebuilding because every version taught us something the previous one couldn’t. A mechanism that looked perfect on a laptop screen behaved differently once it was built. A design that seemed sturdy became difficult to repair. Something that worked during practice struggled under the pressure of an actual match.

Every version revealed something we simply couldn’t have known beforehand.

Only later did I discover that there was already a name for this way of thinking: iteration. Build something. Learn from it. Improve it. Repeat. It sounded simple, but it completely changed the way I thought about creating anything.

The robot wasn’t changing because we’d made bad decisions.

It was changing because each version gave us information the last one never could.

Part III: More Than Just Robots

Once I understood what iteration really meant, I started noticing it everywhere.

The apps on my phone weren’t built in a day — they’ve been refined through countless updates. The books on my shelf went through multiple drafts before they were published. Even products we think of as “finished” are often the result of years of redesigns, tiny improvements, and lessons learned along the way.

I’d always imagined progress as a straight line: have a great idea, build it well, and you’re done. But iteration showed me that progress is usually much messier than that. It’s a cycle of trying, learning, improving, and trying again.

I still find it fascinating that some of the world’s best ideas didn’t begin as brilliant final products. They became brilliant because someone was willing to keep asking, “What could make this just a little better?”

Maybe that’s why the first version is almost never the last.

Not because it isn’t good enough.

But because every version has something new to teach us.

#First Robotics #First Tech Challenge #STEM #Engineering #Robotics