"I want to remind everyone that at the end of the day my job isn’t drawing cool bitmaps just like your job isn’t writing JavaScript. We are all building things, we are all creating something, and each of us have something to contribute with in different ways."

This is seriously good advice that every startup (and I suppose even every product company, regardless of size) should think about. We published changelogs early on at Spectrum, but eventually stopped – I can't even remember why. But I do know that the lack of them hurt our ability to share momentum and excitement with our early users.

"...be more prolific with just one easy trick" – I do find the framing of this post useful. I've historically been so slow to write in public because of this sense that the written word is final. But it's not. Having a mindset shift to write more fluidly and iterate over time (aka digital gardening) is freeing. One thing that's been cool is having the "Was anything wrong or incorrect?" prompt at the bottom of each of my posts – people actually use it to correct me, and blog posts get incrementally more correct over time.

I love this. Write to learn, not to teach.

"To suit our unique needs, we designed and open-sourced $AN_ENGINEER_TOOK_A_MYTHOLOGY_CLASS, a highly-available, just-in-time compiler for $UNREMARKABLE_LANGUAGE." Ha! This hits home. We named all of our worker servers after Greek and Roman mythological characters. The rest of this post is simultaneously hilarious and poignant.

The idea of what makes software "high quality" has been on my mind lately. Shipping bugs and breakages is a cost of doing business; I'm guilty of having this mentality when I build – "we can always fix it later!" We should hold ourselves to a higher standard, but an incentive structures to ship things that won't break doesn't exist in most organizations.

I've been thinking a lot about deliberate practice. What does it mean for designers to practice, if we spend every day "doing the work?" I want to spend more time digging into posts like this, and some of Andy Matuschak's thinking on this. See ref and ref2 for more.

This form of tutorial is wonderful. I've seen this kind of scroll-and-tween design used on the SwiftUI tutorial and the Stripe payment tutorial, but this Build Your Own React was my first time seeing the pattern – so good!

My favorite point is "Good design is redesign," especially the line "It helps to have a medium that makes change easy." I've been thinking about this a lot in the context of side projects and working on my personal website. In the past it was such a pain to iterate, to redesign. The friction to expressing improvement made me give up. So now I'm focusing on designing things that are easy to change, or even better: easy to delete.

The contrast between the two visions of the future was startling. Popular culture has always told me that the future is shiny and sleek and made of glass. But in reality, that place looks terrible.

Chat is hard. We spent a long time trying to figure out a hybrid thread/real-time-chat model at Spectrum, but we never quite got there. There must be better primitives in our tools to account for the way conversations are structured in the real world: divergence, amends, reactions, context.

Very creative, and staggeringly hard to comprehend. It just...keeps...scrolling.

I'm often flipping between inlining some styles to prototype the way something should look, then formalizing that into a styled-component. Unfortunately moving between the two formats is tedious – not any more!