After publishing my previous Working at Theorem: a typical workday article a co-worker asked me the following:

Can you go into the details of what happens during those “work” blocks? Do you frequently check slack_email or only check them occasionally? Are you heads down for parts of the day? Do you have dedicated “help_review others” time or does it happen ad-hoc?

This is an interesting question, so here are the answers.

Checking email / Slack

I approach these two differently. Email is something I check only when I don’t have any other task or when I’m in a break. I don’t have alerts or notifications when a new email arrives, so it’s a task that only happens in an active way. I consider email as the best asynchronous communication tool available, thus I treat it that way. I’ve several different filters that labels or archives emails as they arrive so when I check them I don’t have to lose precious time triaging everything that I’ve received.

Of course working 100% asynchronously is an utopia when working in a team that interacts with an external customer, so synchronous communication is a must; at work we use Slack for this. I’ve enabled notifications although I’ve also muted several channels that only generate noise or are mostly for announcements. I could leave those muted channels, however they are still important and I check them a few times throughout the day, usually after catching up with email.

I try to be conscious of how much affects others when mentioning them on Slack, so I try to keep usage of @here at a minimum, @channel only when it is urgent or very important; using @everyone is completely off the table, unless a catastrophe happens. And when it comes to direct messages I always try to send initially only one message: a greeting plus whatever question or comment I’d like to communicate; this way the other person can quickly decide to dedicate some time to me or not.

Code reviews

A big part of my day consists of reviewing pull requests created by other members of the team. I’m not going to go into the details of how you should behave when doing PR reviews, there are already hundred of posts dedicated to that: this is how I approach this task, YMMV.

First I start by reading the title and description. If those are good and informative then I’d approach the review in a better mood: good programming is mostly about communication, so I held prose to the same standards as code.

Second I look at each commit individually. Writing clear and well scoped commits makes reviewing easier, as you can better understand the author’s intentions. PRs with just one or two gigantic commits are a bummer and from time to time I try and teach people to write smaller commits next time.

Last but not least I look at the code in detail. The first things I look for is overall structure: is the code properly indented or doesn’t violate the rules and standards set for the project? Then I look at the semantics, trying to understand each decision, expecting to see well named variables and methods, easy to follow flow control statements, etc. I can be very nit picky at times, so I have to keep me at bay of not becoming an asshole. And yet there are times when you need to become one; luckily is not something that I need to do often.

PR reviewing is an opportunity for both the author and the reviewer’s growth as programmers and communicators. Treat it like as a learning experience and not as a chore.

Time management

With the current pandemic my working conditions changed quite a bit, even when I was already working remotely. The biggest change was on time management. When I worked from my office, I had some dedicated time for things like checking emails and Slack, for deeply diving into any tasks I was working on, and for reviewing code. Now those dedicated time chunks are gone, so I try to manage my time as follows:

• Checking emails and Slack is something I do first thing in the morning, before and after lunch, and during any coffee- or cigarette-break;
• Working on assigned tasks in 20 minutes chunks. Nowadays is hard to find long stretch hours of work, 20 minutes is a good compromise between I want to do something and gonna check the kids, have a break.
• PR reviews: I usually do them after the above mentioned 20 minutes. In the past I also scheduled this way, but after 40 minutes/1 hour instead.
• Lunchtime is something I’ve cleared out in my calendar, daily from noon to 1pm, so we have some routine for the kids. This I try to keep on schedule, so it doesn’t conflicts with my calendar. Of course it doesn’t always happens but so far it hasn’t been a problem.

Endnotes

As you can see I haven’t shared any truth revealing insights, though I hope it helps others getting more organized. This schema works for me; it might work for you or don’t work at all.

Interesting in working with me? Check our careers page and apply to any of our current openings. We are waiting for you ;)