MIT blogger CJ Q. '23

You don’t have to be a founder by CJ Q. '23

move slow and fix things

Thanks to Petey, whose ideas I am stealing to write this post. Thanks to Alan and Vincent for reading drafts. This post is dedicated to MIT Facilities, the people who keep MIT running.

In 2014, Walter Isaacson published a book named “The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution”. It’s rated 4.6 on Amazon, and it’s a pretty popular book. Someone made a joke, suggesting that this book be countered with one titled “The Maintainers: How Bureaucrats, Standards Engineers, and Introverts Create Technologies that Kind of Work Most of the Time”.

Philippine science fairs, back in my day, always had “innovation” as their highest-weighted judging criterion. A national science fair announcement from the Department of Education mentions “innovation” an average of once per page. Replicating a previous work’s experiments? Applying another study’s results? Important, maybe, but unglamorous; it wouldn’t win a science fair.

When I went to a party in SF this summer, lots of people I talked to asked me about what startup I was a cofounder of. I heard about pitches ranging from “Tinder between venture capitalists and founders” and “a low-code authentication solution”. To which my gut reactions were:

I don’t remember what their answers were, but I do remember that I wasn’t convinced. Now, I don’t think there’s anything wrong with making your own solution, if you find the existing ones lacking. I’ve done this myself with qboard, because I wanted a whiteboard app with custom keyboard shortcuts; I’ve talked about my thought process before too. But it felt to me like they weren’t founding a startup because they wanted their product to exist. It felt like they were founding a startup for the sake of being a startup founder.

Leave the water running

Things tend to stick around longer than anyone expects. Consider the ESP website, which was last rewritten in 2006. Some old meeting minutes talk about whether to create the website in Perl or Python. There’s a bit of discussion, and the question that ended it was “what’s [the website’s] expected lifetime?” How many years before it’d have to be rewritten again? The consensus was, in the best-case, five years. The “upper limit” for how long it should last, they said, was ten years.

It has been 17 years, and the ESP website stands unchanged. Five years? A ten year “upper limit”? They had the right mindset of thinking about future website developers, but they didn’t get close to guessing how long the website would last.

Consider another example, Building 20. It’s a “temporary” building constructed in 1943, during World War II. An architect’s memo says its expected lifetime would be “the duration of the war and six months thereafter”. The war ended in 1945. Building 20 stayed up until 1998.

Why did Building 20 take 55 years before it got demolished? Why are we still using the same codebase for the ESP website, 17 years later? Partly because of how expensive it is to replace something so large, in both time and money. If I had to guess, a bigger reason would be because so much depends on these systems. Running any of ESP’s programs at our thousand student scale would be difficult without our website’s registration features. If you read anything about Building 20, you’ll see how much people praised the building’s flexibility, and there’s hundreds of articles talking about how it encouraged innovation.

In time, the cost of maintaining these systems becomes too high. There’s parts of ESP’s website that no one in ESP understands, and developers are afraid of making big changes in fear of breaking it. The asbestos hazards of Building 20, and perhaps its disrepair, eventually outweighed whatever creative benefits its occupants got. Leave the water running for too long, and your water bill goes up.

Leave it to me

I talk so much about the student groups I help run that I sometimes forget why I’m with these groups in the first place. In my second blog post, which I wrote three-and-a-half years ago, I talked about my first ever Assassins’ Guild game and how I got dragged to a square dance class by a hallmate, and I said that I found it fun. I find live-action roleplaying, square dancing, teaching, and puzzles fun, which is why I’m part of all these extracurriculars. And I cared about them enough that I took on some responsibility to help keep them going.

Ever since I wrote about gift economies in the puzzlehunt context, I’ve thought about my student groups as having a gift economy, to an extent. (That’s what happens to you when you study CMS; you start applying your humanities knowledge to everything.) In the Assassins’ Guild, work can be anything from helping cart the Nerf guns to and from the office, to writing or reviewing a game. In Tech Squares, work can be anything from doing weekly setup and teardown, to helping organize one-off events like amateur night.

As with the puzzlehunt or fandom gift economies, not everyone who joins a Guild game or comes to Squares will do one of these things, and that’s okay. Some people won’t have the resources to do more than come, and that’s okay. There’s groups that I take from more than I give to, like how I go to SaveTFP and get free food, or how I’ll take hot chocolate from the Lab for Chocolate Science during finals week, or how I’ll go to International Students Association meetings to get dinner. I’ve never done anything in exchange for all their free food, and I probably never will.

I’ve talked to some people who think that the only way they can show “leadership skills” is by being the president of something, or that expressing initiative and risk-taking means founding something. But there are other ways too. I’ve learned skills like delegation, tracking deadlines, and running meetings from groups like Tech Squares or the Puzzle Club, and I’ve never been the president for either of these. I didn’t suggest running ESP’s first virtual program but I took on the risk of doing so.

Leave room to grow

Maybe replacement is inevitable. When Building 20 was constructed, most people weren’t aware of asbestos’s health hazards. There’s always that unknown unknown that you couldn’t have foreseen, that unpredictable disaster you can’t recover from, or some fundamentally broken part of whatever system. And in that case, then yes, we need founders. We need people who’ll create new solutions, people who’ll make whatever invention to fill the gap.

