When I don’t feel like I’m making sufficient progress at work, I have a favorite technique: asking “What would finishing this today look like?”

Retrospectives are one of my favorite engineering team practices. In this post, I’ll explain why and how I run retros.

When I am preparing development work, I write Gherkin-style stories, which follow the “Given/When/Then” format. I learned this technique at Hashrocket and have practiced it ever since. It’s incredibly effective. But why? In this post, I’ll try to answer that question.

I’ve been lucky to have worked with some great engineers, and one thing that they tend to do exceptionally well is reporting about their work at meetings. Today I’d like to summarize what I think makes a great standup report.

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.

A naive implementation is a programming technique that prioritizes imperfect shortcuts for the sake of speed, simplicity, or lack of knowledge.

I recently completed a winter survival course where we built shelters in just ten minutes with only the contents of our packs. The pack I brought was nearly empty, so I made a tent out of my parka. It was ugly, but it could have saved my life. How does this apply to software? When building a feature, first get it working, then make it look good.

I think the most important factor in consistent delivery is understanding the work. When you understand the work, you build what the stakeholder wants, better and faster.

When I create Agile bug tickets, I don’t add Agile story points. In this post, I’d like to explain this preference via two arguments: pointing bugs creates backward incentives, and bugs are surprisingly difficult to point.

I’ve been working on a development roadmap for my projects, and wanted to share my process. Consider this my recipe to turn an idea into software.

There’s a detail about Today I Learned some might find unusual: we never added a way to delete posts from the site. Why ignore a basic CRUD feature? We didn’t ignore it. It was intentionally omitted.