Today I’d like to share a small part of my practice: using a persisted scratchpad text file for jotting things down.

One of my all-time favorite programming tools is Dash by Kapeli. In this post, I’ll share some tips for leveraging this fantastic program.

When testing with data, I prefer realistic data rather than random data.

I believe that luck is part of every professional journey. Here’s a sampling of the luck I’ve had.

This is a list of all the best debugging tips I’ve picked up over the years. Some of these might seem obvious, yet we forget them when it counts. Debugging is a skill. You have to bring every tool you have to the job.

My development environment depends on several processes running. Here’s how I’ve scripted this setup.

Perhaps you’re familiar with this scenario: you’re debugging and stuck. You’ve Googled, read some blog posts and docs. You return to your search engine, type some characters, and then something strange happens: the search engine autocompletes your question, and the results are all purple because they have been visited by you. I’ve come to recognize this moment as always a symptom of a broken mental model.

Action items are small, defined, actionable TODOs to follow up on after the meeting. An example: “close all pull requests opened more than 90 days ago.” Agile retrospectives should produce many of these.

There’s almost always a better variable name or value than ‘foo’. It’s useful as a debugging placeholder, but it almost never belongs in production code, even and especially in automated tests.

I think a great migration database migration is: correct, atomic, reversible, consistent with the style of the application, and (mostly) uncoupled from your application and RDBMS.