Design → CS → philosophy

I started designing in print, playing around with page layouts in InDesign for my high school yearbook. I always had gut feelings about whether certain spreads looked good, but I had no idea why. But when I started reading about type hierarchies and designing on the grid and eye patterns, I could begin to make sense of these intuitions. I was hooked.

I love that design is an art rooted in science. Knowing these underlying principles gave me the confidence to make decisions in a field where the possibilities can be paralyzingly infinite. And because design isn’t as clear-cut as an algorithm or a math problem, sometimes the most reliable principle is the data on what actually works.

I consider a design successful if it’s intuitive enough for the user to know where to look first but interesting enough to make them want to stick around to see the rest. Before even thinking about branding, I usually make a list of users, their goals, and their most frequent actions on the website. I design the UX to minimize the number of steps required to complete each of those frequent actions. It’s always a fine line between “interesting” and “overcomplicated,” and to be honest, I usually err on the plainer side. I’m learning new things about design every day, and I’m consistently inspired by publications like uxdesign.cc and design paradigms like material.io.

While it was fun (and kind of addicting) to arrange pixels on a screen, I also liked solving more technical problems. When I started studying CS, what made me excited about the subject wasn’t the rush of seeing a program pass test cases but the excitement of finding a great solution. There’s nothing more satisfying than seeing an unfamiliar problem and reducing it to a problem you’ve solved before, whether it’s using reusable components in React or using DP to solve seemingly exponential problems in polynomial time. As I’ve taken more algorithms classes, I’ve come to appreciate this framework of breaking down problems into subparts and abstracting their similarities.

I’m TF-ing Harvard’s CS51 this year, which, on paper, is a functional programming course in OCaml. But CS51 isn’t a class about a language; it’s a class on how to code well. As a TF, I spend my time preparing handouts for code review and thinking of intuitive analogies to explain concepts. CS languages can seem arbitrary at times, but in my experience, understanding the motivations behind those designs is what makes them click.

Which brings me to philosophy. To me, reading philosophy is about understanding the motivations behind arguments. Once you’ve reconstructed the hierarchy of premises and claims, you can decide whether you agree with the conclusion. If you don’t, you can explain exactly where you get off the boat — do you disagree with the premise, or do you deny that the premise necessitates the conclusion? If you agree, how would you address the opposition?

I think there’s a stereotype of a “philosophy person”: someone who’s out of touch with the real world; someone who name drops Frege and Heidegger to sound well-read; someone who’s a little too eager to play devil’s advocate in everyday conversation. But in my experience, philosophy is more about communicating ideas in clear, convincing ways than it is about steamrolling the opposition. It’s a collaborative process that thrives on discourse. In that respect, it’s not that different from computer science or design.

I used to think that these three fields were fundamentally different, but now I think that they’re just three different ways of playing the same game. We’re just trying to solve the most general problem in the most coherent way. And that game is gratifying no matter what the medium.