Getting things done as a remote engineer is a non-trivial task. It's hard as it is in an office with lots of process and structure. Our work particularly requires a ton of focus and often involves unpredictable obstacles and challenges. But it's actually my view that when you're working remote, you have extra control over your productivity.

That’s because working from home makes it more possible to completely commit to time blocking, a system that can help you organize your day so as not to waste a single moment. And my method for doing it is especially great for seamlessly handling coding tasks right alongside the kind of administrative work or team communications surprises that try to pop in to disrupt your flow.

Related: How to work asynchronously on an engineering team and not waste time

Understand the role of habit

Human beings have limited bandwidth to make conscious decisions. It's as though we have a stamina meter in our brains with each decision and micro-decision deducting from our daily allowance. If we rely too much on decision-making, we will burn out and kill our productivity — which is why we need structures in place to reduce our mental burden as much as possible.

In an office, a large number of time management decisions are made for you, either explicitly as rules or via culture. For example, there are rules and guidelines about when you should arrive at work, take lunch, and leave for the day. There are social cues from others about when you should be doing heads-down work, collaboratively problem-solving, or taking breaks. These are all decisions you don't have to make, leaving lots of bandwidth to focus on decisions specific to your role and personal value-add.

In a remote setting, 50% to 90% of that is taken away from you. You have much more (if not complete) autonomy over your schedule, and you can't rely nearly as much on the culture that's socially reaffirmed by your team. A lot of engineers think they can solve this with conscious decision-making, and that's when things get overwhelming.

What you really need are habits and structures that do the decision-making for you. As Charles Duhigg, author of The Power of Habit, explains:

Simply put, a habit is a behavior that starts as a choice, and then becomes a nearly unconscious pattern. For example, when you were learning to drive, and you wanted to back your car out of the driveway, it took a lot of concentration: you had to check the rearview and side mirrors for obstacles, remove your foot from the brake, mentally estimate the distance between the garage and the street while keeping the wheels aligned and monitoring for oncoming traffic, calculate how reflected images in the mirrors translate into actual distances between the bumper, and so on.

At first, developing a productive remote workflow is going to take a lot of conscious thinking. But if you're thoughtful about structure and habit-building, all that effort is eventually going to settle into an unconscious pattern that you can take advantage of every day.

Implement habits with time blocks

Time blocking is an excellent way to add structure to your workday as an engineer. The nature of our work requires intense focus, but also needs to accommodate a fair amount of collaboration (and putting out fires when necessary). Here's how to do it in a manner that's especially optimized to balance our particular set of needs.

The basic structure is simple

Time blocking comes in about a million different forms. You may have heard of a popular one called the Pomodoro technique that dictates a mix of 25-minute blocks of work separated by small 5-minutes breaks and a larger 30-minute break every couple of hours. This works great for some workflows, but I personally find the break-up of this system to be both too frequent and infrequent. I recommend structuring your day into 1.5 hour time blocks with 30-minute gaps in between. This means four to five work blocks a day (or if you get carried away like me, five to six work blocks a day). Each block should happen at the same time each day so the pattern can sink in without the need for mental exceptions.

1.5 hours is great for engineering

Even though some productivity experts prefer blocks of 52 minutes, I find 1.5 hours is the right amount of time to really sink your teeth into an engineering task and make meaningful progress. This allows, for example, time to read through tickets and documentation while still allowing for focus on direct problem-solving. It also fits nicely onto a standard calendar, eliminating the overhead of having to work with blocks that start and stop at awkward clock times.

Blocks are for focus, not reacting

Blocks are for focused work; they're not for reacting to things that pop up during the day. That means no responding to Slack messages or emails, and no reacting to anything that isn't urgently time-sensitive. If you explicitly designated a block for admin tasks like email, that's obviously a different story. But if you're in the midst of an engineering block, you should give yourself permission to focus fully on the engineering task at hand without apology. Consider yourself to be in a meeting with yourself, and act accordingly.

But I can't just ignore my boss and coworkers, right? Actually you can, for a little while. Making them wait until the end of a block is a perfectly professional thing to do for non-urgent communications. This is why we have gaps. They free you to focus on work during blocks because the next gap is never more than 1.5 hours away!

Gaps are for flexibility

The full thirty-minute gap between every single block is your secret flexibility weapon. This is when you take your breaks, yes. But it's also the time when you get to handle all manner of unstructured and unplanned necessities that pop-up throughout the day without getting thrown off-course.

For example, a task for a block may occasionally take a little longer than 1.5 hours to complete. Letting it bleed into the thirty minute gap is a great way of coming to a natural pause without disrupting your next planned block.

