Reflecting on my time at University of Washington

Having just graduated, I've been cleaning out old class notes and projects and realizing how much of my UW experience was shaped by side quests: getting lost in research, extending class assignments too far, turning hobbies into technical projects, and eventually learning to share the work publicly. This post is a tour through some of my favorite projects, and what they taught me, told through interactive widgets.

Year 1: Reaching Out Early (2022-23)

The first thing I did upon accepting my UW offer was look for fun groups to join. One stood out: Richard Anderson's ICTD Lab and the eKichabi v2 project (a digital phone directory for farmers in rural Tanzania). I sent in an email and, thanks to PhD student Ananditha Raghunath and Professor Anderson taking a chance on an incoming freshman, I got to join the project. After a year of field deployments and validation, I had learned Django and made friends in the ICTD community. Both helped me land my first internship at Gooey.AI working on Farmer.CHAT (a chatbot to help farmers across India, Ethiopia, and Kenya). The work was demoed at the UN 77th General Assembly and FAO Science and Innovation Forum 2023, but it is more fun if you try the English version yourself:

Working at Gooey with AI agents, clients, startups, and model deployments laid the foundation for eventually founding my own startup. The main takeaway I have for anyone about to start their undergrad is to not be afraid to reach out to join extracurricular projects, especially research, in the first year. The sooner you start building and publishing useful projects, the more doors open up.

That said, while my most useful experiences were outside the classroom, the course exercises were definitely not without their merits. As a violinist in the UWSO, the first project that resonated with me was actually in the very first introductory CS class I took. The task was to implement a simple Guitar sound synthesizer. Naturally, I extended it to accept MIDI input (try "Under the Sea" or "Pirates", they work great):

So, while I recommend seeking out extracurricular experiences early, I do not want the message to be to ignore your coursework. Even if you're forced to take a boring prerequisite, the smart move is to extend it and learn something new. In fact, through extending projects in my first year, I got good enough at building apps/games to petition into a senior capstone in software development for underserved populations. Together, my group and I built an app to teach community health workers in India how to use EKG machines to screen for heart diseases. Huge thanks to my mom for teaching me how to read electrocardiograms.

Year 2: Interdisciplinary CS (2023-24)

Having seen the impact you can have building software, my main goal for the second year was to explore the intersections of CS with other fields. Starting with aerodynamics, I joined Design Build Fly to build RC planes. My computer science skills were of great use writing data analysis scripts for the team, and I learned a ton about fabrication, physics, and electronics. We were even able to place 3rd nationally!

Outside extracurriculars, my favorite class from year two was intro to compilers because it lies at the interface of software and hardware. It is one of the main classes I recommend everyone take. In fact, I even went on to become a teaching assistant for it. My class partner, Daniel Tameishi, and I built a (mini)Java compiler that targets x86 and extended it to support Apple Silicon's ARM64 target. Enjoy this Godbolt Compiler Explorer inspired MiniJava explorer that shows the source code and assembly correspondence:

The things I've learned from building compilers have come in useful in linguistics projects, machine learning research, and software-hardware optimmization. Learning to teach the concepts to undergraduate students and professional masters has also made me better at conveying my research in a more accessible language.

Many of the other courses I took have come in useful later too. Most notably, algorithms, modern algorithms, and theory of computation came in quite handy for working on graph algorithms over the summer with Austin Ulrigg. We started with a simple textbook problem: figuring out the genus of the Balaban 10-cage. At the time, we didn't know this was an NP-hard problem in general, so we went about designing a general algorithm for this. It was slow, but eventually, after a few days, we had our answer (the genus is 9). After taking combinatorial theory and numerical analysis in my third year, I was able to optimize our algorithm so it now can solve the Balaban 10-cage and even the much larger, and previously unsolved, Tutte 12-cage in just a few seconds. As of writing, our algorithm, PAGE, is the fastest general-purpose graph embedding algorithm, has been published in Discrete Mathematics, and inspired my honors thesis. Here's an interactive explanation of graph embedding (drawing graphs on surfaces without edges crossing) and how it can be represented combinatorically using rotation systems. You can also generate visualizations for your own graphs or explore it in full-screen. The complete bipartite graph K3,3 is used as an example:

My main takeaway from the math research, applications of compilers/teaching knowlegde, and wind tunnel data analysis is that my favorite uses of CS skills are not purely computer science, software, or hardware engineering. The coolest applications are when CS skills are used in combination with knowledge from other fields. My advice to current undergrads is to not be afraid to pursue other hobbies and interests even if they seem unrelated to your main field of study. I used to worry that spreading myself across music, planes, math, apps, and research made me unfocused. In practice, the intersections were where the best projects came from. The best time to try new things, have fun, and take risks is when you're young.

Year 3: Learning to share (2024-25)

To learn more about wearables and cross department collaboration, in my third year, I joined the Ubicomp Lab, advised by Professor Shwetak Patel, Professor Vikram Iyer, and senior PhD student Zhihan Zhang. Together, we published multimodal agents for sustainability information retrieval in Nature Electronics and work on interactively discovering sustainability information while browsing in ACM IMWUT. We also released an open-source agentic hardware tool-use benchmark, Embedded Arena. The part I enjoyed the most was collaborating with other departments across the university, particularly the seismology department. We started by shadowing their work and understanding the data analysis bottlenecks. Then we built a tailored seismology agent to make iteration and data exploration easy for seismologists. Check out the earthquake detection 101 tutorial below and see how good you are at identifying earthquakes from the noisy data:

