I find myself in an interesting and exciting position in my new role with Asynchrony Labs. My team is a really well-oiled machine (something I’ll write about in depth at a later point) — but because of this, sometimes our testing time leads to us having some pretty decent lag in-between “productive” moments.
I’m actually using the lag right now to write this article— it’s pretty common that at least once (if not several times) a day, we have to fire off a build which includes all of our levels of integration testing. Right now, that’s zeroing in on 20 minutes where we have “time to kill” at our desks.
There are times we use this downtime for camaraderie. Since we’re a pair-programming team, often our pairs will share humorous stories we’ve heard or interesting anecdotes from the programming community.
There are times when we use this downtime for administrative tasks, like tracking hours, answering emails, or stepping away from our desks to grab a snack or take a quick walk.
But that’s not enough to fill every gap. At times lately, I’ve taken to perusing Twitter or Facebook just to pass the time, and often, even these don’t really hold my attention, because on any given day, I’ve already checked them for 20 minutes.
So this leaves me with time. Time to think. Time to reflect. Time to take better advantage of my time. And so far, I’ve been really bad at it.
I’ve spent some of this downtime just kind of checked out or bored. I’ve spent some of it doing things that don’t really enrich me, my team, or my project (like checking Twitter or Facebook compulsively).
There are so many ways I could spend 20 minutes a day (or more) doing productive things that will help me in the long-term with my career or my home life. But for some reason I haven’t thought about them at all—until now. Here are some things that I’ve recently started incorporating into my downtime that’s made me feel much better about my own personal productivity.
Writing
As in, what I’m doing right this second as I wait for the build to pass or (hopefully not) fail. I’ve stepped away from my habit of writing for a while; I’ve missed it, and now the writing bug is ready to seize the day again. Generally my writing happens either in long-form (such as this blog article) or as journaling.
I’ve started journaling more using the Bullet Journal System, which has given me several ideas for blog topics and helped me with self reflection. Logging the specific things I’m working on every day, alongside logging my ideas, helps me come back to them later instead of losing track of them altogether.
I’ve also started using this time for blogging again. The large bulk of this article came to pass during one of my build downtimes.
I hope to pick up my writing momentum and be more motivated to do so again. Writing really frees me up as an individual and helps me share my experiences with those around me. I’ve been a bit… ahem… off the wagon for the last several months, but now that things are in a good place at my office, I should certainly be writing more again.
Reading
There are so many books on my list that I can’t even begin to imagine getting through all of them in any realistic timeframe. Some of them apply directly towards my career or my ultimate end-game for income. As such, some of them are very technical. Right now I’m diving deep into Clean Code by Robert C. Martin.
I also recently rediscovered my love for fiction. While there’s so much enrichment that can happen when reading various non-fiction and educational material, fiction has really proven to me that disconnecting from reality for a little while really makes a big difference. It helps me clear out my headspace from all of the general distractions that don’t really help with anything, to make room for more critical thinking, creative thought, and overall general brain health.
The list of novels I want to read is much shorter than my non-fiction list. But reading really has become important to me again, after neglecting it for a while. Right now I’m really itching to read the Wheel of Time series, because I imagine it will take me away on a grand adventure when I do.
When I’m at work, I tend to focus on reading non-fiction enrichment topics, because I feel like I have so much more to learn all the time. My reading list of non-fiction, related either directly or tangentially to programming, is rather long. As such, when I do sit down to read I like to hit no more than one chapter at a time, taking notes in my Bullet Journal and really absorbing what it is I’ve read about.
Collaboration
Often my team spends time talking with each other while we wait for things to happen. We talk about ways we can improve our current codebase. We talk about ways we can bring in new project work. And we just talk about life.
And now the shy introverts reading are going “Hold up! Talking, as in… with people?!” Yes, talking with people really helps get programming creativity going. While I totally get wanting to read that cool article or check on that programmerhumor post, sometimes it really does pay to just turn around and talk to another person. I promise!
I’m very proud of the fact that my team is close-knit. We have a certain inherent safety in our working relationships with one another, and much of that stems from the fact that we all talk to each other about anything and everything several times a day.
We build this trust through camaraderie and regular open and honest feedback. Team onboarding includes a 30-day reflective review from other team members, providing honest critical tools that new team members can use to actively respect the culture of the team.
We also like to use something called a Team 360 on occasion. In these kinds of conversations, the whole development team sits down and comes up with one strength and one weakness for each team member, and then we have one-on-one talks with each other about our ideas to help one another get better at working as a team.
I like to think of my team as following the mantra from the old Magic School Bus series. “Take chances. Make mistakes. Get messy!”
No matter how big of a mess we end up making, we always have each other’s backs and make decisions as a team. Lone guns need not apply!
Going for a Walk
One of my teammates and I go on a walk at least once a day now. We generally just go outside and walk around a couple of city blocks, so that we can get fresh air and sunshine.
It helps clear out the mental cobwebs and reset our brains for focusing. Getting away from the desk altogether really helps make desk time more bearable.
Going for walks isn’t your only option, but it sure is a good one. You could also look into getting a standing desk, to get the blood flowing. You might also try an exercise ball. I’m sure there’s other ways to get a bit of movement at the desk. Either way, I highly recommend moving around more. As I wrote about in The Programmer's Great Clinical Depression, physical exercise really is one of the best ways to get a brain boost.
Sharpening the Saw
Sharpening the saw, a term defined in 7 Habits of Highly Effective People, is one of the most important things we can do for our careers.
As we continue to evolve and become more and more expert in a particular subject, it’s important that we don’t develop tunnel vision. Sure, we need to continue to re-up ourselves on our already acquired hard skills. But so much of what we do can’t survive if we don’t appreciate our own selves and strengths beyond what’s in the codebase.
I’ve found myself relishing the times I spend doing things not related to my line of work.
I’ve taken up working on some of my fine art skills lately, specifically learning how to do hand-lettering (or calligraphy) and also refining my abilities with graphite and other drawing media. I also come up with silly illustrations that my team really appreciates.
I don’t spend much time doing this activity at the office because I don’t know that it’s the kind of enrichment that our employer encourages us to do during our build downtimes— but I may soon find myself experimenting with these things at the office if it seems like I can find a good time to do it.
Here’s one I did about pair programming:
Code
Oddly enough, we don’t spend much time working on code-related tasks while we wait for our builds to pass. It’s possible that we could learn a new tool or pick up the basics of some mechanism or another in our current stack, but I think we all realize that the soft skills of our team and inter-team communication have plenty of value, instead of just 20 minutes spent working on hard skills that we’re already super confident with.
Those code projects that we do work on during downtime tend to be very short-lived and focus on small pain points we have as a team. One of the more recent code snippets we wrote captured the amount of time we use as a team each day and then saved it as an entry in a csv.
We’re also working on a way to extract data from our task management tool and use it for reviewing metrics. We’re accessing it via a pretty mundane REST API right now, but it will be interesting to see if we can’t collate some of the data and make meaningful adjustments to team workflow based around what we learn.
It’s Not a Waste of Time
One of the most important things that my employer and my team remind me of during these builds is this: the downtime is absolutely, positively, not wasting our time.
We’re enriching ourselves, and allowing ourselves to become better programmers and better team members. The things we do when we’re not actively coding on a card on our board directly impact our mental health while we are working on the cards on the board.
Hopefully you’re lucky enough to get downtime while you’re on a team doing a build. And, hopefully you’re able to use that time to find the important parts of yourself that aren’t in your code.
I’d love to hear your suggestions for how you use downtime, or whether or not you really get to use it yourself.
Sound off in the comments!