Jake Worth

• routines

After a decade of programming full-time, I’ve developed a daily routine that I’d like to share.

Why Follow a Routine?

Many programmers don’t have a routine. So, first let me answer: why follow one?

A routine at work can be a double-edged sword. Overemphasize it, and your day can feel too rigid and predictable.

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

Secondly, there are things that I should do every day, like reviewing code. A routine helps ensure I don’t overlook these team-supporting tasks. It’s even more critical with colleagues in multiple time zones.

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 from right-to-left, moving tickets to the right. On the right is my “Deployed” column, and left is the “Unstarted” column. All the other tickets are somewhere in the process.

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 deployed to QA
• A rejected ticket gets fixed
• A ticket in progress… more on that below
• A ticket that I’m working on but haven’t “started” gets started

If I can’t move a ticket, I try to unblock it.

I go right-to-left each time so that I’m starting off the process doing the most high-value thing: shipping.

2. Review Colleagues’ Work 📋

Next, I review my colleagues’ work. On most teams I’ve been a part of, code reviews are mandatory, so once I’m assigned to review, I’m a blocker 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, always pushed to the remote. If I do it right, the Git log tells a story:

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

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

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

4. Standup 🤝

This is our mandatory team meeting. Show up, make small talk, give a report, and be helpful.

5. Bonus: Personal QA 🔎

Sometimes when I have extra time, I’ll do a short personal 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 team with high trust. 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.

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

I end the formal portion of my 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 asked 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 leverage 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 buried.

My medium is 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, one I can always endlessly improve.

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