I don’t want to give people the impression that I’m against innovation. There’s lots of cases when founding something is the right thing to do, and this is one of them. And if you make something that’s meant to last for a short time, like a one-off event that’ll never run again, there’s no need to think about maintenance. But if you want to start an event that’ll run every year, you need to think about how it’ll run every year.

My favorite examples of making things that’ll last for years are from software and architecture. For whatever reason, there’s a lot of similar ideas in designing websites and designing buildings, like how I talked about the ESP website and Building 20. I first learned this connection through a Twitter thread by Geoffrey Litt, a PhD student in the MIT Software Design Group. It’s about How Buildings Learn, a book that talks about how buildings adapt to changing requirements over decades. The thread discusses shearing layers, the idea that a building is made of layers that change at different rates, from furniture that can change day by day, to wiring or plumbing that only get replaced every few years.

There’s a lot that’s been written about writing maintainable software, like Big Ball of Mud, Worse is Better, or The Cathedral and the Bazaar. My favorite is probably Growing a Language, a talk you can watch on YouTube or read the text of. It’s by Guy Steele, and in the talk he talks about the philosophy of designing Java. It’s a great talk, and I’d suggest watching at least the first ten mintues, even if you’re not a programmer. His main idea is that designs should leave room to grow:

I stand on this claim: I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time.

These thoughts influenced how I designed Hydrant, a rewrite of Firehose. Firehose is a fantastic class scheduling website, but as its Github README says, it was built in a weekend, and “every new feature had been crammed on top.” All these features were in one 2000-line JavaScript file, which I split into several files to make adding new features easier. I also changed the jQuery to React and TypeScript, which I chose because React is taught in web.lab, and TypeScript is taught in 6.102 Software Construction. While I’d have enjoyed trying out new techiques in making Hydrant, I stuck to what future developers might know, because I can’t maintain Hydrant forever.

Leave the lights on

Hydrant is open source. Anyone can look at the Github repo and submit a pull request to get something changed. In theory, if there’s an issue or request that enough people want, one of those people would fix or add it themselves. In practice, this doesn’t happen, because would-be contributors don’t know how or don’t have enough time. Design can only go so far: good maintainers can make up for bad design, but good design can never make up for a lack of maintainers.

This is where SIPB comes in. As Hydrant is a SIPB project, we encourage our members to take on roles like being a Hydrant maintainer, one of the many roles in our many projects. We try to help members choose roles where their skills would be useful, and many roles need skills beyond code. Remember how, earlier, I talked about “delegation, tracking deadlines, and running meetings”? Every project needs someone in this role, and they’re no less of a maintainer than someone who writes code. Other non-code maintainer roles include writing documentation, choosing issues and requests to focus on, and outreach.

These ideas aren’t new. In Breaking apart the monolith, swyx suggests solutions to finding maintainers. One suggestion I like is to treat being a maintainer not only as a responsibility, but as a title or a source of pride. This is something we could do better in SIPB ourselves. I dream that one day, people will step up to be a Hydrant maintainer, because of how cool it’d be to tell people that you work on Hydrant. I’ve gotten a lot of thanks for maintaining Hydrant, and I hope the new maintainers get recognition for their work too.

You could call it passing the torch. But torches remind me of burning out, like how I once burned out doing work for my student groups. Instead, I like to call it leaving the lights on. It’s partly in the sense of the idiom “keep the lights on,” which means to keep something going, even if it’s the bare minimum. But it’s also in the sense of “leave the lights on,” which means being ready to welcome someone when they arrive. It’s a reminder to make people feel welcome to contribute, and a reminder that I will eventually leave the lights for someone else to keep on.

Leave it behind

We give advice we wish we could’ve told our past selves. While it’s true that being older made me think about maintenance more, you don’t have to wait until you’re older before you start thinking about it too. It reminds me of Choose Boring Technology, which someone once called “how to be old, for young people.” Incidentally, part of the talk’s reasons for choosing boring technology is because long-term costs can outweigh short-term benefits. Kind of like how this essay is about maintenance, which is the long-term cost to keep something going.

Here, then, is my advice. Want to change something? Find the role that’ll best let you do so. If that means starting something, then that’s great, do it. But you don’t have to be a founder. You might have more impact as a maintainer.

I’m graduating in two months. Did I leave my mark on MIT as a maintainer? Did I leave things better than I found them? Did I leave the lights on for the people who’ll take my place? I don’t know. I tried my best. I might be leaving, but I’ll still be available for advice, in the same way that others have been available for me.

To Alyssa S. ’24, Colin C. ’26, Diana S. ’25, Julia C. ’25, Lumia N. ’24, and the many, many others I don’t have space to list, I hope I made your job easier, and if not, I hope I didn’t make it harder. I hope that you help maintain the communities and groups I’m leaving behind. I hope that you one day leave the lights on for someone else to maintain them. And I hope you find more joy in your work than I’ve ever had.