Tom Chen

Immediate and ordinary beauty

2024-05-16T00:00:00+00:00

Sometime last year I subscribed to Christopher Schwarz’s newsletter, The American Peasant, and I’ve been gradually reading the archives in their entirety. If you’re into woodworking, you might know that Chris runs Lost Art Press which publishes some incredible books and videos on hand tool woodworking. Over the past year or so, I’ve read The Anarchist’s Tool Chest and The Anarchist’s Design Book. I’ve watched The Naked Woodworker, and I’m currently working through The Essential Woodworker by Robert Wearing.

I’ve slowly begun to assemble a small set of decent tools and have started working on a couple of small projects for our home—a pair of sawbenches, a proper Nicholson workbench, likely a coffee table after that.

As a relative newcomer to woodworking, I appreciate the unpretentiousness of Chris’ voice, and I’ve learned a lot from him and the crew at Lost Art Press. But what I really appreciate and find inspiring is his worldview and the ethical commitments that infuse his work. There’s something very punk rock about Chris’ insistence that everyone can and should learn the basic skills to build and maintain the essential stuff of their lives for themselves.

And then there’s nuggets like this:

[…] we are all capable of good. For me, the two most important things I can do are: Take care of others and create things that are beautiful. By “beauty,” I don’t mean the stuff in art museums, the books in our libraries or the soaring buildings in our cities. I mean the small (and big) things that we do every day.

Beauty can be a rude chair that is nice to sit in and draws your eye from the other side of the room. It can be a handplaned surface. A moulding that creates bands of light and dark. A song that is sung at the end of a day’s work. A meal that you make for your family.

All these things are temporary; some last only an instant. But these bits of immediate and ordinary beauty (what you see, taste, smell and feel) make a moment – perhaps the one you are in right now – better than moments without them.¹

This is the kind of ethos that I want to guide my life and work. It’s a reminder that the small things we do every day matter. You’ll have to subscribe to Chris’ newsletter to read the rest, but I highly recommend it.

Christopher Schwarz, “Earlywood: Immediate and Ordinary Beauty”. ↩

The market-reflected gaze

2023-07-30T00:00:00+00:00

Anne Helen Peterson nails it in this essay on the “market-reflected gaze” and how it makes us all feel bad about our homes:

Houses aren’t just money pits when it comes to everyday maintenance. Homeownership is always shadowed by the specter of resale value.

For every modification, necessary or cosmetic, the questions dance around you: Is this good for resale? Am I making it “too much” house for the neighborhood? What would a real estate agent say? How do I balance what I actually want with what ten thousand prospective buyers would actually want?

Even if you have no intention of selling in the near or even semi-near future, there’s persistent pressure to make your space amenable to a theoretical someone who isn’t you, the person who very much lives there right now.

I feel like I’ve seen so many homes lately that seem to have been designed to appease this “gaze”. It’s hard to put a finger on (and I am far from immune to the gaze myself), but there’s lots of muted tones and sterile decorations. Clean and orderly but cold and hotel-like. It’s a bit like a home that’s meant to look good on Zillow but that actually feels kind of bad to inhabit. These are homes designed to offend no one and consequently end up pleasing no one.

One person I’ve been following who’s been thinking about other ways of relating to the house that is one’s home is Simon Sarris. In his Designing a New Old Home series, he documents the process of designing and building his home and reflects on what goes into making a home actually feel good. Here he is on why certain materials feel the way they feel:

The obvious problem with some modern material choices is that if they are chosen for a clean look, they often don’t stay that way. New home materials tend to get worse over time: A soiled solid light-gray carpet looks worse than a faded vintage Persian rug, a chipped polyurethane floor looks worse than old, worn wood. Fake materials disintegrate, while natural materials gain patina and grow in elegance.

Old houses harbor much of their charms in the materials themselves, which seem to get better over time, because the wear that the materials take on makes them more beautiful. Raw brass and copper grow a patina. Marble gets scratched or etched. Oiled wood floors get re-oiled, darken with age and get dented. The finishes on these objects are alive. They do not decline so much as they move with time. Even raw plaster, as it is painted and broken and repaired over time, becomes more and more pretty.

Four thousand weeks

2023-01-12T00:00:00+00:00

One of my favorite books I read last year was Four Thousand Weeks by Oliver Burkeman. Here are some of the insights from the book that I’m thinking about a lot as we enter this new year.

