Lessons from My First University Group Project

I just finished presenting my group project for ECE 198—Project Studio. Our team built a delirium detection system for hospital patients using an ESP32 running ESP-IDF (FreeRTOS), a handful of sensors, and an ESP-CAM with an object-detection model.

The course itself wasn’t particularly demanding compared to something like ECE 105 (Classical Mechanics). What consumed most of my time was learning FreeRTOS through Mastering the FreeRTOS Real Time Kernel—about 300 pages of dense material. Even with a background in operating systems, this was my first time programming on a real-time operating system, so working through the manual was unavoidable. I genuinely enjoyed reading it, as I do with most computer science books. But it came at a cost: time I could have spent studying for other courses.

That wasn’t the hardest part, though.

The conflict

A few days before our final presentation, one of my group members accused me of “overriding” other people’s changes and caring too much about code quality. He argued that code quality shouldn’t matter because this was “just a school project,” and took a jab at me by implying I was rigidly adhering to FreeBSD’s standards. (For context, many people in my cohort know my first co-op is with the FreeBSD Foundation.) Funnily enough, I generated most of the code using Claude Code, directing it to write in the style of examples from the FreeRTOS manual.

This struck me as absurd. All code changes went through merge requests with extensive review before being approved and merged into main. The only exceptions were the initial template bootstrapping and formatting through clang-format, which I handled directly. Yes, I modified some driver code written by another teammate, but that was necessary to integrate the drivers properly with ESP-IDF. The original logic remained intact, and every contribution was preserved in the git log. There was no force-pushing. Nothing was lost.

As for the code quality critique: I firmly believe that maintaining good standards matters even for a school project—perhaps especially for one. This course exists to give engineering students the chance to develop skills for complex, collaborative work. If you walk away thinking code quality doesn’t matter when multiple people are contributing to the same codebase, you’ve missed the point entirely.

During our argument, I offered an analogy: would an art student in university deliberately produce low-quality work simply because it’s “just an assignment”? He didn’t have a response, and the conversation ended without an apology.

Presentation day

Then came the day of the final presentation.

Our HTTP requests weren’t working, despite the team testing them successfully the day before. It turned out the device had connected to a different Wi-Fi hotspot. The same teammate “fixed” it—but not really. Our code was designed to pull Wi-Fi credentials and the remote server URL from ESP-IDF’s menuconfig, specifically to avoid hardcoding sensitive values that could end up in the git repository. He bypassed all of that and hardcoded the credentials directly.

It worked. But that wasn’t the point.

When I tried to correct it through menuconfig, he snapped at me: “Just leave it! It’s working!”

I couldn’t believe what I was hearing. This was our final presentation—effectively our production environment—and I was being told to ignore a problem that hadn’t been properly resolved. What made it worse was that ESP-32 and ESP-IDF were my responsibility. I was the one who had read the 300-page manual. At the start of the project, I told everyone that if they wanted to work on the FreeRTOS side, they’d need to read it too. Only I did.

Now someone who hadn’t done that work was telling me how to handle my own domain—and doing so by overriding my judgment on the day that mattered most.

I can tolerate confidence. What I can’t tolerate is confidence untethered from competence. He wasn’t leading the project, but in that moment, he was acting as though he were.

What I took away

Throughout my work on open source projects, I’ve never encountered anything like this. Even contributors with decades of experience tend to approach discussions with humility—probably because everything is public and reputations are built over time. During my first internship at a health research institute, my managers and coworkers were consistently respectful, despite holding PhDs and years of experience. That mutual respect is part of why I loved the job, even when the workload was heavy.

From my first group project in university, I learned something I hadn’t expected: not every engineer shares those values. Some prioritize expediency over craft. Some conflate volume with authority. And some would rather fight you than listen.

It’s a lesson I won’t forget.