I build the things I didn't have.

I got into computers in sixth grade, in science class, building PCs. Nobody handed me that, I just worked it out. I didn't write a line of code until I was sixteen, in AP Computer Science Principles, and Python was the first time I could make something instead of assembling something.

So the hardware came about four years before the software, which is probably why I ended up down at the low level instead of somewhere more comfortable.

The part I think about more is that I didn't know any of it was missing at the time. Innovators for Purpose is where that changed.

nobody sat me down and started any of this

It was the education, not the hardware. I could get my hands on a computer eventually; what I couldn't get was anyone to teach me what to do with it, and I wish I'd had that years earlier than I did.

So that's what I build for now, and it's usually for someone the market decided wasn't worth building for.

Bridges between high level and low level language. How you get from something a person can read to something a machine can run, and what gets lost on the way.

It's why the same person ended up writing a processor from the instruction set and a block palette that middle schoolers use to drive a robot. Both of those are about the distance between what a person means and what a machine does, just approached from opposite ends.

i would talk about this forever

Most of what I actually do is explaining. I lead a firmware subteam, I teach the shop assistants who run the trainings, and I teach middle schoolers who have never written a line. It's mostly the same problem each time, which is figuring out what someone can already do before you start talking.

On the subteam that means goals set with people rather than for them, weekly meetings, one-to-one check-ins, and making sure nobody walks into a design review unprepared. It also means teaching the stack itself: C and C++, Git, Linux, the ESP-IDF toolchain, hardware fundamentals, the protocols everything talks over. You can't hand someone a task they haven't been taught yet.

Ask before you build. I didn’t run the braille user interviews myself, that was the wider team, but the feature set we are working to came out of two rounds of them rather than out of what any of us thought would be interesting to make. That is the part I would defend hardest about how that project is run.

The site sorts everything into six. Here is what each one actually means, which is not always what it sounds like.

FIRMWARE

The layer where every other part of a device has to agree with the others. On Myo-Amp that is literally what it was: the firmware was the integration.

DIGITAL DESIGN

Reading a specification and turning it into logic a machine follows, one instruction at a time. No library underneath it.

IN THE SHOP

Mostly teaching, not running machines. Belt tension, thermistors, and someone who has never touched the thing in front of them.

SOFTWARE

Picking what the next person can maintain over what is elegant. The shop tool tracker runs on Power Automate for exactly that reason.

TEACHING

Handing over the thing I had to find sideways. Blocks that resolve down to real code, so a robot moves before anyone writes a line.

GAMES

Constraints, mostly. A Game Boy Advance has no operating system and nowhere to print to, so the tests ship as their own ROM.