Because Racecar, Friendships, and Family by Gloria Z. '26
Guest post by Monica C. '25: "What I’ve learned about being an engineer, friend, and teammate by building three racecars with my best friends"
This is a blog by Monica C. ‘25 about her experience on the MIT Formula SAE team! Eight years ago, her brother, Kevin C. ‘17, wrote a guest post of his own about his time on the team, so now we’re bringing it full circle 😊. You can learn more about the team at https://fsae.mit.edu/.
Background and Introduction
I’m Monica C., an M.Eng in Electrical Engineering and Computer Science (6-2), and I wanted to write a blog about MIT Motorsports, a team that builds, designs, and competes a Formula style electric passenger racecar. Each year we build a new racecar from scratch, starting from the design stage to two annual competitions in May and June, where we race against colleges across the nation in the Formula SAE competition series. Our team consists of around 80 people now, divided into Mechanical Engineering, Electrical Engineering, Software Engineering, Autonomous, and Business.
I’m the Software and Autonomous Engineering Lead, which means I am responsible for what I like to call “the soul of the car”: custom PCB low level firmware, data acquisition and telemetry, controls algorithms, and our very first autonomous driving system.
The Cool Stuff™
Our team has been around since 2001, and we started building electric vehicles in 2014. This year we’ve built our first 4 wheel drive vehicle, a major advancement in our team knowledge and technical prowess. This year is the largest technical jump we’ve made in my time on the team, requiring us to learn how to build a custom gearbox, our 550-Volt custom battery, controls algorithms for torque vectoring, and decoupled suspension. Our car’s 0-6001 the amount of time it takes to go from 0mph to 60mph is 2.5 seconds, and we placed 9th at our most recent competition out of 90 teams. Our team is also developing our first driverless racecar. But none of this would be possible if we didn’t love the team we were on.
Being in Motorsports has taught me a lot about the engineering process, but more importantly, it’s taught me what it takes to work on a cross-functional team.
What I’ve learned as an engineer
My advice boils down to: anything worthwhile building is hard, no one is going to have all the answers. Just go for it.
1) To be a good software engineer, you must first be a good engineer.
During my time at MIT, especially in the EECS02 Electrical Engineering and Computer Science department, I’ve noticed that it’s easy to get funneled into one specific kind of software engineering role: building software products for software companies. I’ve heard classmates complain about there not being enough classes that teach you frontend/backend development or more practical skills that are used day to day in the industry. I think the real point of MIT isn’t to learn how to use specific tools, it’s to teach you how to think.
Through my work at MIT Motorsports, I’ve realized that software engineers can do much more, particularly when working on hardware-focused teams.
Being a software engineer in a hardware-heavy project is a unique experience. You’re not just writing code. You’re responsible for understanding mechanical and electrical systems you didn’t design, figuring out how different components interface and communicate, and often connecting all the pieces together. You spend time reading datasheets to understand sensor limitations, learning how signals propagate, and solving problems that span both hardware and software.
For example, from February to March, the EE03 Electrical Engineering and software teams push to test our electrical system off the car by placing all our boards on a table and wiring them together for a full integration test. We call this process “EE on Bench,” where the final goal is to spin the motors that power the car with our custom battery. During that time, the software is actually mostly written, so I spend most of my time helping with assembly. I help make the wiring harnesses, assemble the boxes, and do full integration tests with the help from the electrical team.
EE On Bench Assembly: the box in the middle is our main low voltage components. This was the first time we saw everything in the boxes fully packaged, hence Marissa L. ‘26 ‘s enthused expression.
This is our main car controller PCB that we design ourselves! Most of the software runs on this tiny 4 inch compact setup.
To write good software, you need to understand the design requirements and constraints. What components does the software interface with? Who is going to be using the code, and what is their skill set? What are the latency, memory, and power design requirements?
These are engineering questions. They are unrelated to writing code and syntax, but they shape your end product. Knowing how register timing works or how to use specific Python libraries helps with implementation. But writing good and useful software requires thinking carefully about integration, usability, and trade-offs; problems that engineers solve no matter their discipline. As a CS or EECS student, it’s often easy to lose sight of those values when hung up day to day in the implementation details and debugging code. Most importantly, I’ve realized how easy it is to get caught up writing code without asking yourself why am I writing this? I think the boom of the software and artificial intelligence era has encouraged people to learn how to code, but software engineers need to learn how to design.
That is why to be a good software engineer, you must first be a good engineer.
2) Learn on the job
Nobody tells you how to build a driverless racecar. There’s no book with step by step instructions, lecture slides, or professors that have 20+ years of experience that are advising you. Formula SAE is a crash course on being pushed off the edge of a cliff and learning how to fly.
When I decided this year to build an autonomous subteam, I realized a lot of it was thinking about how in class we’d learn a lot about perception, motion planning, and controls, but how few opportunities there were to put all those concepts in practice. I wanted to create a team who wanted to learn how to build an autonomous car by building one. The autonomous team consists this year of 10 software engineers who, together, have learned about many different fields, including optics, motion planning, and even fundraising :).
None of us are AI experts; many of the autonomous team are freshmen who hadn’t even taken introduction to machine learning yet. But what I was selecting during recruiting were team members who were willing to take the risk and get their hands dirty.
3) You’re just as capable now as you will be 2 years from now
Before I entered MIT, and even as I started as an undergraduate, I really looked up to the juniors and seniors on the team or in my classes who seemed so sure of themselves and to me, so much smarter. But now that I myself am a senior about to graduate I realized that they probably didn’t know that much more than me. They learned it all themselves. My best mentors didn’t really teach me any step by step processes. They instead gave me projects and the emotional encouragement that I could do it.
Transitioning from student to engineer requires starting to make your own design decisions and advocating for your own system. The best engineers I’ve met have a common trait: they’re not afraid to ask questions or look like they don’t understand something. That’s how they learn.
4) Making mistakes is how you learn
I think there are limits to this statement that are vaguely in the realm of “move fast and break things.” But generally speaking, I’ve seen too many student-run teams or startups fail because they aren’t decisive enough. They spend months in the “kickoff” phase of a project or idea and never commit to the first decisions, first purchases. Building anything worthwhile has its risks, and part of what I learned during my time in college is to stop being afraid of making mistakes. I purchased the wrong type of ethernet hub 4 or 5 times, and then we realized we didn’t even need it since we discovered we needed a hardware trigger for our cameras. But how would we have discovered that if we never tried?
What I’ve learned as a friend and teammate
1) For the project to excel, the team must excel
From years that were more of a struggle, we learned that the team has to work well together in order to build a good car. Those years showed the younger generation on the team the vital importance of putting the team first before the car. When I say a good team, I don’t mean technically excellent; I mean a team that is capable of working together as a unit.
Therefore, since then, we focused a lot on building the team. Focusing on things like team bonding, trips, and just having fun in the workshop. We go on an annual ski trip, retreats, and competitions together! Throughout the year, we eat dinner together multiple times a week, watch Formula 1 races together in our shop, and have social events including mixers with other build teams and movie nights. If the team likes being around each other, they will enjoy working together to build the car.
Ultimately, if the team doesn’t like working together, the project won’t get done. Once we learned that, we built the best car in our team history in 2025.
2) Empathy is the most important quality for a teammate
Sometimes all that people want is someone to listen to their concerns. On a team where you work 40+ hours a week, it is natural that disagreements come up, and we are not perfect people. As a leader, I’ve noticed that the most important thing is to listen. This might seem obvious, but I’ve had to learn how to be a good listener. I’ve come to realize that empathy, that is deeply feeling and understanding people’s feelings, has a few components:
- Why: Get to the root of what is causing people to feel the way they do. This is the most important part. Sometimes people just want to voice their concern but don’t necessarily have a good plan for how to handle it, which is why they come to you for help. Emotional support and validation is the most important aspect of this.
- How: Understand whether there are concrete actionables to resolve the problem. People feel the way they do based on what has been occurring around them. Are there actions that are currently hurting them? Is there a better way we can support them?
- Follow up: Listening isn’t just a one time thing. It’s important to follow up in the weeks or even months after to re-evaluate the plan.
3) Sometimes the best thing to do is to go to bed (or go get boba)
When people are working super hard and it gets late at night, there’s something like sunk cost fallacy that occurs and people just keep bashing their head debugging instead of going home. Problems often look better in the morning with a fresh mind, as hard as it is to stop working when you’ve invested so much time. Going to bed early sets you up for a better attempt the next day.
One perk of working on Motorsports is that we have a boba shop and ice cream store right down the street. We often take breaks to go walk there and get a sweet treat when things aren’t working as we expect. We also have a playlist that we listen to throughout our late nights working together, which I will attach here:
Family
Eight years ago, my older brother Kevin Chan ‘17 M.Eng ‘18 wrote Because Racecar and it’s fun to reflect on how much has changed:
“While our team can only dream about carbon fiber monocoques, four-wheel drive systems with in-hub motors, and semi-active suspensions…”
I’m proud to say that our Model Year 2025 car features our first four-wheel drive vehicle with in hub motors. This car also features our first decoupled roll-heave suspension. My whole family made it out for my last competition this year!
My dad and mom, Eric ‘85 and Mary, raised both of us to have a deep love for problem solving and engineering. In many ways, Formula SAE is a dream our family came up with together, albeit indirectly. My parents raised us to be able to fix our own bicycles and cars, to help around the house with maintenance, and encouraged us to pursue whatever silly things we wanted to build. None of them were even phased when I told them I started building a driverless car.
Me, my dad ‘85, my brother ‘17 MEng ‘18, and my mom at our June 2025 competition! Kevin was a design judge for the competition this year.
Purpose
Some people ask me, “why do you do this to yourself?”
They ask me this because it’s hard to believe an MIT student would spend 40 hours a week doing anything except their schoolwork. When the nights are long and the car is not working, I often ask myself this question.
Sunset in Michigan on the last day of our competition. It was so surreal to be surrounded by so much rural landscape when we’re used to the hustle and bustle of Cambridge.
One of my favorite feelings is when we’re out on the track testing. If you close your eyes, you can hear the sounds of the car, which often indicate to you how the car is operating, how much the driver is slipping, whether any components are interfering. Often, listening to the car will tell you more than seeing it. You can hear everything working together, the cooling, the controls, the drivetrain, etc. I get a moment to process that wow. We built that car.
But if you listen a little closer, you hear the laughter from the team watching the car that we built driving around. “Woah, I can’t believe it! It’s going so fast! It sounds so good!” I can hear my teammates pacing around, watching the car closely.
On one hand, you have the car, a physical manifestation of our work as engineers and the countless hours poured into it. On the other, you have the people, joy, and friendship that was required to get there. For me, MIT Motorsports is a combination of all the things I love most about being at MIT. Working with incredibly talented engineers and scientists to build something cool, partly for fun, partly because of the challenge.
But mostly, it’s because we love what we do and who we do it with.
MIT is a hard place, as any student at Tech knows. Some days are hard to get through and understand why we put ourselves through it. I used to think my dreams would get smaller after I achieved what seemed a lofty dream of attending MIT. But to my dismay, my dreams only got bigger. And on the days that are hard, as there are many, I am guided by the people around me, my team.
The most important lesson that I’ve learned through my time at MIT is that we build things to attain the craft and scientific prowess, but anything worth building takes a village. You need the right village to build a fast racecar. Technical knowledge allows you to accomplish your goal, but people provide the purpose.
.
- the amount of time it takes to go from 0mph to 60mph back to text ↑
- Electrical Engineering and Computer Science back to text ↑
- Electrical Engineering back to text ↑