Posts

This is a response to “Don’t Guess” from the excellent “The Best Programmers I Know” by Matthias Endler. My goal is to crystallize my understanding of this trait. “In the face of ambiguity, refuse the temptation to guess.” –The Zen of Python, Tim Peters Guessing is defined as “form[ing] an opinion of from little or no evidence.” As a programmer, it’s tempting to guess while debugging. We might say: “Hey, I wonder if this is happening in GamePlanSyncer? That sure causes a lot of bugs”, while nowhere near the corresponding code. ...

If something in your software is confusing to a customer, it is confusing. It is! There is something about it, that you might not see, that doesn’t make sense to a nonzero number of your customers. Stop trying to outsmart the bug report and consider it. Will you encounter a few outlier customers who are hard to please? A few more who struggle with what seem like obvious interfaces? Yes and yes. ...

I’ve added TypeScript to several projects I’ve worked on. In this post, I’d like to discuss why I think TypeScript is essential and document my expectations around it. What Is TypeScript? TypeScript is a type-safe superset of JavaScript developed by Microsoft. JavaScript is a dynamic language and doesn’t have type-safety. But with TypeScript, it does! It’s also a gradual type system, so one file in a codebase can be converted from .js to .ts, and with a server or process restart, type-checking is performed on that file. ...

I recently learned a practice for customer communication that I’d like to document. It’s called “Hit It Twice.” The quoted language in here is broad and should be adapted to the situation. Why This Matters Customer issues deserve prompt attention. And, we have to prioritize customer issues that matter. Customers responding to offers of help, or not, tells us how much they care about the issue. “Hit It Twice” Scenario: a customer opens a support ticket. We respond with a proposed solution or a clarifying question, ensuring they have the next step to move forward. ...

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. It’s Tradeoffs All the Way Down Trade-offs at a low level, such as choices made within an individual code file, and trade-offs at a strategic level, such as which technology tools to invest in and people to hire. It often feels like it’s trade-offs all the way down. ...

My definition of “I don’t understand” debugging. I once heard Malcolm Gladwell claim that his father, a professor, would have never fallen for Bernie Madoff’s Ponzi scheme. He felt his father was too curious and unafraid to admit when he didn’t understand something. He’d listen to the pitch, then quietly say: “I don’t understand that; please explain it to me again.” Again and again, until the explainer gave up. I call this “I don’t understand” debugging. It’s something I’m proud to have picked up watching some greats at Hashrocket. I can’t always summon it, but when I can, it’s magical. ...

I’ve been organizing Meetups for a decade, starting with Vim Chicago and Chicago Elixir, and now running Maine JS from Portland, Maine. Here’s my practical guide on how to start a Meetup group, based on what’s worked for me. How to start a meetup group The steps that follow are in rough order. You’re going to be doing many of them in the beginning; that’s the time when you do the most sustained work. ...

Here’s my annual review covering 2024. Work Big news: the software portal I’d been building for over a year launched! It was a ton of work: ups, downs, and updating caniuse-lite. We defied escape velocity and launched. I was proud of my team and my growth in achieving this milestone. Soon afterward, I got a new job and got promoted! I’m enjoying the challenge. I’ve learned that I’m happiest when being pushed and working on tough problems. I’m grateful for James Stanier’s book Become an Effective Software Engineering Manager, which I bookmarked liberally. ...

This post is about how to write software well. It was inspired by this post with a similar title. Read it and write yours. These ideas aren’t advice but rather notes about how I do my best work. If you’re new, some of these ideas might seem obvious, but they get harder as you progress, or your understanding of them deepens, or you’ll encounter engineers who embody them in surprising ways. ...

TONY: We should take this outside. JARVIS (O.S.): I must strongly caution against that. There are terabytes of calculations still needed – TONY: We’ll do them in-flight. Before Your Take it Outside (Ship) There’s been a lot written in our industry about the value of taking it outside (shipping). Today I’d like to write a little more, with an idea that I think makes the value of shipping clear: shipping tells you, precisely, what matters. ...