Hey friends 👋 I hope you had a fantastic week. Mine was particularly great—I attended Epic Web Camp and the Utah JS conference last week, where I made tons of new friends and watched some pretty cool talks.

This week I'm experimenting with a slightly different format for the newsletter. You'll notice that today's issue is a bit shorter and a bit more concise. A bit cozier even, but with roughly the same amount of goodness (or the same amount of badness, depending on how much you like reading my ramblings.)

I'll probably come back to the previous format in the next issue, but I wanted to try out something different and see how it feels. I'd love to hear what you think of it! Do you love it? Hate it? Are you completely indeferent about it? Reply and let me know!

Also, a quick update on the Fundamentals course: it's finally done! All content has been edited and recorded, and all that's left is just some tweaks on the website. I'll launch the course this Thursday, September 19th, and I can't wait for you to check it out :)

Alright, let's dive in.

SOFTWARE DESIGN

Make a Mess, Then Clean It Up

About a year ago, I attended one of Oliver Burkeman's workshops on designing creativity systems, in which I learned what has since become my favorite piece of writing advice:

"Make a mess, then clean it up."

When I sit down to write this newsletter, for example, I resist the temptation to polish up each sentence and paragraph as I write it, and I force myself to write an entire draft in one go without focusing on quality at all.

The end result looks absolutely terrible, of course—but that's fine because I can always come back to clean things up.

Making a mess can be uncomfortable sometimes, so following this advice is not always easy. But it is certainly easier than the alternative, which is staring at a blank screen for hours on end without making any progress.

As a self-proclaimed overthinker, I'm very familiar with the whole "staring at a blank screen for hours" ceremony. I struggle with it when I have to write words, and I sometimes struggle with it when I have to write code.

So in an effort to stop banging my head against the keyboard so frequently, I've recently started experimenting with the "make a mess, then clean it up" method at work—and I have to say it's been working surprisingly well.

When a task is too hard or unclear, instead of spending what used to be ridiculous amounts of time planning the perfect way to implement it, I now spend two minutes finding a starting point, and I start coding.

I write code in the same way my kids play with their toys around the house—without a single care in the world of the mess they're leaving behind. And let me tell you, it's some of the ugliest-looking code you've ever seen.

Poorly named variables? Yes, please.

Functions that span thousands of lines of code? I'll allow them.

@ts-ignore and any's? More than you can count.

I've written some of the worst code of my career in the last few months, but that's totally OK because nobody gets to see it. By the time it hits the Github repo, it's already been cleaned up.

I've found that this isn't only a great way to get myself unblocked whenever a task seems paralyzingly complicated, but it also often results in a better implementation than what I would have come up with if I just spent hours crafting a "perfect" plan.

This isn't a bulletproof method, of course—lots of tasks do require more thoughtful planning. But when you're not sure where to start, starting anywhere is typically better than not starting at all.

If you're willing to give this method a try in your own projects, here are some quick tips that might be helpful:

1. Don't skip the cleaning up part. Once you have a messy working implementation, it can be tempting to just push it up to the main branch and hope that no one will notice. But I'd strongly advise against doing this. Even if you're the only person working on this project, your future self will thank you for taking the time to clean things up.
2. Seriously, don't skip it! I know you're still thinking about it. And I know spending time cleaning up code can be hard to justify with a looming deadline on the horizon. But it really is important to clean up your messes, so if you truly can't do it now, make sure you prioritize it for the near future.
3. Keep your messes small. A small mess is exponentially easier to clean up than a big mess. And the harder something is to clean up, the greater the chances you'll want to skip it. You're not still thinking about skipping the clean-up part, are you?
4. Write tests before cleaning up. If you're going to write tests for your code (because of course that's a thing we all do, right?), a good time to do it is right after you finish with your messy but fully functional implementation, but before you start cleaning things up. Passing tests will help you make sure you don't break your functionality during the cleanup phase.
5. Use AI to clean things up. LLMs are great for this. Using your messy implementation as a prompt, you can instruct the bots to simply give you a cleaned-up version and it would typically produce something that is 90% of the way there. This is, by far, the most common use case of AI in my workflow.

I'll leave you with this wonderful quote from Anne Lamott's classic book Birdy by Bird on the effectiveness of writing "shitty first drafts":

The only way I can get anything written at all is to write really, really shitty first drafts. [...] Almost all good writing begins with terrible first efforts. You need to start somewhere. Start by getting something – anything – down on paper. A friend of mine says that the first draft is the down draft – you just get it down. The second draft is the up draft – you fix it up.

Lamott is talking about writing words here. But as someone who learned to write really, really shitty first versions of whatever it is I'm implementing, I can assure you that her advice applies to writing code equally as well.

ARCHITECTURE SNACKS

Links Worth Checking Out

• All of the Laracon US talks are now available to watch on YouTube, and I've been slowly catching up with them. A couple of my favorites so far are Adam Wathan's talk on Designing a Component Library, and Kapehe's wonderful talk Building Your Village—which I had the pleasure of watching a mini-version of live last week at Epic Web Camp.
• Tomas Stropus wrote a great article on The Art of Finishing side-projects, the cost of leaving them unfinished indefinitely, and a few practical strategies for actually getting things done.
• Moriz Büsing wrote a short essay on the usefulness of optimizing your code for greppability to make it easier to find things in your codebase. Not to be confused with grapeability, which is the ability to eat nothing but grapes for every meal of the day—something my kids are pretty good at.
• The CSS @property rule recently gained support in all modern browsers, and this article and very cool demo by Ryan Mulligan is a fantastic way to learn how it works.
• Speaking of CSS, one of my favorite reads of the past week was this fantastic blog post by Josh Comeau on how the :has pseudo-class works. That's right, two CSS articles in a single issue, so you know they're both that good.
• Sandro Maglione wrote a free course for getting started with XState—everyone's favorite state-machine-based state management tool.
• Jamie Peters wrote about the benefits of writing clean, maintainable code, including a potentially life-saving piece of advice: "Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live."
• The code examples in that last article were all written in PHP, but that's OK, because according to Dave Kiss, PHP is the new JavaScript.
• ​You Don't Have Time to Read Books That Won't Change Your Life.

That’s all for today, friends! Thank you for making it all the way to the end. If you enjoyed the newsletter, it would mean the world to me if you’d share it with your friends and coworkers. (And if you didn't enjoy it, why not share it with an enemy?)

Did someone forward this to you? First of all, tell them how awesome they are, and then consider subscribing to the newsletter to get the next issue right in your inbox.

I read and reply to all of your comments. Feel free to reach out on Twitter or reply to this email directly with any feedback or questions.

Have a great week 👋

– Maxi