What I’m chasing is code that feels like magic. Something that runs unbelievably fast, or fits in far less memory than should be possible, or just looks really good.

Something that looks cool and runs slowly is just shitty magic. The trick has to survive being measured.

Visuals add to it, especially when you’re replicating something real. My spectral raymarcher does a physically accurate diamond, dispersion and all, in one shader in real time. It runs the actual physics, and that’s most of why it’s satisfying.

Finding a way nobody has used before is the same feeling. The voxel format in ray-vox came out of a few dead ends and one good idea. It packs a scene smaller than a gzipped copy of the source file, and the GPU reads that same layout directly. I hadn’t seen anyone do that.

I’m a computer science student at UC Santa Cruz, going into my third year, and that’s the thread through most of what I’ve built.

It shows up in different shapes. I built a voxel renderer from scratch around a data structure I designed. It holds a scene in a fifth the space and stays fast to trace on the GPU. I worked out how to lay all 16 million RGB colors into a single image that reads as one smooth gradient. The method is one I haven’t seen anyone else use. I tuned a production service until it ran 39% faster and cost 92% less for the same output. And I built a robot that fuses its sensors to know where it is on the field to within a centimeter.

What I’m looking for

A software engineering internship doing graphics, rendering, or performance work. Close to the hardware, somewhere I can measure whether I did it well, shipping something real next to engineers I can learn from.

That’s narrower than what I’d have said a year ago, and wider than it sounds. Graphics, GPU compute, simulation and ML inference all come down to the same skill: getting a lot of parallel work done inside a budget. I’d rather get good at that than pick an industry and hope it’s the right one.

How I work

The thing I’m proudest of from the last two years wasn’t a feature. On a game built by a 100-person student team, I got convinced our rendering setup was going to rot into something we couldn’t dig out of. Rather than keep arguing about it in meetings, I rebuilt a full level on a new 3D system to prove the point. That prototype got the team to switch. The transparency shader I wrote afterward was much harder code. Convincing people to do the rewrite was the part that mattered.

I also care about making things other people can pick up, so I write stuff down. My robotics team has a wiki I built from scratch, so the hard parts survive after I graduate. Every project on this site has a real writeup too. Being able to explain what you built matters about as much as building it.

I also like talking about software with other people, nerding out, and working a problem together rather than alone. It’s a big part of why I joined a game dev club instead of building everything by myself.

Two internships inside production codebases taught me the thing I still think about most: careful beats clever when a lot of people depend on your code. I test it, I push it through review, and I’d rather ship safely than look clever and break prod.

Where graphics fits

I’ve loved video games my whole life, and graphics is where that runs into the hard-problem stuff. It’s one of the few places low-level work shows up right on the screen. Get it right and you watch it run, instead of reading it off a graph.

It’s also where the constraints fight hardest. You get about 16 milliseconds, the hardware is whatever the player already owns, and you can’t throw more machines at it. The answer has to come from arranging the work better, which is the kind of problem I like most.

That’s why ray-vox and the spectral raymarcher are the two things I’ve sunk the most into. It’s also why the math I’m working on now is rendering math specifically.

Outside of that

I like being close to hardware. I built my PC years ago and keep tuning it. Lately I’ve been into small form factor builds, trying to fit real performance into a roughly 10-liter case. I also fell down the audio rabbit hole: EQ, calibration, measuring how speakers and headphones actually perform. I keep meaning to write my own AutoEQ-style tool and haven’t started. I’m in UCSC’s Game Design and Art club making things in Godot. And Rust is my default when I want speed and safety at once.

Timeline

High school (2020 to 2024). Graduated from Khan Lab School. Dual-enrolled at Foothill College, taking college-level chemistry, biology, and three physics courses alongside high school. Built a CS foundation through AP CS A, robotics (FRC #6962), and a lot of independent projects. Programming lead for the robotics team, focused on control systems, simulation, and software reliability.

Summer 2022, SWE Intern at SmugMug. Full-time paid internship after my sophomore year of high school, working in a real production codebase in PHP, React, and Next.

Summer 2023, SWE Intern at Flickr. Internship after my junior year, tuning a production AWS pipeline to cut its compute cost about 92% and run 39% faster.

University (2024 to now). Computer science at UC Santa Cruz, going into my third year. Building systems-level projects across graphics, GPU compute and infrastructure, and looking for a software engineering internship where performance is the actual problem.