Laws like these are fun - not always easy to remember, not always practical in day-to-day existence, but once you start internalizing them it's cool to see their application pop up from time to time.

I'm probably making a few of these mistakes on my personal projects. Worth a read to find some quick wins for HTML accessibility.

A pretty solid guide to configuring your displays and finding an external monitor that optimizes for text clarity (and basically nothing else). I found a couple useful tweaks for my own personal set up here.

"Experts say the following decades of research have turned up similar findings. Escalating force by police leads to more violence, not less. It tends to create feedback loops, where protesters escalate against police, police escalate even further, and both sides become increasingly angry and afraid."

"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.