Robotics.

I joined FRC with almost no experience. I could not have told you what a motor controller was. What pulled me in wasn't the robot so much as how the work happened: an idea went from whiteboard to prototype to a competition field in weeks, and every version taught the team something the previous one couldn't.

Robotics was my first real exposure to iterative design, and to solving problems alongside people who knew things I didn't. Nobody hands you a curriculum; you learn by building, breaking, and asking.

Over four seasons I grew from a new member into three roles, and each one turned out to be a different lesson in the same subject. Leading electrical meant owning a system other people depended on, and teaching newer members to build it well enough that it didn't depend on me. Running the pit meant making calls in the minutes between matches, when mechanical, electrical, and programming all need the same fifteen minutes and someone has to decide what happens first.

Inventory sounds unglamorous until the part you need mid-competition is exactly where it's supposed to be. That job taught me something I've carried everywhere since: organization is a form of reliability.

Most of my work lived in the robot's electrical system: power distribution, motor controllers, battery management, and the wiring that ties it all together. The real skill wasn't the wiring. It was diagnosis. When a robot dies on the field, the cause could be a brownout, a loose crimp, a damaged wire, or software. You learn to isolate variables, test one thing at a time, and resist the urge to guess, usually with a match clock running.

You also learn to build so the same failure doesn't happen twice: cleaner wire runs, labeled connections, strain relief, spares where they can be reached. Good engineering turned out to be less about clever solutions and more about systematically removing the ways things go wrong.

In my final year I helped mentor FTC Team 24563, FM Firewall. Mentoring flips the job: instead of solving the problem, you help someone else see it, asking the question instead of grabbing the wrench. It showed me how much I had absorbed without noticing, and how much of engineering is really about giving people the confidence to try something they might get wrong.

The lessons that stuck have very little to do with robots.

• Engineering is iterative. The second version is always smarter than the first.
• Systems people can rely on are built through collaboration, not heroics.
• Leadership means enabling others to succeed without you.
• Organization is just as important as technical ability.
• Complex problems give way one isolated variable at a time.

Those habits, to diagnose before acting, build for reliability, and make the system bigger than yourself, are the same ones I now reach for in everything from volunteer organizations to client work, and they're the ones I expect to matter most in medicine.