My Daily Programming Routine

- 6 minutes read - 1122 words

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 single day, like team standups. My day goes more smoothly when I plan for events like these.

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

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

1. Review Colleagues’ Work 📋

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

Why start with reviewing? Code review is a great first-cup-of-coffee task for me. I think I provide a lot of value when doing it, so it helps my team right away, yet it doesn’t take all my brain the way programming does. I actually think it’s a bit better to not be totally ‘on’ when reviewing code. If something doesn’t make sense to me in that state, it’s probably too complicated.

When reviewing, I try to follow this checklist.

2. Move My Tickets to the Right ➡️

Nest, I review 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 most valuable activity, deploying to production.

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. When I do this, my Git log tells a story:

$ a 1 5 4 b u 9 b g 9 d d d i e 5 5 3 t 4 b b 5 0 x d 8 l 5 7 7 0 o g A S C I d t o n d y m i l p t ( e l i f d e a a t l i p e l e s i r s p n o i g d l k ) e u e s t t i i e g o s n n t

Reading from bottom to top, I: created a spike, got it working, styled it, and added a failing test. It’s pretty clear to me what I need to do now: make the 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 right story.

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, where I’m most likely to look in the morning.

$ f i g l e t " O P E N P R "

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. It’s a version of exploratory testing.

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 empathy for our users, and fix bugs before they’re found by anybody else. Few manager will prioritize tech debt, even when it would increase velocity, so we engineers sometimes have to prioritize 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:

i s : p r i s : o p e n u s e r - r e v i e w - r e q u e s t e d : @ m e

This is also codified into a terminal alias, rr.

7. Spin the Flywheel 🎡

Spinning the flywheel– publicly 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 document 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 quickly 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. Review colleagues’ work 📋
  2. Move my tickets to the right ➡️
  3. Finish my in-progress work 🚀
  4. Standup 🤝
  5. Bonus: personal QA 🔎
  6. Move tickets and review colleagues’ work, revisited ➡️ 📋
  7. Spin the flywheel 🎡