Posted on June 27, 2016 by Gabe Parmer
Half a day, or half an hour?
One way to look at a job is what granularity of time slots you break your day into. Graham posits that most people in tech operate either on the manager’s schedule or the maker’s schedule. Managers segregate their work-day into hour/half-hour blocks based on meeting with others, sending significant emails, and coordinating with other people. Any conversation at this level should never take more than an hour as they are often decision-based, not based on information-building/dissemination. On the other hand, “makers” must focus on the creation of value. Engineering requires building a mental context that is deep enough to completely understand the problem at hand, or brainstorming a new design. Both activities are wasteful if done in hour stretches due to the massive context required. It is advisable to devote at least four hour, contiguous stretches to it.
Why does an engineer needs their time split into four-hour blocks? Understanding this is pretty fundamental. Faced with a large body of code, you have to understand it, build a mental model if its inter-relations, determine what the goal and means to the goal are, make the changes/additions, and debug those changes. This requires a deep understanding of the issues faced, the goals, and the software environment in which the changes are made in. Abandon all hope, ye programmers that go in hour spurts.
Given the need for large contiguous blocks of time, what threatens our ability to effectively utilize them? A great summary briefly investigates the impact of disruptions on programmer productivity. The most interesting reference explores how programmers recover from interrupted programming tasks1. The big take-away is that after an interruption, a programmer takes 10-15 minutes to re-acquire their context, and start programming again. If a programmer gets an interruption four times an hour, they get nothing done. This is harrowing news, and implies that it is worth putting effort into understanding how to minimize these distractions.
To make the higher-order bits perfectly clear:
Research is an activity that is a little more nuanced than “manager”-style, or “maker”-style schedules. On the one hand, we do significant system building. Writing papers also requires building significant context to craft a well thought-out product. This fits exactly into the “programmer” prototype. On the other hand, research is inherently a social activity. Meetings are required to
These activities motivate another granularity, the two hour chunk.
While taking classes, a researcher has yet another constraint on their time. Classes absorb a two to three hour chunk of time that requires deep attention. Additionally, if a researcher has Teaching Assistant (TA) duties, teaching classes consumes a comparable amount of time. Unique to being a TA, the researcher must learn to manage answering student emails in a timely manner without tanking productivity.
How is a researcher able to be productive in their own research when faced with this level of adversity? One of the first skills that every PhD student should focus on is being quite diligent in their own time management. A lack of productivity very quickly turns into a lack of research output.
It is quite important to actively make your own schedule work for you. The responsibility is on the researcher to get the most out of every productive hour of their day. In the end, doing research is only justified by the product. The means to the end is integral, and doing a PhD is about understanding the means to learn how to do research. But finally, papers must get published, systems must get built, and thesis must get written. The output is necessary, but not sufficient for doing a PhD.
I think that it is good to have a number of goals when creating your schedule. First, shoot for three days with two four chunks. This may be unrealistic during the first years when you’re taking classes, but is still a good goal. On these days, aggressively avoid distractions, and focus on being as productive as possible. If you must schedule something on these days, try to place that meeting at the beginning, or the end of the day. Generally, attempt to bin distractions together either in the morning or evening. The foremost goal is to create the largest chunk of contiguous research time as possible. If you end up with small fragments of time due to time slots you have no control over (classes, TA duties, etc…), then plan the work for those slots to be an activity that best makes use of a slot of that size. This should all seem somewhat obvious, but it is important to make a conscious optimization pass over your schedule.
Headphones. Use headphones in the lab. If one of your co-researchers has their headphones on, assume that they are trying to be productive, and that interrupting them will destroy their context. Thus, don’t do it. If you’re interested in coffee or lunch, use Slack or email to organize the outing. These types of activities are very important to build the group dynamics, but they should be integrated with a productive pattern for each researcher.
Reading papers as your “flex” slots. Reading a paper generally doesn’t require large slots of time. It is not difficult to put a paper down after reading it for 45 minutes, and come back to it in two days. Take notes in the margins where necessary to enable you to reboot into the paper’s context if necessary. Reading papers also fills in commute time, and time in-between other meetings quite well. If you need to understand the ins-and-outs of a paper, then this strategy might not be appropriate as it might require deeper attention, but realistically, most papers we read don’t require that deep of concentration.
Managing synchronous interactions. Synchronous interruptions are the productivity enemy of large-blocks of research time. Taking your brain away from the research in front of you to have a conversation with someone else, or to answer emails quickly is what tanks your ability to use a four hour stretch. It is important, therefore to insulate yourself from interruptions. There are two main strategies (that I know of) for this:
Clustering synchronous interactions. Meetings are necessary for a researcher’s long-term development. However, that doesn’t mean that 3 meetings throughout the week can’t be clustered together so that programming productivity for a single day suffers to preserve productivity for the rest of the days.
Even interactions with your advisor should abide by these rules. It is easy to think that you should want to meet with your advisor as quickly as possible, whenever they want to meet. Always remember that your advisor wants your research to be successful. In the long term, your research is the most successful when you are able to focus on creating systems. So if interruptions from your advisor are prohibiting your productivity, it is your responsibility to figure out a system that works.
It is worth having a discussion at the beginning of each semester to figure out what the lab-wide “meeting days” should be. These are the only days that meetings can be scheduled on (with exceptions permitted).
Synchronous \(\to\) asynchronous coordination. Technology helps here. Sometimes you are “blocked” on a problem and can’t make progress without solving it. If the only way to become unblocked is to talk to a fellow researcher, then you have few options other than to talk to them ASAP. However, many times interactions in a group of researchers are not quite as dire, and can be delayed. Technology to the rescue!
Using Slack. Slack enables questions to be asked and answered asynchronously, and enables them to be both answered and viewed by all of the interested researchers. It is an intermediate communication medium between physical meetings, and email. That is to say, that it is asynchronous, but enables some semblance of reactive conversations.
It is important to view the things you post on slack as not necessarily being viewed and replied to immediately. This means that you must provide enough context in your posts for someone who is not engrossed in your problem to relate, and provide productive replies. Please keep in mind that this is more context than you think it is at any point in time. If your posts are ambiguous, or are lacking enough specificity to enable a reasonable reply, then you’re wasting your own time in writing the post, and the time of everyone else in the channel that might read it and try and reply.
Slack messages that were not instigated by one of your own questions should be viewed as interruptions, thus should be avoided while programming. Don’t feel that you need to check slack whenever there is a new message. Check it when you aren’t in a sprint of productivity. Slack integrations for RSS, github, and Trello are useful notifications, but should not be indulged until you’re able to take the interrupt without losing significant context.
A note on public vs private messages in slack: Your default should always be to use public messages. Debugging bugs, learning about the infrastructure, and discussing design – these are all actions that should be public so that other researchers can chime in, and can learn from the discussion. If you have something that is personal and should not be public, then private messages are appropriate. You’ll find that little is actually private.
Using Trello. Trello adds value in three areas.
To best use Trello, it requires that you 1. include a significant number of tentative cards that represent the next month(ish) of work so that you can see the out-lay of work, 2. update cards (creating them, and updating those that exist) to reflect the work that is required, and that is being done., and 3. work to make sure that enough context is provided in each card so that anyone who is following the project will understand it.
It is important to understand the time allocations of the people who you have to collaborate with, and your professor is an important variable in this equation. Why does a professor interrupt you when they do, and when can you delay the distraction to protect one of your productive blocks of time? Systems professors that attempt to maintain their own ability to produce code have a mix of “management”-style task, and “programmer”-style tasks. They have some combination of:
When you receive an email from your advisor, realize that it is likely not temporally sensitive enough to require your to interrupt a programming session. If they stop by, or send you personal message on slack, then you’re unfortunately going to have to suffer an interrupt.
Given the variety of different activities your advisor is involved in, it should always be your assumption that they don’t remember the details of any specific programming situation that you’re in. This is not a valuation of the advisor on your work, rather a realistic fact given the set of commitments they have. Always provide context on trello, in slack, or in email for the issues you’re having. If you don’t it will waste not only your advisor’s time, but also your own time as the replies you will receive will likely not be about what you expect them to be about.
Resumption strategies for interrupted programming tasks, by Parnin et al. in the Software Quality Journal.↩︎