Based on these research experiences, I gave a bunch of talks and guest lectures this year. A fun one was to the students of the Embedded Systems capstone where Jiuyang Lyu and I showed how to run custom ML architectures on the MAX78000. We demonstrated both a tiny LLM and a simple elk detection model:

I ended the year by taking the NLP capstone with Aruna Srivastava. We laid the groundwork for our Interspeech publication and trained early versions of the models we now use at our startup. Try the models in action by downloading our app!

This year, I learned that sharing my work is just as fun as making it. Before, I would keep my projects on my private disk for my own enjoyment and shy away from public speaking. But after speaking at lots of events, including the Mozilla Builders Demo Day and Interspeech Speech Slam, I now see the value of it. The reality of the overwhelming amount of papers being published is that if you don't advertise your work, it won't be seen and other researchers won't be able to build on it. More importantly, when you present a talk, your face becomes recognizable and other event attendees will seek you out to talk with you. This means you get to hear lots of cool ideas and perspectives you otherwise wouldn't. So my main advice to other early researchers is to share your work, and try to be one of the first people presenting at events you attend. This is something my mentor at Gooey, Sean Blagsvedt, had also tried to teach me, but it didn't click before now.

Year 4: The Sweet Lesson (2025-26)

Starting my master's in computer science, a main theme for my fourth year was the value of human engineering and domain-specific expertise. While this primarily showed up in my research and startup work, I also have relevant class projects to share. The first was in robotics with Ethan Kogan where we trained a model to control a robotic arm using our brain waves. In the video, I'm moving a second arm to focus my brain waves, but the main arm on the left is purely controlled by my brain:

Even a simple task like picking up a charger and dropping it in a box based on my brain signaling to the model how the charger and box are positioned, required many hours of demonstrations for the model to learn. Because we cannot easily simulate a human brain (yet), this was inherently something that could not be trained in simulation and had to be done manually in the real world.

Similarly, my other favorite project from this year, required collecting physical data on humans using their body to play tennis. With my group in computer vision, we collected hundreds of videos of serves, and used that data to build a pipeline that takes a video of someone playing tennis, determines the frames where a serve occurs, further annotates each frame with the corresponding stage in the 8 stage model, and then analyses each stage for potential injury risks and technique improvements. View it in action below:

Replay stage Frames 0-0

Start

Stage 1 of 8

Lastly, since I spent a significant amount of time this year working on my pronunciation coaching app, I would like to share the most tedious part: reviewing and annotating audio samples. Listening to audio, even sped up, is inherently a linear process where reviewing X hours of audio is lower-bounded by X hours of work. However, by visually representing audio using Mel spectrograms, it is possible to read it much faster and "listen" to multiple audio samples at the same time to spot patterns by rendering multiple on the same screen. Here's an interactive tutorial on reading speech from spectrograms:

A lot of my projects this year required tedious human work: frame annotations for tennis, brainwave demonstrations for robotics, audio review for my startup, and many small rounds of interface-tuning in between. Earlier in college, I probably would have treated that kind of manual work as a failure of elegance. I wanted the scalable™ solution: the clever algorithm, the synthetic data pipeline, the model that improves automatically once you point enough compute at it. And of course, there is real truth in that instinct. The Bitter Lesson is bitter because it keeps being right: over a long enough time horizon, methods that leverage more compute and more data tend to win over methods that try to hard-code expert knowledge.

But my fourth year taught me a sweeter version of that lesson. Human knowledge does not stop being useful just because it may eventually be out-scaled. There are always moments where the missing ingredient is not more generic data, but the right human signal: a clinician's intuition, a speaker's lived experience, an annotator's careful ear, a user's adaptation to a tool, or a domain expert's sense of what matters. Sometimes that signal only buys a short-term improvement. But short-term improvements are not trivial when the system helps a child with a speech impediment communicate today, or helps someone with limited motor control gain even a little more command over a robotic limb. In those cases, "eventually" is not good enough. A small boost in usability now can be worth a lot.

Generative AI has made this feel even more true, not less. As more purely software tasks become easy to automate, the valuable human work shifts toward knowing what to measure, what to correct, what interface would make annotation bearable, and what kind of feedback would actually help the next model improve. It has also made the tedious parts easier to survive: now, when I need a custom labeling tool, review interface, or data-cleaning workflow, I can vibe-code something tailored to the task instead of bending my work around generic software. That makes me much less afraid of projects that require manual effort.

So my takeaway is: do not worship manual work, but do not run from it either. If one person's careful effort can create repeated value for many people, especially in a domain where the automatic approach is not ready yet, that effort can be deeply worthwhile. Humans will keep adapting on top of technology, and technology will keep giving humans better ways to contribute back. The sweet lesson is that scaling and human knowledge are not opposites. The best systems often use both.

Next: PhD at UC Berkeley (2026)

UW taught me that the projects I enjoy most sit at the boundary between technical depth and human usefulness: tools that require signal processing, hardware, machine learning, deployment, and careful interface design, but ultimately matter because they help people do something they could not do before. That is what draws me to assistive speech technology, and it is what I'm excited to keep exploring with Professor Gopala at Berkeley. Huge thanks to my advisors, collaborators, classmates, and friends at UW for making these four years so fun.