Always Be Demoing

Any given day when writing software, I can have ambiguous and ambitious goals. Sometimes, that can be overwhelming, so here’s how I tackle wrestling with that problem in a recursive pattern that I can repeat daily (it’s a habit I try to instill in other engineers as well):

Every day, have a demo of what you accomplished.

Your daily report should never be “I was working on X, today, I’m going to be working on X some more”. Instead, focus on concrete artifacts that you can produce by the end of the day.

At the start of each day, think about a “physical” artifact that you can generate.

At the start of a project this might be:

• A page of unanswered questions.
• The first draft of a design document.
• A fully scoped design document ready for review.
• A sketch of what the UI might look like.
• A prototype or proof of concept that validates core assumptions.
• A diagram with component interactions.
• A user journey map showing the complete flow through your feature.
• A set of high level tests that all fail.

These demos can be shared (I like to broadcast to my own slack channel), but they don’t have to be, what’s important is to find a concrete object to deliver.

As the project progresses, your daily artifacts evolve:

• Working code.
• Unit tests that demonstrate specific functionality.
• API endpoints that can be tested with curl or Postman.
• Performance benchmarks showing system behavior under load.
• Error handling scenarios that demonstrate graceful failure modes.

The key is tangible progress that can be shown, not just described. Instead of saying “I worked on the authentication system,” show a login flow that actually works (or fails in expected ways).

Not all work produces visible artifacts immediately. Software development involves a lot of invisible work: refactoring, performance optimization, security hardening, and technical debt reduction. These efforts are critical but hard to demonstrate.

For invisible work, create artifacts that make the impact visible. A pull request, ready for review or (better) merged, is a tangible message that others can see and understand. You can also create before/after performance comparisons, code complexity metrics, or test coverage reports.

Adopting a daily demo practice changes how you approach work:

1. Focus on deliverables: You naturally prioritize work that produces demonstrable results.
2. User empathy: Regularly showing your work keeps the end user experience in mind.
3. Risk mitigation: Daily demos surface problems early when they’re cheaper to fix.
4. Team alignment: Regular visibility ensures everyone understands the current state.
5. Documentation by default: Preparing demos creates natural documentation of your work.

The practice of “always be demoing” transforms both individual productivity and team collaboration. Whether it’s a formal end-of-cycle review or a daily check-in, the discipline of preparing something concrete to show drives better decision-making and clearer communication.

Start small: at the end of today, have something you can demo tomorrow. It doesn’t need to be perfect or complete—it just needs to exist and demonstrate progress toward your goals.