Jake Worth

Jake Worth

My Daily Programming Routine

Published: April 10, 2023 • Updated: January 05, 2024 4 min read

  • routines

After a decade of programming full-time, I’ve developed a daily work routine that I’d like to share. I hope to revisit it and share it with people who are starting out in the industry or are curious about a programmer’s workday.

Many programmers don’t have a routine. So, first let me answer: why have one at all? A routine at work can be a double-edged sword; overemphasize it, and your day can feel too predictable.

The first reason I keep a routine is that there are some things I must do every day, like team standups. My day goes better when I plan for events like these.

Secondly, there are things that I should do every day, like reviewing my peers’ code. A routine helps ensure I don’t overlook these team tasks.

Each day, I try to accomplish the following tasks in the order listed.

1. Move Tickets to the Right ➡️

I start by reviewing my Kanban ticketing system, which I open with a terminal function:

function pt() {
  open https://www.pivotaltracker.com/n/projects/123456
}

I read from right-to-left. On the right is my “Deployed” column, and left is the “Unstarted” column. All the other tickets are somewhere in between those two states.

My goal is to move each ticket to the right. For example:

  • A ticket that’s passed QA gets deployed to production
  • A ticket that’s passed code review gets sent to QA
  • A rejected ticket gets triaged and fixed
  • A ticket in progress… more on that below
  • A ticket that I’m ready to work on gets started

If I can’t move a ticket, I try to figure out why.

I go right-to-left each time so that I’m systematically unblocking work, starting off with the highest-value activity, deploying to production.

2. Review Colleagues’ Work 📋

Next, I review my colleagues’ work. I use a terminal function named rr to open the GitHub page of reviews assigned to me.

On my team, code reviews are required to merge, so once I’m assigned to review, I’m blocking progress until I leave feedback. I try to follow this checklist.

3. Finish My In-Progress Work 🚀

Okay, we’re coding! Any work that I’ve left unfinished yesterday, I finish.

Something that helps me pick up unfinished work is committing small, well-named commits on named branches that are always pushed to the remote. My Git log tells a story:

$ git log
ab9e405 Add (failing) test
1ud5bx7 Styled per design
59d5bd7 Complete solution
4bd3580 Initial spike

When I see this log, it’s clear to me what I need to do: make the failing test pass.

I start by checking out main and rebasing my branch interactively. This lets me pull in changes and squash or rewrite commits that don’t tell the story I’m trying to tell.

If I finish the day with work unfinished, which happens often, I write myself a note describing what’s left, such as “cleanup CSS open PR.” I use an executable called figlet for this job, which prints my note in the terminal and forces me to be concise.

$ figlet "OPEN PR"
  ___  ____  _____ _   _   ____  ____
 / _ \|  _ \| ____| \ | | |  _ \|  _ \
| | | | |_) |  _| |  \| | | |_) | |_) |
| |_| |  __/| |___| |\  | |  __/|  _ <
 \___/|_|   |_____|_| \_| |_|   |_| \_\

4. Standup 🤝

This is our mandatory team meeting. I have a terminal function that opens the Zoom call.

I show up, make small talk, give a report, and try to be helpful.

5. Bonus: Personal QA 🔎

Sometimes when I have extra time, I’ll do a short QA of our application.

My goal is to find things that I know are broken or could be better, addressing what I can. If I can’t fix it right away, I write a ticket.

I’ve only started doing this recently and it requires a boss who’s okay with me going rogue. I find it immensely valuable because I get to scratch my own itches, increase my ownership of the product, and fix bugs before they’re found by QA, management, or customers. Few manager are going to schedule ‘tech debt’ time, even when it would conclusively increase velocity, so we engineers have to take it ourselves.

6. Move Tickets and Review Colleagues’ Work, Revisited ➡️ 📋

I end the formal portion of my day with one more pass at the ticket board. Sometimes I’ve been waiting for a CI build or a colleague to review my work; this is my chance to react.

I’ll also do another pass at code reviews to ensure I’m not leaving anybody waiting. I use the following filter on my GitHub repo’s pull request search bar to see just what I’ve been assigned to review:

is:pr is:open user-review-requested:@me

7. Spin the Flywheel 🎡

Spinning the flywheel– permanently documenting what I’ve learned– lets me learn and graduate to harder, more interesting problems. Any time I learn something noteworthy, I try to think about how I can cement that knowledge.

Typing up what you learned anywhere is valuable, but the medium matters. Count those keystrokes.

The least effective place to share what you learned is an asynchronous chat like Slack. These feeds are fast and noisy and what you write there is going to get lost.

I usually pick my TIL repo, where I’ve been writing short posts since 2015. Hashrocket’s TIL grew out of this idea.

For ideas I’ve revisited again and again, I post on this blog.

Wrapping Up

Here’s the routine:

  1. Move tickets to the right ➡️
  2. Review colleagues’ work 📋
  3. Finish my in-progress work 🚀
  4. Standup 🤝
  5. Bonus: personal QA 🔎
  6. Move tickets and review colleagues’ work, revisited ➡️ 📋
  7. Spin the flywheel 🎡

It’s an infinite game.

What are your thoughts on daily programming routines? Let me know!


Join 100+ engineers who subscribe for advice, commentary, and technical deep-dives into the world of software.