Pomodoro extensions for software engineers Software engineers often struggle to manage their time effectively. In the late 14th century, the townspeople of Salisbury, England were summoned to their cathedral by a machine. It was a wonderful and strange device. It consisted of a collection of iron gears and wheels and bars, all arranged in a cube. It tugged endlessly on ropes hanging above. Its stone weights swung about imperceptibly in the cool air. And once per day, as if haunted by a punctual ghost, it struck a bell. It was a clock, and it had no face. It had no need for one. The people of Salisbury lived in a world without appointments. Or rather, their only appointments were with God. The tolling of the Salisbury clock connected people with their obligations to the divine, but it was just one step in the ever-shifting dance between humans, their , and Time. tools In the late 20th century, Francesco Cirillo invented the . “Our unique time method gives you immediate and lasting results. Master it, and you’ll be able to accomplish anything.” Knowledge workers all around the world started putting red tomato timers on their desks. Pomodoro Technique management It seems like everybody has tried the Pomodoro technique, but no one keeps using it. You set a timer for 25 minutes. Then the timer rings, and you drink a La Croix. Then, you set it for 25 minutes again. The timer rings, and you drink another La Croix. Then, you check your email, and 2 hours vanish instantaneously. “Oh, I do Pomodoro sometimes,” you then say. “I set a timer. It was kind of whatever.” 1. Get your head in the right place Time comes to us naturally as an undifferentiated river. Our attention darts from one moment to the next, always reacting. In this mode, we are focusing on the task at hand, but rarely on why we’re doing it. This is how people end up spending all day working on things that don’t really matter. Your most important tasks aren’t necessarily the ones that are standing up and waving their arms at you. They’re the ones that are sitting cross-legged in the corner, brooding. We can shift our perception of time by using consistent cadences and rituals. We already are familiar with the socially-constructed rituals of the weekend, and of three meals per day. These cadences chop up time into discrete chunks, making time easier for us to understand. Deliberately introducing 30-minute work intervals to your day can give you a lot more mental control of how you work. But you need to commit and invest into a system to support your new cadence, or else you’ll never adopt it. Set your time chunk goal at the start of each day Using a timer at work can be the first step in improving your productivity. But setting a timer alone isn’t enough. You have to do deliberate and difficult work to ensure to really change the way that you perceive time. At the start of your day, write down how many poms (i.e. time chunks) you will complete. Take into consideration how many meetings you have that day, as well as switching costs. Here’s one example calculation: * 1 pom = 30 minutes = (25 minutes of work + 5 minutes rest).* Estimate roughly 5 minutes of switching costs per pom = 35 minutes.* 8 hours = 480 minutes = roughly 13 poms.* Subtract 1 pom for lunch.* Subtract 5 poms for 2.5 hours of meetings today.* Subtract 1 pom for helping others. I will try to complete 6 poms today. Setting a goal for the day helps ensure that you actually come back to reset the timer after taking a break or getting distracted. View this as a challenge for pushing yourself to grow. It’s OK to use complex tools It’s true that a simple sheet of paper is all that you need for writing down your to-do list. But simplicity isn’t the only goal when choosing your tools for time management. I find that choosing a tool that I enjoy makes it more likely that I’ll actually use it. Traditional Pomodoro technique tells you to write down a log of how many poms you complete each day. But for software engineers, I suggest a different approach. You can blend pomodoro tracking with task subdivision and note-taking. Engineering notes work well inside of text editors. You can paste filenames, identifiers, commands, and code into an editor. You could use one system for notes and another for tracking poms. But I recommend putting your notes in the same file as your poms. This makes your poms as searchable as your notes. It also eliminates the need to switch between your pom log and your notes. 2. Write effective micro goals Ever feel like you’re working on something that isn’t going anywhere? Software engineers definitely know what it feels like to get stuck. As you work on a stuck problem, time starts to fall into the task endlessly like a sinkhole. You begin to lose the sense of accomplishment from finishing tasks. The task is expanding to double, triple, and quadruple its original size. It’s like you came home with a puppy, but it grew up into a Rhinoceros. To continue to make progress, you need to repeatedly define, and redefine, the work that you’re doing. Set achievable goals for each pom You’ve written down your goal for the number of poms to complete today. Now, write down a set of tasks that you honestly think that you can get during the first pom. completely finished Goal for today: 6 pomsPom 1: - [ ] Reproduce the CSS transition bug locally. - [ ] Implement a fix locally. I call these tasks for each pom . Take a moment to look at the goal and visualize yourself finishing it in the next 25 minutes. Only proceed if you believe it’s possible. If it still feels impossible, make it smaller. micro goals Now, set a timer for 25 minutes and do that you said you were going to do. everything If you do not finish the goals during the 25 minutes, take a 5-minute break anyway. But when you come back, don’t resume work on the same micro goal. When you spend more than one pom working on the same thing, you will start to experience time as a continuous stream. It will slip through your fingers. That said, I also don’t recommend switching to a completely different micro goal. Instead, before resuming. Focus on that sub-goal rather than the larger goal for the next pom. write a smaller sub-goal Decomposing micro goals Let’s say that you don’t finish the goal to “Implement a fix” in Pom 1. Since Pom 1 has completed, that goal will remain unchecked . Don’t go back and check off goals that weren’t completed within their pom. forever Instead, write down your next pom and its micro goals: Pom 1: - [x] Reproduce the CSS transition bug locally. - [ ] Implement a fix> Hmm, I'm going to need to keep the element in the DOM longer to make the transition work the right way.Pom 2: - [ ] Add a parameter to the parent component for displaying the child - [ ] Use a timeout to set that parameter to false after 1000ms The next pom is ultimately a continuation of the same work. But you have reframed the work to make it feel more achievable. This highlights an important distinction. While these micro goals seem like a to-do list, they serve a completely different purpose. Rather than a backlog of things to remember to do , micro-goals are expressions of what you’re doing . You should think of this document as append-only. Your long-term backlog probably belongs in a work tracking system like . later now Asana Whatever you do, always make sure that your micro goals always have some concrete associated with them. There should be some evidence that you completed each micro goal. deliverable - [ ] Investigate why this bug is happening // This is vague.- [ ] Find the problem file and add its name below. // Better! Assigning deliverables to each micro goal gives you a much clearer sense of progress. It makes work more fulfilling. 3. Manage real-world interruptions I’m sure you’ve heard the science. Interruptions are . The most productive environment for a software engineer is complete silence and isolation, right? poison Working in isolation is great when these conditions are met: You know the full specification of what you need to build You have full context on the system that you’re modifying No one else on your team needs help from you In real-world scenarios, it’s rare that even one of these things holds true, much less all three. The truth is that, for the most part, professional software engineering is a team sport. Collaboration is a crucial part of the job, and it is valuable work. Too many engineers view the ability to work in isolation as the pinnacle of productivity. They begrudgingly attend even important meetings. They discourage others from engaging with them to ask questions. They become knowledge silos without the power to share what they know. The obvious truth is that it’s impossible to eliminate all interruptions. Don’t build your workflow around the assumption that you will have complete isolation while you code. Instead, built interruptions into your process in a balanced and sustainable way. Master interruptions One common mistake when using Pomodoro is working through the end of the timer. Why is this a problem? If you’re being productive, why not keep working? Here’s what happens, though: You keep on working until you get stuck You take a 5-minute break You procrastinate. Who wants to start on a project that’s stuck? It’s far more fun to resume work that’s going well. That’s why I recommend stopping immediately when the timer goes off. But what about your train of thought? By stepping away from your work, don’t you lose all of that mental context? Relying solely on mental context is like storing your database in RAM. It’s simple, easy, and reckless. You need to externalize your context by taking good notes. If you keep these notes while you work, then stepping away from the computer every 25 minutes becomes much easier. And this has the fantastic side-effect of making all other interruptions easier to work with. I’m not advocating that you embrace interruptions. But some interruptions important. Externalizing your mental context helps prepare you for them. all are Work collaboration into your system I recommend that you close Slack while you’re working. However, you then need to consistently reopen it at the end of your Pomodoro to check for messages. Regardless of what you do, have clear conversations with the people that you work with on your communication preferences. Even better, put it on your Slack status, too. What if there’s a real emergency? You should make it clear that it’s acceptable for someone to approach you in-person, or to call you. Make yourself feel comfortable turning off notifications for 25 minutes at a time. What about email? Here’s what I recommend: Set a micro goal for inbox zero Quickly decide whether each email should be archived or filed as “needs response” Either way, your inbox should be completely empty by the end. For the emails that need responses, work them into your poms as micro goals. Time is on your side We don’t perceive time rationally. We perceive it emotionally. So don’t expect your natural impulses to guide you through your work. Instead of treating time as an endless flow, split it up into discrete chunks with specific goals. You will find it more intuitive to think about time in a rational and productive manner. Take the next week to focus on how you use your time at work. With some hard work and reflection, your perception of time at work will change. You’ll be more productive and get more enjoyment out of what you do. If you care about helping people do more of their best work, then you should work with me at Asana .