The average human life is a measly four thousand weeks long. You definitely won’t have time in your life to do everything you want to do or that other people want you to do.
Hard choices must be made about what to focus on and, just as important, what to neglect. All of us must decide which balls to let drop, which people to disappoint, which cherished ambitions to abandon, which roles to fail at, which experiences to miss out on. The day will never arrive when you finally have everything under control. There is no moment in the future when you’ll magically be done with everything and have loads of free time to finally get to the real work you want to do. Stop postponing the “real meaning” of your existence into the future, and throw yourself into life now.
Each moment of the work you spend your time doing in life can only matter in the moment it is done, not at the end. This is true whether or not your efforts ever reach what the rest of the world defines as fruition and whether or not you live to see your work completed. Life is nothing more than a succession of present moments, and then you die. Now is all you ever get.
No one really cares what you do with your life, and ultimately a single human life is a drop in the bucket of the universe. You can therefore stop worrying about what others think of you, about disappointing anyone, or about being punished for stepping out of line. You are cosmically insignificant, so you might as well stop holding back. Put bold plans into practice, and go after what you want.
Many of the things you’re already doing with your life are more meaningful than you think.

Filtering requests in browser dev tools

2022-04-02T00:00:00+00:00

Sometimes when I’m using developer tools to inspect network requests in my browser, I find myself wanting to filter out certain types of requests that I know are not relevant to what I’m looking for.

To do this, you can enter certain keywords prepended by a minus (-) in the network tab’s search box. To filter out OPTIONS requests, for example, enter -method:OPTIONS. This will prevent OPTIONS requests from showing up in the list of network requests, which can help filter out noise and make it easier to spot what you’re looking for. This works with other parts of a request too such as status-code or domain.

A full list of keywords you can use in Firefox is here. A similar list for Chrome can be found here.

Learning how to learn

2021-04-04T00:00:00+00:00

Julia Evans on getting better at programming by learning how things work:

When I’m asking someone questions to try to learn about something new, sometimes this happens:

me: so, just to check my understanding, it works like this, right?

them: actually, no, it’s

me (internally): (brief moment of panic)

me: ok, let me think for a minute about my next question

It never quite feels good to learn that my mental model was totally wrong, even though it’s incredibly helpful information. Asking this kind of really specific question (even though it’s more effective!) puts you in a more vulnerable position than asking a broader question, because sometimes you have to reveal specific things that you were totally wrong about!

When this happens, I like to just say that I’m going to take a minute to incorporate the new fact into my mental model and think about my next question.

This perfectly captures for me that somewhat horrifying yet exhilarating feeling when I suddenly realize that I’ve been living my life with a completely wrong understanding of something. Exhilarating in part because I’ve come to appreciate that these moments are usually followed by a series of “Wait a sec, does this mean that” realizations where a bunch of other bits of understanding suddenly come into focus and click into place.

Curbing the Twitter instinct

2020-11-17T00:00:00+00:00

I recently came across a neat little tool called Tokimeki Unfollow. You connect it to your Twitter account, and it walks you through the accounts you follow in chronological order and invites you to unfollow accounts that no longer “spark joy.”¹ It also cleverly defaults to hiding account bios to encourage you to evaluate whether each account still feels useful or interesting based on its own merits rather than on its reputation.² Over several weeks, I used this tool to reduce the number of accounts I follow from over 2000 to less than 150. Twitter already feels a lot calmer, more interesting, and less addictive.

Another technique I put into practice recently was to save my Twitter password as a screenshot in 1Password instead of as a text field. Forcing myself to type an unreasonably long password is just enough friction to curb the instinct to check Twitter whenever I feel bored.

On why one might want to dial back social media use, see “Why you should quit social media” by Cal Newport and “Growing apart and losing touch is human and healthy” by David Heinemeier Hansson. ↩
This is something Dan Abramov touched on recently, on Twitter of course. ↩

Livable code

2020-07-19T00:00:00+00:00

One of my favorite tech talks is “Livable Code” by Sarah Mei. She’s given a few different versions of this talk, but I saw it for the first time at RailsConf 2018 in Pittsburgh.¹ Each time I revisit it, I find that my own evolving philosophy of software design grows closer to the one that Sarah offers. I want to note here a few ideas I’ve taken from “Livable Code” that have stuck with me and that I continue to think about often.

Software design is not architecture

Architecture is a poor metaphor for software design. It suggests that designing, building, and maintaining software are discrete phases of a linear software development process and that afterwards the software will be done. This may have been true to a degree at some point in the past, when software was pressed onto disks and sold in boxes at a store. But nowadays, changes to a single codebase may be deployed hundreds of times a day, and the process of iterating on software happens continuously over its lifetime.

Software is a house you live in

Rather than thinking about software development as analogous to constructing a building, it’s more useful to think about software as a house you live in, as interior design. Today, frameworks like Ruby on Rails provide much of the “building structure” for our code (and we might think of different frameworks as we do different styles of architecture, each with different histories, philosophies, limitations, affordances). Instead of having to construct the building then, we get to focus on living in it, arranging the furniture, deciding where to put our stuff, and changing these decisions over time as our needs and desires change and grow. Certain changes are easier to make than others, like re-arranging the furniture or painting a wall. Others are more difficult like knocking down a wall or putting on an addition. None of these changes are impossible, but the cost of change varies and depends partly on the structure we’ve chosen to live in as well as its age, condition, and environment. Any changes we undertake must also consider the needs of everyone who lives in the house beyond ourselves. And like any house, codebases require regular maintenance and upkeep to prevent them from becoming unlivable.

