These are my longer essays.
Two-Follow-Up Rule for Closing Support and Internal Tickets
I recently learned a practice for customer communication that I’d like to document. It’s called “Hit It Twice.” ...
These are my longer essays.
I recently learned a practice for customer communication that I’d like to document. It’s called “Hit It Twice.” ...
One common trait among early-career programmers is seeing technology choices in black-and-white. I’ve been there. “Redux is awesome!” “Nested ternaries are terrible!” As you advance as a programmer, for better or worse, you start to see almost everything as a trade-off. ...
My definition of “I don’t understand” debugging. ...
I’ve been organizing Meetups for a decade, starting with Vim Chicago and Chicago Elixir, and now running Maine JS from Portland, Maine. In honor of our most recent Meetup, here’s my practical guide on how to start a Meetup group, based on what’s worked for me. ...
Here’s my annual review covering 2024. ...
This post is about how to write software well. It was inspired by this post with a similar title. Read it and write yours. ...
TONY: We should take this outside. ...
I was the third engineer hired by my company, not counting our technical co-founder. I like that position, and it seems to play to my strengths. ...
Today I’d like to talk about a quality that’s essential to success as a computer programmer. Let’s call it “comfort with discomfort.” As programmers, we live in this unsettling space. Here are some thoughts on discomfort and tips for dealing with it skillfully. ...
Often, when you work as an engineer on a small team, you don’t have dedicated designers on staff. How can you deliver beautiful, intuitive software without designers? Here’s a trick that helps me: decoupling my design work from my engineering work. ...