Why include a project that didn’t fully work?
Every other project on this site works. This one is here on purpose, because it’s honest, and because it’s the project that actually taught me the most — about hardware, about scoping, and about staying useful to a team when a build isn’t going well. If you read Valerii’s note about me further up this site, the “Arduino sensor burning out on presentation day” he mentions is this project.
The goal
As a team of five first-years, we set out to build a portable water quality monitor addressing UN Sustainable Development Goal 6 (clean water access) — a turbidity sensor and a waterproof temperature sensor wired to an Arduino, streaming live readings to a phone via the Blynk.io dashboard, aiming for something low-cost enough to be genuinely useful in resource-limited settings.
What actually happened
We jumped into an ambitious hardware project with close to no prior knowledge — none of us had touched C++ before, and we bought the wrong Arduino revision for our sensors on the first attempt. The replacement board still wouldn’t cooperate, and without real C++ experience, we struggled to tell whether the problem was our wiring, our code, or the hardware itself. The turbidity sensor ultimately burned out during setup on presentation day.
The physical build — breadboard, Arduino, and sensor wiring. This is as far as the hardware got working reliably.
What I actually did
I wasn’t the one who solved the hardware problem — nobody did, in the time we had. What I did do was stay with it: I kept troubleshooting alongside the team rather than checking out once it got frustrating, and I kept the group’s morale up when a working demo stopped looking realistic. That’s a smaller thing to put on a portfolio than “shipped a feature,” but it’s a real and repeatable skill, and it’s the specific thing my teammate Valerii chose to highlight about working with me.
What I took from it
The concrete lesson was about process, not hardware: as first-years, we committed to an ambitious build before reading the documentation properly, prototyping small, or confirming our components were compatible. The fix isn’t “know more about Arduino” — it’s read first, test in small pieces, and only commit to the full idea once the fundamentals are confirmed working. I’ve carried that into every group project since.