Unfortunately you sometimes need to do the thing | Griffin Berlstein

Griffin Berlstein

Not Entirely Clueless

Blog

Projects

Publications

CV

Contact

Colophon

&copy 2026. All rights reserved.

Unfortunately you sometimes need to do the thing

2025-03-21

In which I meander about creative tasks and offer some advice on learning to write Rust code (or any other programming language really).

So I am fortunate enough to write a fair bit of code in the course of my<br>research. Over the past several years this has primarily taken the form of Rust,<br>a language I really like but that has a reputation for being difficult to pick<br>up. So how do you go about learning Rust, or any other creative skill for that<br>matter?

Like many people I suffer from a bad case of perfectionist brain gremlins, which<br>can make it very hard to get things done. They’ve a paralytic effect that can be<br>hard to manage, particularly in the early stages of things. Writing words, the<br>thing I am doing now, is a real pain point. The complicated, messy process of<br>taking ideas from the churning mass of thought-soup that is the conscious and<br>pinning them down with language is something I become easily frustrated by. This<br>frustration stems entirely from the recognition that what I’ve made, that what<br>sits in front of me, is not what I want it to be. Either it’s missing some<br>essential truth, feels self-indulgent, requires foreknowledge not contained<br>within the writing, or one of many other unavoidable imperfections of existence.

There’s no getting away from this. No matter what you’ve made, it can almost<br>always be improved in some way, even if you’re the only one who would notice.<br>And caving in to this desire to polish, to improve, is a fantastic way to get<br>nothing done at all, or to never even start. The most perfect version of a thing<br>is the imagined idea of it; and unfortunately that version will never and can<br>never actually exist in the world.

So here’s how I think about it: our brains are lazy—or efficient depending on<br>your perspective—and tend to be very use-it-or-lose-it about skills. And,<br>unfortunately, this means you have to do whatever it is you want to learn and<br>that you’re going to be bad at it, at first. And that, well that sucks, doesn’t<br>it? It would be nice if thinking hard about something was enough. But I suspect<br>that art would be a lot less compelling if that were the case.

Boiled down to its simplest elements, I think the act of creating something, be<br>it art or code, looks something like this:

Start with an idea fragment

Attempt to make it

Assess what was made

Improve until “good enough”

And in my experience, my failure mode looks like jumping right to assessing what<br>I’ve made after the smallest amount of creation. It’s easy to slip on the<br>editor’s hat before the author is done, because making things is, quite often,<br>challenging. And while good critique is hard, criticism is quite easy. This<br>looks something like

Start with an idea

Make a tiny bit

Spiral

Go browse the web instead

I’ll get to this project later. Totally.

But here’s the thing, it’s almost always the case that you don’t really<br>understand what you’re making until after you’ve finished trying to make the<br>first version of it. I believe this is true for writing as much for code<br>development. And until you actually know the shape—not merely the vibe—of<br>what you’re making, criticism is largely paralytic and insidious in the way it<br>promises improvement while grinding everything to a halt.

Put another way, there are, broadly speaking, two layers at which you have to<br>understand a piece of work: High-level and Low-level. The former is the big<br>picture, the broad goal, the overall approach, while the latter is all the work<br>and mechanics needed to accomplish it and manage all the messy troubles of<br>reality.1 This high-level view of the work is necessarily incomplete<br>and should be revised based on understanding gained from the actual doing, i.e.<br>the low-level work. Recognizing this is how we make actual progress, rather than<br>becoming discouraged when the high-level understanding clashes with the<br>low-level work. In this way, the two layers form a loop: the doing improves the<br>high-level understanding and the high-level understanding guides the doing lest<br>it get lost in the weeds.

This is starting to sound an awful lot like self help. Gross.

Okay, brass tacks, how do you learn to program rust? Well, in short, I recommend<br>that you first read at least the beginning of the Rust Book and then as soon<br>as possible start writing some code. Make a tiny project to do whatever silly<br>thing strikes your fancy. You can try rustlings. You could even follow<br>some tutorials.<br>There are a ton of educational resources out there,<br>and I’m certain some of them will work for your brain.

But remember: you should always actually write the code yourself. It is far too<br>easy to look at a piece of code and think “yeah I get it” without actually<br>understanding or retaining it. Incidentally, this is...