Likewise, I am sometimes so deep in thought coding that a gap is more disruptive than helpful, so I work through the end of the next block so long as there's nothing urgent that needs to be addressed. That said, I do this sparingly. It's important to reinforce the expectation of gaps throughout the work day so you can develop habits that avoid random and disorderly interruptions — which are likely to occur if you don't respect the boundaries of the structure.

The point is, gaps are wiggle room between officially planned blocks that allow you to manage unpredictability flexibly while strongly respecting the parts of the day you have actually planned.

Related: My guide for rubber duck debugging: A better process (with no rubber ducks)

Breaks are necessary and primary

Breaks are critical success factors for productivity. There are now boatloads of articles and studies that support the idea that strategic breaks are critical and necessary. They should be taken frequently throughout the day and rarely skipped.

In our case, breaks of 15 to 20 minutes should be taken during most 30-minute gaps between blocks. The thirty minutes is set aside for adequate wiggle room, but a significant portion of that time should be respected for breaks.

It's acceptable to skip breaks on occasion when it feels right, but you should never skip more than one break consecutively and ideally not more than once per day. Even when a break feels like an interruption, taking a step back is usually what you need to see the bug in your code or the elegant solution for designing your architecture. Keeping blinders on indefinitely actually slows your problem-solving progress.

Messages are a special case

Given that we do need breaks (and they should be taken at some point during most of our 30-minute gaps), we need to be really careful about how we handle messages and requests from others. That is, it's easy for these things to balloon to overwhelm every single gap so that we never stop the whole day through. But fortunately, we just need to be a little strategic!

If you have messages waiting when a block ends, plan to take roughly 10 minutes to address them. If you come across an item that requires further action, you have a few options:

1. If the task can be done within the 10 minutes, you might as well get it out of the way now so it's no longer on your mind.
2. If the task cannot be done before then, defer it to the next appropriate block. That is, if your next two blocks are designated for engineering work, but the following block is designated as flexible or admin, wait until your flexible/admin block if possible so as not to disrupt your engineering groove. Quickly respond to the message to set expectations, then proceed with your plan.
3. However, if the item must be addressed asap, plan to address it at the start of your next block. Then stop focusing on work, and take a proper break before that block begins. A friend once told me if you don't choose when you take breaks, your body will choose for you! And those breaks are usually much longer and sneakier than a planned break (e.g. a two-hour rabbit hole on Facebook).

Skipping blocks can also be ok

Now, there will be days when you just don't have your energy in order. You might start a block where you find yourself simply unable to focus or get into a groove. Maybe you're worried about something unrelated to work. Maybe you just woke up on the wrong side of the bed.

Sometimes the best thing to do is to skip a block entirely, go do whatever you need to re-charge, then return to the next block refreshed and ready. That may involve handling some personal task, having some social time, or watching an episode of Bob's Burgers. It doesn't matter. Do what feels right in the moment, and see where your mind takes you.

This is perhaps one of the best features of time blocking. If your day is unstructured, fluctuations in energy and motivation have a way of really nocking your day off course. But with time blocks, you can usually constrain the repercussions of resistance like this to a single block and find yourself right back on schedule. This is because 1.5 hours is long enough to feel really substantial, but it's also not like unconsciously taking half-a-day.

Designate blocks by purpose

Over the course of the week, it's valuable to designate blocks for a handful of different purposes and stick to it. But you need to do so in a way that isn't too complex but has planned bursts of flexibility.

I prefer to use three block categories to keep things simple: engineering, admin, and flexible. During engineering blocks, I do only engineering work. During admin blocks, I focus on communications, task management and planning, and meetings. During flexible blocks, I focus on whatever the day demands. This could be more admin, more engineering, or even handling personal demands that might arise.

My week is planned by first setting aside standing meetings. These include sprint planning events like standup and backlog refinement, and scheduled check-ins with team members. Since these often don't take up an entire block, they are scheduled during admin blocks or flexible blocks, the rest of which are used for light tasks.

I then make sure I have two or three consecutive engineering blocks per day, and at least one flexible block per day. These blocks occur at the same time every day where possible, reinforcing a daily pattern that eventually becomes second nature.

Next steps

The time blocking method I propose is just one way to add flexibility and predictability to your day while establishing a strong productive workflow. It's great for software engineering in particular, and works great for my personal needs as an engineer. That said, you should feel free to iterate on this structure until you find something that meets your particular needs in a nuanced way. Start with the basics, experiment by designating blocks at different times of the day, and see what feels realistic for you. Just remember, getting accustomed to any system requires practice, and too much complexity and rigidity will make whatever you choose hard to follow and unlikely to take root. Read the abundant literature about timeboxing, then settle on something simple and stick to it with light tweaks as you go.