Published: April 10, 2023 • Updated: August 29, 2023 • 4 min read
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 myself 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 rigid and predictable.
The first reason I keep a routine is that there are 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 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.
I start by reviewing my Kanban ticketing system (Pivotal Tracker, Trello, Jira, etc.) 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:
If I can’t move a ticket, I try to figure out why.
I go right-to-left each time so that I’m starting off the process by shipping, the most high-value activity.
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.
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 end the day with work unfinished, which happens often, I write myself a note describing what’s left to do, 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" ___ ____ _____ _ _ ____ ____ / _ \| _ \| ____| \ | | | _ \| _ \ | | | | |_) | _| | \| | | |_) | |_) | | |_| | __/| |___| |\ | | __/| _ < \___/|_| |_____|_| \_| |_| |_| \_\
This is our mandatory team meeting. Show up, make small talk, give a report, and try to be helpful.
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 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.
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 asked to review:
is:pr is:open user-review-requested:@me
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 lost.
For ideas I’ve revisited again and again, I post on this blog.
Here’s the routine:
It’s an infinite game, one I can endlessly improve.
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.