In my second semester of my freshman year at Arizona State University (before I transferred back to Georgia Tech), I spent a weekend - not playing games, or hanging out with friends - in Google Calendar.
I wasn’t planning for anything fun, coordinating a dinner, or even looking at my life calendar, I was working across a dozen or so new ones. Each one, a different version of the next semester’s classes. Discrete math came in two shapes: a fifty-minute Monday-Wednesday-Friday version, and two or three Tuesday-Thursday sections that ran ninety minutes. I wanted to take Circuit design with a few friends, so the schedule they were thinking of taking went in as another layer. I fenced then, so practice went in. And I’m not much of a morning person, so Linear Algebra was not going to get me up at 7am.
I’m very much a visual person. I need to see something - even just a layout - for it to really stick for me. The school’s registration system was definitely not built for visual people. It was a wall of text, listing the courses in a list - after some confusing searching. Each result showed Course, section, days, times, room, seats left vs available, and instructor. M/W/F 9:00-9:50. T/Th 11:00-12:15. Technically everything I needed was on that page. Practically, I could not look at it and envision what the week would actually be like. So I dragged blocks around in a calendar for hours, turning events on and off, until something looked like a life I would want to live.
So, after a burnt weekend, I had a plan. Of course, like most plans - when registration opened, the one section that made the whole thing work was full! I had backup plans, but ended up with that 8am Linear Algebra course. I think I maybe attended 3 lectures, the intro, the mid-term and the final; I passed, but only because I had a similar course in High School the college didn’t give me credit for.
Here is what I did not understand at the time, and took a long time to put into words.
The registrar’s system was complete. Every fact was in it. The problem wasn’t that it was missing information, it was just that it wasn’t legible, and the work of making it so had been handed to me. The weekend in Google Calendar wasn’t hard, I came to realize. It was just me doing, by hand, a job the computer could have done in a millisecond: take every combination of sections, throw out the ones that overlap, add some optional constraints, and show me what was left.
The first thing I built was not a scheduler, or a UI. - instead I addressed the pressing issue with a cron job (a computer initiative that runs over and over on a timer). When the section I needed was full, I wrote a script that hit the course listing page every few minutes and looked for a seat to open up. One simple check, done in a loop - so I didn’t have to sit there refreshing the page. It’s a very small program, but incredibly useful, because it watched the one thing that mattered and told me when it changed - without wasting the most valuable thing we all have - time.
The scheduler came after, and like most useful things, I built it for myself. I modeled it on the tool I was already using for this - Google Calendar. On the left panel, every section of every course I was considering, one row each, with a little Monday-through-Friday block showing which days it met. On the right, the week laid out just like Google Calendar does. When you picked a section, every other section that conflicted with it went grey - showing what was no longer possible, and the calendar populated.
That greying out was the whole idea, and came from me using my own tool. I got tired of picking a section and then finding out it collided with something I already had. The computer knew it collided, and letting me pick it anyway was like letting me shoot myself in the foot with a decision the software could have made for me. Clear UX shows what is possible, and makes clear what isn’t. My philosophy is to be lazy, have the computer do the work when it can.
I have been building that same thing ever since. I didn’t plan this as my career, but it keeps coming up. And once I recognized the pattern, I’m leaning into it.
At Nest, I led the web app for a thermostat that intelligently controls the temperature of your house on its own. When a machine does that, the interface has one job, which is to let you see what it did and why, so you keep trusting it. The web app showed the weather outside your house in the background, and at night it showed stars. I made sure the stars were the real ones, in the right place for your zip code, rotating around the north star. This wasn’t necessary, and in fact - I had to negotiate with the design team to get it in, since the Android and iOS apps weren’t doing this. I pushed for it through because everything else in the app was accurate and I did not want the one decorative thing to be a lie. It is still running. If you log into home.nest.com starting around dusk, you’ll see the background change, and the stars appear.
Years later, at Everyday Robots, within Google [X], I built the tools engineers, roboticists, and leadership used to see what a fleet of learning robots was doing. The part I’m proudest of: you could scrub back through a robot’s day the way you would scrub a video, or watch it live from anywhere, in the same view, with the same controls.
At Waymo, I work on internal tools. I’m not going to get into specifics - but the pattern holds: the more sophisticated the analysis underneath, the more weight the interface has to carry, and the less forgiving people are of one that makes them guess.
And on the side, for myself, I’ve been building small tools of my own. I’ll save the details for later posts, but they follow the same rule: the machine advises. The person decides. To decide well, the person has to be able to understand what’s going on.
So here is my thesis, and how I’m going to approach Legibility:
As any system gets more complex or more autonomous, the interfaces for understanding outgrow the capabilities of any bolted on dashboard. The interfaces have to be thought of as part of the product, even when not exposed to the public. A thermostat you can’t read is one you override, and that wastes energy. The same is true of a robot, and it’s true of a change to a self-driving car: if you can’t validate it, or don’t know why it did what it did, you can’t ship it. People route around systems they can’t understand, even capable ones.
I have started calling this legibility. The word to me, means “Can a person hold this thing in their head, well enough to really understand it, and make a decision about it?” - without doing a weekend of work in Google Calendar first?
That is what this Substack is about. I’ll have roughly two kinds of posts, about one a week. Firstly, case studies of systems I’ve actually built: what was hard to read, what made it legible, what I would do differently. The others will be builder notes on making things while holding a day job: shipping with AI agents, the legal reality of side projects inside a big company, the mistakes I would rather you not repeat.
I’m not a fan of philosophizing without hands-on experience, so nothing here will be about something I haven’t done - I’ll speak from grounded experience.
So, next week: what happened after the cron job? Thirteen schools, and a laptop running upside down on my apartment carpet so the fans could breathe - it was a side project turned startup. Next thing I knew I was in an accelerator, with funding, a co-founder, and learning the importance of customer discovery.
Until then, I have a question for you. What is the system you are trying to make legible? I would love to hear about it.
I work at Waymo. The views here are mine alone and do not represent Waymo, Alphabet, or any current or former employer.