Keeping your code livable

Sarah offers the following four steps to move your code from a place you have to live to a place you get to live, and she stresses that these steps are focused on people, on habits you can adopt with your team, rather than on any specific software design pattern.

Don’t make it worse. When we change code, even if we don’t have time to fix everything in the bloated, confusing file full of terrible sins that we’re touching, don’t make it worse. Try not to repeat the terrible sin in that file.
Improvement over consistency. Sarah illustrates this point well: “Five books in a pile and one on the shelf is better than six books in the pile. Maybe next time this code is touched, someone can move one more of the books to the shelf. But if you wait until you have time to move them all at once, it will never happen.” This one really resonates with me and can be difficult to practice at times, but I think it’s probably the guideline I return to most often.
Inline everything. “No more stories about refactoring a class. Do it inline while you’re executing on stories that actually have business value.” Do the easy things and tackle the low hanging fruit while you’re working on other tasks. Make the big problem smaller, and eventually the big problems will be small. It’s also easier to refactor inline while you have the context rather than having to regain the context when you come back in the future to try to tackle it all at once.
Talk more. Don’t ask for permission to clean up small pieces of code, but be upfront about what you’re doing. Don’t ask forgiveness either because doing this work is part of your job. Learn from the process, so that over time, you hone your sense of when you should have skipped some cleaning up when you took the time to do it and when you should have taken the time to do it when you didn’t. Seek advice from your team (“Is this the right time to do this?”), but don’t always take it. Moreover, work together because you’re living in the code together.

There is no such thing as absolutely correct software design

Many of us have experienced being in a group where someone invokes an abstract principle of “good design” or “proper architecture” to advocate for a particular design decision or direction. These decisions aren’t always wrong, but they often rely on received wisdoms from design pattern books or lazy justifications like “that’s what Google does, so we should too” or “My 30 years of experience make my opinion correct.” This kind of thinking tends to ignore the importance of local context and lived reality, namely that the right design for a particular codebase and the team working on it are unique to the needs of that codebase and that team at that time. And these needs can and do change as the needs of the codebase change (e.g., new features, new requirements, new iterations) and as the team changes (e.g., a small team grows, team members join or leave, a team diversifies its levels of experience).² The continuously changing nature of software development and the ways in which software is situated in the social context of a particular team leads to the realization that there is no such thing as absolutely correct software design. If we can accept this idea, then we can free ourselves to refocus our attention on the actual problems we aim to solve and the people we’re solving them with.

“Livable Code” has helped me develop a more grounded, pragmatic approach to software design and development. It’s an approach that pays more attention to the needs of the team (“Will the least experienced engineer on our team be able to understand and change this code?”), that tries to shift debates over abstract principles towards concrete solutions to actual problems, and that focuses on moving one more book to the shelf and always leaving the code a little better than I found it.³

There is a @LivableCode Twitter account with her original thread on these ideas from 2016. Another great, more conversational, version of this talk can be found on the Tech Done Right podcast. But if you haven’t watched her conference talk, I recommend starting there. ↩
There is more to consider with regards to how the social context of a team affects its software design, but Sarah observes that type safety often benefits larger teams at the expense of individual programmer happiness. This is one example in which something like team size might factor into a technical decision for a given codebase. ↩
Perhaps a future post will dig into more concrete examples of this philosophy in action. Thanks to Dave Kroondyk for providing feedback on an earlier draft of this post. ↩

Writing is thinking

2020-06-30T00:00:00+00:00

For the past few months, I’ve been gradually retreating from social media in an effort to reclaim my attention for working and living more deeply and intentionally.¹ As I back away from the noisy chatter of Twitter and Instagram, I’ve decided to return to blogging. It’s something I’ve wanted to get back to for a while and on a personal website I control, one that doesn’t track or sell personal data.

This blog will be about me thinking, learning, and working in public. I’ll share some nitty gritty, practical things I’ve learned and am learning–mostly about developing software–and discuss projects I’m working on. But I’ll also write about other topics that interest me broadly related to technology, work, and culture. I hope that by writing here regularly, I’ll improve the clarity of my thinking, deepen my understanding of software engineering, and contribute in a small way to a larger conversation about the future we’re creating with all this software.² Hopefully, others will find this interesting too.

Cal Newport’s writings on “deep work” and the “deep life” have had a big influence on me. For more on this, I recommend his books Deep Work and Digital Minimalism, as well as his blog, Study Hacks. ↩
I borrowed the title of this post from Kerry Ann Rockquemore’s “Writing IS Thinking”, an old blog post I used to have my students read when I worked in academia (a topic for a future post). It touches on some of these ideas about writing in order to think rather than to simply dispense information. I also take inspiration from Ta-Nehisi Coates who discusses writing as a “process of learning in public” in this interview in The Atlantic. ↩