Time

The first key is to make time to write. Ideally this should be a decent period of time each day during which you are undisturbed and at peak mental capacity.

The minimum period of time that I find effective is usually around 15 - 30 minutes. This is because it sometimes takes time to get into a good flow of writing. The maximum period of time that I find effective ranged from 45 minutes to 1.5 hours. This maximum is based on how well I can maintain my flow of writing and my motivation / discipline. If I get stuck, especially on a new section for which I do not have a clear outline, I tend to stop and let it percolate in the back of my mind. The longer the writing session goes, the more likely I am to run out of steam (motivation / discipline) - e.g. by getting distracted by email or my RSS reader. I find that practically this means that I am generally unable to continue writing for more than 1.5 hours.

So how do I find the time to write? I get up early each morning, before the rest of my family, and use the time to write. I sometimes write in the evening, but I find I often do not have the mental energy for this after a long day at work. So I tend to save the evenings for other activities, such as exercising, and dedicate the mornings to writing. Successfully doing this day after day takes motivation and discipline.

Motivation

The second aspect of my system is maintaining a high level of motivation. I have found that if I am not motivated to write regarding a particular topic or section then my progress is usually quite slow and I am easily distracted.

One way I keep my motivation high is extremely simple: I primarily choose topics that I am motivated to write about. When a new idea comes along, motivation to write about it is usually quite high initially and decays over time. So the ideal is to start writing about such ideas immediately. Other times I am wrestling with a topic at work or researching it on my own and gain some insights that I feel like sharing.

My motivation in these cases is linked to the goal of helping others learn and grow, which is part of my professional vision. In some cases, as I have started writing about an idea, I realized that I only had a sentence or two of meaningful content, which by my standards is not enough to share via an article. This typically rapidly deflates my motivation, and I move on to a different idea.

This concept of linking the act of writing to the achievement of a larger, more personally-meaningful goal is another valuable technique for boosting motivation. In the last year I have started to tackle some larger projects (which is one reason for the decrease in my posting frequency), and I find that having this linkage is extremely powerful in maintaining motivation over the long term. Having this motivation helps in dedicating the time to write.

Motivation is powerful, but it tends to fluctuate. When motivation fades, discipline is needed to maintain consistency of purpose.

Discipline

The final key to my system of writing is discipline - consistently applying deliberately-designed techniques and practices that help me write. Discipline has also helped me discover these methods through ongoing reflection and improvement on what is working versus what is not

A large part of discipline is consistency, which helps build up productive practices into positive habits. One example is my practice of getting up early each morning to write - I do this every morning, weekends as well as workdays.

I have found that there is an initial hurdle to overcome when sitting down to write, especially if I am struggling with a section. This difficulty often caused me to switch to email or the web as a distraction from which I tended not to emerge, resulting in me making no progress for that block of time. One practice I have developed to overcome this is to have a firm plan in mind the night before of what specifically I am going to write the next morning. As I get up in the morning, I immediately begin recalling my plan as a way to help prime my mind for action. Not only does this help me stay focused, but I also find it reduces the start-up time necessary to get into the flow, thus allowing me to be productive with even a short block of time.

Outlines are another practice I regularly use, even for short pieces of writing such as this article. These outlines are often quite informal, focusing on the main points I plan to write about. The purpose is not to identify all the content, or how it is organized - I often add more points that come to mind as I write, or restructure as the material comes together. Instead, I use outlines to help eliminate one of the causes of getting stuck - not knowing what content to write about. (It is still possible, unfortunately, to get stuck regarding how to write the content.) Outlines are also helpful in dividing the writing into sections: each section acts as a mini-milestone that I can aim to complete during a writing session, thus helping me remain motivated to write.

I have a technique for maintaining the flow while writing and minimizing distractions that involves the use of 'todo' labels. The general idea is that when I identify something to do or consider that falls outside my current focus, I document it with a 'todo' prefix. This keeps it preserved for later action, which helps to get it out of my mind now. Here are some common examples of how I employ this technique:

• When I want to link to an article on my website or elsewhere, I leave a 'todo'. Finding the link is often quite quick, but I do this to avoid distractions.
• When I have an idea for a piece of content for a future, unwritten section, I jot down a brief note with a 'todo' in that section, then return to what I was writing.
• When I get quite stuck on a particular paragraph or section, I leave a 'todo' comment and switch to another area. This is especially common when I have a long list of points outlined: I start writing the points for which I have the most motivation, leaving 'todo' flags on ones I skip. I then use the momentum I have built writing these more motivating points combined with the promise of almost being done them all to return to these few remaining points and grind them out.
• When I have an outline consisting of sections, like this article does, I start by writing down the section headings with 'todo' labels on each. This serves as a road-map for me to follow while writing. It also helps me see the overall structure of what I am writing.

This is my system for writing - it may not work for you. But I do suggest at least experimenting with some of these techniques and practices if you have not tried them before. I encourage you to leave a comment describing what practices or techniques you have found helpful.

Despite all these indicators, it took me a while playing Starcraft 2 to realize that the principles from lean thinking are completely applicable to the game. Lean thinking derives from the lean manufacturing system used by Toyota that helped it become a powerhouse among automobile manufacturers. Once I made the association, I realized that many of the strategies and techniques used by top players can be derived from lean principles.

This demonstrates the power of lean: it is applicable not just to manufacturing of physical products but also to product design, business processes, creation of knowledge-based products such as software, and even games. Starcraft 2 can therefore serve as an excellent educational tool for conveying lessons about lean. (But good luck expensing the game as training material :)

One of the main lean principles is eliminating waste, or non-value-add activities. There are different categories of waste generally corresponding to different aspects of an idealized process that can be linked to specific aspects of Starcraft 2.

• Excess Inventory: Minerals and vespene gas are the two resources in Starcraft 2 that are needed to build units, upgrades, and buildings (production centers or higher technology). Focusing on economic production - lots of workers - is important to ensure a high income of these resources, but letting the inventory of these grow, especially in the early and mid game, is considered wasteful - you should be using those resources to build units, buildings, or upgrades. A growing inventory is generally a sign that you have insufficient (or inactive) unit production.
• Under-utilization: Inactive unit production buildings are wasteful: why build the building if you are not going to pump units out of it? This is especially true for building workers from Command Centers and Nexuses - if you miss building a worker, there is no way to 'catch up' to your opponent without expanding (and your opponent can expand at the same time, so you may never catch up). This is less true for the Zerg as they can stockpile larva produced via Queens, but still remains true for the initial three larva from any hatchery. This explains why becoming supply blocked is considered bad - it forces your unit production to become inactive until you can build more supply. To help deal with idle production Starcraft 2 added build queues for Terran and Protoss so that multiple units can be queued to build. Using the queues avoids one waste, but leads to the next...
• Work in Progress: Lean focuses on providing value to the customer so anything that is a work in progress is not yet providing value. The larger the level of work in progress, the more resources committed with no value realized, which translates into waste. One pro tip is to never use build queues - only build a single unit at a time. This requires impressive multitasking abilities to always be ready to build another unit when the prior unit finishes to avoid under-utilization, even in the middle of battle. But it is a requirement at the pro level - the resources spent on the queued unit are not realized until later, whereas a less wasteful player can instead use those resources in a different way for a more immediate return on investment. The Terran ability to queue multiple buildings for a worker to build is convenient but is yet another example of this type of waste.
• Excess Stock: Finished products sitting in storage do not make money - they have to be delivered to paying customers to earn their value. Combat units sitting around at least provide a defensive value, but they could be providing a much greater benefit by attacking the opponent to weaken them. There are a wide number of possible tactics - harassment attacks against workers, attacks on expansions, feints to gain a psychological edge, or merely establishing map control to expand. The keys are to not sacrifice your macro game and to not suffer a major, unequal loss of units in battle.
• Delays: Any unnecessary delay between two events or process steps is a form of waste. One of the best examples of this is the use of proxies (proxy pylons, proxy barracks, or a proxy hatchery) to enable unit production near your opponent in order to eliminate the delay in marching units from your base to your opponents. Another example is moving a worker to your natural expansion prior to collecting the necessary minerals so that you can begin building the second you reach the necessary amount.

There's more that can be said about lean and Starcraft 2, but I'll stop for now and leave it as an exercise for the reader to discover additional associations. GLHF!

A common problem I encounter from the use of these generalized requirement statements is ambiguity. This has multiple negative impacts. The user representatives providing requirements and the business analysts documenting them can both review the same written requirement and agree that it is correct, based on their discussions, while actually holding differing interpretations. But it gets worse. The developers implementing the requirement who typically do not have the benefit of the interactions and discussions with user representatives can arrive at an even larger range of interpretations. And if you have a separate tester, who knows what they might come up with.

To illustrate the problem, here are some questions about the example business rule provided above demonstrating the amount of ambiguity in just one single sentence:

• By the phrase "last transaction" do you mean the last transaction chronologically? If so, which transaction date should be used to determine this – the date of posting or the date of acceptance?
• The phrase "more than a year ago" could be based on calendar year or could be based on the corporate fiscal year. Which is it?
• Assuming the phrase "more than a year ago" is calculated based on calendar year, how exactly should the calculation work? It could be based solely on the year – e.g. warn if the year of the transaction is two or more years less than the current year. It could be based on date – e.g. warn if the transaction date happens before the same month and day as today last year. Or it could be based on a number of days – e.g. warn if the transaction date is more than 365 days before the current date. (Note that the last two scenarios will produce different results in a leap year.)

The solution to the problem of ambiguity is to use examples. And not just a few examples here and there to support particularly complex requirements – requirements should be largely based on examples, with the generalized description simply providing the higher level intent or summary. Examples should ideally be created by user representatives, or at the very least carefully reviewed by them. The benefit of examples is not just to bring greater clarity to the development team but also to ensure the users are clear on what the system will do. This helps avoid unpleasant surprises when the users first see and play with the working system.

The Agile community has figured this out a long time ago, thus prompting the move to very short user stories supplemented with acceptance tests instead of formally elaborated use cases. The acceptance tests function as the specific concrete examples. The user story only provides a high level summary in part because of the expectation that further face-to-face conversation will take place regarding the requirement.

If your environment requires more formalized requirements documentation then keep using use cases and lists of business rules, but keep the written text focused on the higher-level intent while examples provide the specifics. To provide an example :) of this, here is the example business rule rewritten to fit this new approach:

As the account manager I want to receive a warning when the account has no recent activity.
Examples:

• Most recent transaction in account based on posting date of May 1, 2009 with current date May 1, 2010 produces the warning "No recent activity in account".
• Most recent transaction in account based on posting date of May 2, 2009 with current date May 1, 2010 does not produce a warning.

One frequently quoted study by bloggers is http://jonpeddie.com/publications/multiple-display-market/ which states that multiple monitors results in an average productivity improvement of 42%. Unfortunately, many then seem to conclude that developers will become this much more productive when switching to two monitors. This is not the case. As per the analysis by blogger Patrick Dubroy which is the best analysis I found of this research, this 42% is for only very specific tasks - comparing or editing information between two documents, or copying and pasting information - for which dual monitors provide a significant benefit. Patrick also quotes another research paper by Microsoft that reports a 9% improvement on more general computer tasks when going from a small display to a much larger display. Microsoft also found that user satisfaction was also significantly increased going to a larger display. Patrick very loosely estimated an overall increase in developer productivity of 3% based on the fact that developers don’t always do tasks needing two displays and are not always working on the computer.
Going with a 3% productivity increase for dual monitors leads to the following ROI calculation. The cost of a developer per year for an employer are typically at least $100,000, and I assume the employer derives higher value (return) from the developer's work than the cost. So a 3% productivity improvement results in a return of at least $100,000 times 3% = $3000. This is approximately 10 times the cost of purchasing a second monitor, which makes for a pretty hefty 1000% ROI in the first year alone, with the break-even point happening after roughly the first month.

The more important, and harder to quantify benefit, however, is the increase to developer satisfaction and motivation. The software engineering research consistently demonstrates that the largest factor influencing productivity in software development is the people doing the work. The best performing people can be over ten times (not 10% but a factor of ten!) more productive than the least productive and the best performing teams can be over three times as productive as the least productive teams. Since larger displays have been demonstrated to increase user satisfaction and decrease frustration, we can expect a direct increase in motivation. There is also an indirect increase in motivation due to developers feeling valued and important by management due to being supplied with good equipment.

While I have referred to software developers in the above business case, the same arguments apply for other I.T. professionals such as business analysts, testers, database administrators, and operational support staff. No matter your role, I believe you will benefit from having multiple monitors instead of one.

You must be careful, however, that the cost of these defect prevention practices does not become excessive. That would introduce a different type of waste – non-value adding process. The waterfall method of software development is an example of this. One of the principles behind waterfall is that careful requirements analysis and design will minimize downstream defects during coding and testing. Put another way, it is a good idea to understand what you need to build before you start building it. The problems with waterfall arise from going to extremes in applying this principle. Requirements analysis is done up front for the entire project as a big batch based on the theory that it minimizes rework due to future change, but in reality the constant pace of requirement changes plus the learning that occurs throughout the project will result in increasing amounts of change the longer the time spent doing requirements. In contrast, Scrum and Kanban apply this principle using a balanced approach – project level requirements are done at a high level, and the more detailed analysis is done on individual user stories just prior to implementing them. (See for example the article Scrum and CMMI – Going from Good to Great: are you ready-ready to be done-done?.)

In order to effectively adopt a defect prevention practice two pieces of information are needed:

1. Specific, actionable steps to apply the practice.
2. The expected benefit. What categories of defects does the practice intend to prevent? This helps determine when to apply the practice and helps to evaluate it after adoption to assess its effectiveness.

If we consider the idea of careful requirements analysis and design mentioned above as a prevention practice, the benefits are fairly clear - prevent requirement and design based errors - but specific actionable steps are missing so it does not qualify. (In fact, this is one of the contributing factors why waterfall projects can end up in the analysis paralysis anti-pattern.)

Now that the groundwork has been laid I can present some specific defect prevention practices. This is not a comprehensive list – many other practices are possible. The practices I have chosen to discuss are ones that I have used and am confident that they work.

Use Understood Methods Rule

The basic formulation of the rule is quite simple: when coding a method only invoke other methods whose behavior you clearly understand and are confident will work the way you want. I have written a separate article providing specific guidance on how to apply this rule.

This practice generally aims to prevent interface errors - which I define generally as defects between two separate pieces of code. Research suggests that a significant proportion of defects are due to these kinds of errors (See for example the paper An Empirical Study of Software Interface Faults.)

I find this rule particularly valuable when applied to the invocation of methods between classes and especially between components. In this case it helps prevent integration errors which are usually not caught by unit testing.

Design by Contract

The idea of design by contract is to precisely specify the behavior of methods to help ensure that they are invoked correctly by callers and that the callers receive the results they are expecting. This is done by precisely specifying the preconditions and postconditions of methods. The chief proponent of design by contract is Bertrand Meyer, whose book Object-Oriented Software Construction is a classic on the topic.

Method preconditions are conditions that must be true in order for the method to successfully execute and fulfill its postconditions. Preconditions are most commonly applied to method arguments. For example, a method to convert a string to a date might have the precondition that the string argument must not be null. Preconditions can also be applied to the state within the class or even external state. For example, a method to delete a particular object from the database might have the precondition that the object exists within the database.

Method postconditions are conditions that the method guarantees to be true after execution, assuming the preconditions are met. Postconditions are most commonly applied to the return value of methods, but like preconditions can also be applied to the state within the class or external state. Returning to the example of a method that converts a string to a date, such a method could have two postconditions. First, that the method will return a corresponding date object that is not null if the input is a string in a valid date format, and second that the method will throw a specified exception if the input does not correspond to a valid date format.

The combination of preconditions and postconditions forms in essence a contract between the method and its caller. The caller promises to fulfill the preconditions in exchange for the method guaranteeing that the postconditions will be met.

Despite the fact that the name of this practice contains the word "design", this approach does not require a separate up-front design of each method. The goal is to have a clear specification of behavior once the method is finished – how you arrive at it is not important to this practice. I tend to start with an initial idea for a method’s contract that I evolve as I write tests and implement the method’s logic using test-driven development.

There are several options for specifying pre- and post- conditions. Some teams rely solely on their automated unit tests to serve as the specification, but I prefer a more concise specification provided as part of the method definition. In Java I typically use JavaDoc to document pre- and post- conditions and programmatically check argument preconditions at the start of the method. I typically formally specify pre- and post- conditions only on methods that are intended for use by other classes or components. In Java, this is typically public and protected methods of interfaces and classes.

This practice is very closely related to the Use Understood Methods Rule, and they go hand-in-hand. Knowing a method’s pre- and post- conditions is necessary to fully understanding it. As I stated above, I tend to only apply formal design by contract to methods intended for use outside the class in question, which means this practice is really aimed at preventing integration defects.

Defensive Coding

Defensive coding is named after the practice of defensive driving and is based on the same mindset of expecting problems to occur and actively taking precautions to avoid them. Defensive coding is applied by adopting a language-specific set of idioms that minimize or prevent common coding errors when using the language. These idioms are often reflected in coding standards.

Here are some examples of defensive coding idioms for Java:

• When comparing if a variable is equal to a constant, put the constant first. This avoids a potential null-pointer exception (if the variable is null) by invoking the equals() method on the constant, which is never null.

  public boolean isAdmin(String userId) {
    String constant = "admin";
    return constant.equals(userId); // Instead of userId.equals(constant)
  }
  

• Always use braces to define a block of code for an if, else, while, for, or do statement, even if the block contains only a single line of code. This avoids the problem of later adding a second line of code indented to the same level as the first and mistakenly thinking it will invoked as part of the block.

  public void addOptions(String userId) {
    if (isAdmin(userId)) {
      addAdminOptions();
    } else {
      addRegularUserOptions();
    }
  }
  

• Use the Java 5 for-each construct rather than using a loop index variable to manually iterate through a list. This avoids the problem of having an off-by-one error in constructing the loop.

  public void processOptions(List options) {
    for (Option option : options) {
      option.process();
    }
  }
  

Defensive coding aims to minimize coding errors, both at the time of coding and in the future when the code is being modified by others. While these types of errors are typically easily detected by unit testing, I find that using these idioms (after the initial adoption) takes virtually no effort or thought on my part, making them literally a no-brainer to use.

Example-Based Requirements

The idea behind this practice is to express requirements as much as possible in terms of concrete examples rather than the generalized wording typically used in use cases and lists of business rules which is almost always ambiguous. I have written a separate article providing further details on example-based requirements which includes a specific example. :)

The practice of example-based requirements aims at minimizing requirement errors, particularly errors due to misunderstanding or misinterpreting. The examples should also be used as acceptance test cases, in which case they help detect design or coding errors (although unit tests should identify most of these first).

Conclusion

I encourage you to choose one or more of these practices to adopt in your current development work. There will be extra effort initially to understand and become comfortable with a given practice, but this will decline over time as you achieve mastery of it.

The very first thing to do to minimize email distractions is to disable in Outlook all the indicators (like the bell, pop-up that fades, and system tray icon) that announce that a new email has arrived. I have always found these annoying and disabled them years ago. (Why are they enabled by default?) Every productivity expert I have read who mentions email also makes the same recommendation, so if you are reading this now and have those indicators set stop and disable them.

Without these indicators I still found myself becoming distracted by email. A typical scenario would see me working in one of my dedicated blocks of time focused on a task when I needed to either send an email or refer to an old one. I would open Outlook, see all the new emails in my inbox, and get distracted with reading and/or responding to them, especially if they were marked high priority. (This is the classic mistake of doing the urgent instead of the important.) So I tried a number of approaches.

First I tried to figure out how to send an email without opening Outlook. I wanted a shortcut in my Windows quick launch bar to do this, but what would have been trivial in an Unix environment turned out to be surprisingly difficult. In fact, I couldn't figure out how to do it using a command-line script, and I wasn't about to spend the time required to write a .Net program to do this. (If you know how to do this or know of such a program please let me know.) The best workaround I found was to invoke the Windows Run command (normally found in the start menu, it can be invoked by the shortcut of the Windows key + R), and type in the command "mailto:". The extra keystrokes were enough to prevent me from adopting this as a regular practice, and this didn't help anyways when I needed to reference an existing email.

Next I tried to figure out how to have Outlook check for incoming emails less often. I found a number of settings that seemed relevant, but they had no effect. New emails were still detected in less than five minutes. I was not sure if I missed the correct setting in Outlook, or if it was taking its email-checking configuration from the Outlook server. (If you know, please pass along the information via a comment.) In either case, I was pretty unhappy with Outlook. I considered simply shutting it down, but I needed it running in order to provide reminders for all the meetings I had scheduled throughout the day – including reminders for my personal design times.

I finally found a workaround through a coworker – switch Outlook to offline mode, and it will no longer check for emails. When offline Outlook does not send emails either, which was mildly annoying but a limitation I could live with. It took me less than a week, however, before I discovered another major limitation: while in offline mode changes to my schedule would not be communicated back to the Outlook server (and become visible to others) after I went back online. I discovered this via a not-so-amusing exchange with a coworker who was trying to book a meeting with me for an afternoon he saw as free that I had booked something while offline. The workaround to this annoying problem was to discipline myself to treat my calendar as read-only while Outlook was offline. Despite all the issues, offline mode worked quite well for me.

Recently, I have become more disciplined about remaining focused during my solo blocks of time and have found myself using offline mode less often. This seems to work best for me when I am crystal clear on my priorities (usually due to an impending deadline), so when I do see an email that would normally distract me I immediately think "not a priority" and file it for actioning later. There is usually a small amount of mental effort / distraction involved in scanning the email and making this decision, so it would be better to not have the emails come in until I want.

What approaches do you use to avoid getting distracted by email? I would love to hear your ideas, so leave a comment below.

Use a "Do-Not-Disturb" Indicator

My first approach involved trying to prevent people from dropping by my cubicle and distracting me. I placed a sign marked "Do Not Disturb" on the back of my second chair. When I did not want to be disturbed, I moved the chair so that the sign on the back was visible to anyone approaching my cubicle. I informed my coworkers of what I was doing and they were generally (but not entirely) supportive. This approach helped, but had a number of limitations. Coworkers having a discussion in an adjacent cubicle were sometimes distracting, especially if they mentioned my name or if they were discussing a topic I found interesting. I had to learn to remember to put out the chair when I needed to concentrate – sometimes I forgot. I had to learn to stay focused and not let myself get distracted by other conversations – this takes discipline and I find is an ongoing battle. Coworkers sitting adjacent to me had to learn to be careful asking questions to me over the cubicle wall, as they could not see whether I was in do-not-disturb mode. The biggest limitation, however, was that it did nothing about all the meetings I was being scheduled in. Some days I was scheduled in meetings for most of the day, with only small gaps of an hour or less between meetings.

Block Personal Time Between Meetings

The multitude of meetings prompted my next approach, which was to block off time – a minimum of 1.5 hours - in my Outlook calendar between meetings for my own solo design tasks. Doing this also helped with my previous approach: when the time for one of these blocks started the Outlook reminder prompted me to deploy the do-not-disturb chair and focus on my design tasks. The downside of this approach to my team members is that I became much less accessible, either for impromptu drop-ins or for scheduled meetings.

Schedule "Please-Disturb" Times

To address this issue of reduced accessibility I adopted a practice that ironically is the opposite of the previous one: I scheduled "please-disturb" times (in Outlook) during the week for team members to ask questions and get feedback on their work, and communicated these times to the entire team. While I wanted to ensure I was still available to the team, I hoped that having a scheduled time to talk to me would reduce the number of unscheduled drop-ins. In practice this saw mixed results for obvious reasons: team members with questions or needing a review sometimes did not want to wait a day or more, potentially impacting their ability to get work done, in order to wait for a scheduled time. But the approach did work in guaranteeing a certain amount of availability to the team.

Block Personal Time First When Most Productive

After a while using the approach of blocking personal time between meetings I started to notice some patterns. I always seemed to be most productive first thing in the morning rather than after one or more meetings. After meetings my mind is less fresh and I am sometimes distracted by issues discussed in the meetings. Plus I personally have a higher energy level in the morning than the afternoon.

So the idea occurred to me to schedule blocks of personal time first thing in the morning when I am most productive and best able to focus. I also aimed to make these blocks longer – at least two hours and preferably three – than the blocks of time I was scheduling between meetings. I found scheduling these blocks in the current week hard due to meetings, so I started scheduling then in advance. First I scheduled them just for the next week out, but I found this insufficient so I switched to scheduling them a month in advance, and in some cases set up reoccurring events in order to permanently block certain mornings. I then sent an email out explaining what I was doing and that I would be unavailable for meetings most mornings before a certain time.

This approach did cause grief for people trying to schedule a meeting with me as it became much harder for them to find time for me. I have had to make compromises – typically by sacrificing part or all of a blocked morning to important meetings. But otherwise I am very pleased with the boost in productivity I have experienced as a result.

A logical extension of this approach is to expand this practice out to the entire team, so that everyone has the same meeting-free and interruption-free blocks of times throughout the day. I have heard of this being done but have never tried it, partly because other team members typically have far fewer meetings and drop-ins than me. If you have been part of a team that has tried this, please leave a comment describing your experience.

How Does it Work?

The basic concept is simple: clearly identify the next task you should work on, write it down as your next step, and then work on it. Given a typically large set of tasks – what I like to refer to as to-dos from a to-do list – a lot of time can be wasted jumping back and forth between tasks and figuring out what to do next. This is especially true when you are inflicted with frequent interruptions, distractions, or breaks.

How you choose the activity for your next step is critical. While the decision should take into account multiple factors such as importance, urgency, and time available, I believe the primary factors that you should use are motivation and progress-ability. Which task are you most motivated or interested to work on next? For which activity do you have the clearest idea of what to do next in order to make progress? By emphasizing these two factors you maximize your productivity on each task: you are as motivated and as clear as possible as to what needs to be done. This is especially true when the tasks are all related to a single project, such as coding functionality for an application. In this case it matters far less what order the work is done in than the amount of progress you make each day.

Putting it into Practice

A key ingredient to implement this technique is a simple and fast method for recording tasks for a piece of work - what I like to call a to-do list. This is necessary because when you are working on your next step and identify an unrelated idea or issue, you need to write it down on this to-do list to get it out of your mind and avoid having it distract you from the task at hand.

I use different approaches to implementing the next step technique depending on the work I am doing.

When writing code in my IDE (Integrated Development Environment), I record to-dos as special code comments that the IDE filters and displays as a list. Instead of recording my next step in a similar fashion, however, I record my next step on a piece of paper on my desk. I use this low-tech solution for a few reasons. The next step is often not as fine-grained as individual to-dos, and may include several to-dos and multiple source code files. Writing it separately allows me to express it at whatever level of detail is appropriate. Using a separate piece of paper provides an area for me to jot down brief design notes, if necessary, as I work on the task and need to resolve design issues. When the task is complete I cross it off on the paper and write down a new one, perhaps flowing logically from the current task or perhaps pulled from my to-do list in the IDE.

When writing large documents in Microsoft Word or Open Office, I use a different approach. Before I write content, I start with some sort of outline – usually a partial outline that I expand and refine as I write. I represent the sections of the outline using headings within the document. Correctly using styles for the headings allows me to use features like the document map or outline view in Word to view the outline. I represent to-do tasks using the text "TODO" with a yellow highlight. For sections that I have not yet started or are incomplete I suffix the heading of the section with this to-do text in parentheses. This allows me to view the outline and see what sections still need to be written. When I choose an outstanding section as my next step, I prefix that heading with the text "NEXT STEP" with a red highlight. When I finish the content for that section, I cut and paste this text to the next section I have chosen.

Why It Works

This technique incorporates a number of elements that make it effective in several ways:

Improving Focus: Explicitly choosing and writing down your next step and providing external storage for any extraneous ideas that come up (your to-do list) helps orient your mind towards the task at hand and keep it free of distractions, which improves your ability to focus on it. I find this especially useful for tasks which I must do but have lower motivation for: my mind tries to suggest distractions to derail me, but my strong focus makes it easier to push through and get the work done.

Recovery From Disruptions: Having your next activity clearly identified in writing makes it much easier to resume work after a break or interruption.

Maximizing Productivity: Choosing your next step based on motivation and progress-ability maximizes your productivity on each task you work on.

Your Next Step

I challenge you, the reader, to immediately put this technique into action. For your current project or to-do list deliberately decide on your next step and write it down. Let me know via the comments below how this technique works for you and how you adapt it for your own use.

1. Say No To Meeting Invites

The best strategy that I find the hardest to use is to turn down meeting invites. Being asked to attend a meeting is often an acknowledgment that your input is valued, especially the more senior the other attendees. Furthermore, meeting with senior technical or management people is often beneficial for your career, while repeatedly turning down such meetings is not. This produces a natural inclination to want to attend meetings. To combat this, I ask two questions to determine if the meeting is worth attending:

• Can I reasonably expect to make a useful contribution at the meeting? In other words, will others benefit from me attending the meeting?
• Can I benefit from attending the meeting?

If the answer to both of these questions is no then it becomes easier to decline the meeting invite. Unfortunately, few meetings meet this criteria.

2. Leave Meetings That Do Not Deliver Value

If you are in a meeting that is not providing any value for you being there, then one option is to get up and leave. Your ability to do this will depend on your role in the meeting and your corporate culture. I have heard that at ThoughtWorks it is considered acceptable and normal for anyone to leave a meeting at any point if they do not feel it is worth their time to be there. The organizations I have dealt with have not had such enlightened cultures, but I have used and have seen others use this strategy at times. This strategy works best when you are an optional attendee.

3. Tentatively Accept, Then Choose When To Go

Regularly scheduled status meetings are a significant percentage of the meetings I am asked to attend. This is especially an issue with being on multiple projects when each has one (or more) regular weekly or biweekly meetings. The biggest problem with regularly scheduled meetings is that they consistently use up your time, week after week, and I find that they deliver limited benefit for the time spent. One strategy I use is to only tentatively accept the invite for such meetings. This gives me the freedom to choose not to attend, whereas accepting the meeting creates the expectation that I will attend every one. This works especially well for formal meetings with published agendas and minutes. If the agenda has items that are worth my time to attend, I will, otherwise I'll just browse the minutes or talk briefly with someone else who attended.

4. Double Book Meetings

Double booking two meetings at the same time is another time-saving strategy. With two meetings scheduled for the same or overlapping times, you can choose which to go to, with an excuse for missing the other that almost every manager will accept. This works especially well when one of them is a regular status meeting that you can afford to skip. Another option is to attend a portion of both meetings. At the start of the first meeting if you point out your need to leave early, you can often get the agenda shuffled to talk about the issues requiring your attendance first. You can then leave for the second meeting having derived most of the value from the first meeting in a shorter period of time.

If your organization uses a shared calendering application that allows you to see the availability of others when scheduling meetings then using the prior strategy of tentatively accepting meetings makes it easier to get double bookings, as others will schedule meetings for when you are tentatively available. This in turn makes it easier to only tentatively accept their meeting, with the excuse that you may have another at the same time.

5. Penalize Projects For Meetings

A different strategy I use is to "penalize" projects for wasting my time in status meetings. I accomplish this by allocating a fixed number of hours per week to each project. If I only allocate four hours a week to a project, and the project manager wants me to attend a one hour status meeting each week, then that uses up 25% of my time for that project. I have at times emphasized this point. When asked in a status meeting how long it will take me to finish a task, I'll point out that I lost an hour due to the meeting, and thus have one less hour left in the following five business days to work on the task.

At this point you may be getting the impression that I think that status meetings are always a waste of time and do everything to avoid them. Not at all. Status meetings are useful for a variety of reasons, and I do attend a fair number of them. Since I am expected to produce work outside of meetings, however, I do need to ensure that I have significant blocks of non-meeting time available.

6. Schedule Meetings With Myself

It seems ironic that one solution to too many meetings is to schedule more, but it works. When I absolutely need to get a piece of work done, I'll schedule a meeting just for myself to work on the task. This strategy works best when your organization uses a shared calendering application such as Microsoft Outlook that allows you to see the availability of others when scheduling meetings. Other people trying to schedule a meeting with you will see that your schedule is busy and change the meeting time to accommodate you. If the topic is urgent, people may decide to meet anyways without you. In order to make progress on significant work tasks, I sometimes schedule full-day meetings one or more days in a row. The downside with doing this is that the next few days afterwards tend to completely fill up with meetings if I am not careful.

There are several variations of this strategy that I use as well. When others want me to review a design or document with them in a few days and ask when I will be available, I tell them to schedule a meeting with me. This ensures I'll have a block of time available that day to meet and go through what they want reviewed, rather than waiting till that day and risk having it fill up with other meetings. When I am waiting for others to do some tasks for me, and not seeing results for a significant period of time, then I will schedule a meeting with them which they will invariably accept. When they come to the "meeting", I review the tasks I am waiting for and then explain that the next hour (or however long the meeting is) is for them to work on these tasks. My logic is hard to turn down: if they had the time to set aside to meet with me, then they have the time to do my tasks.

Too many meetings can sap your productivity and prevent you from achieving the state of flow when working on a design or coding task. So a necessary component of managing your time is to manage your meetings.

The number one benefit of working four days a week is a better work-life balance - I have more time to spend with my family. It is easier to do the many household chores that need to be done plus have personal time to spend on my own activities, such as writing this article. When I worked five days a week, the standard two-day weekend sometimes felt rushed to me as I tried to get everything done that had been put off till the weekend. With three-day weekends (since I take Mondays off), there is always at least one day to unwind and relax. This leads into another major benefit of the four-day work week - less stress. Working only four days means one less day of work stresses, and one extra day to relax and unwind. This helps prevent burnout and keeps my motivation level at work higher during stressful times. Having more time for non-work activities also helps reduce the stress of trying to balance the many competing demands for my time. So the four-day work week reduces stress in both the professional and personal aspects of my life.

There is one significant drawback of the four-day work week that you are likely wondering about. What about the drop in pay? Working four instead of five days a week represents 20% less hours worked, which corresponds to a 20% drop in pay. It is quite possible to handle this kind of pay reduction, typically by reducing your discretionary spending. You may think it is not possible, but consider that assuming 3% annual raises, you would have made 20% less than your current income six years ago. Reducing your income will also reduce some of your corresponding expenses, such as taxes and travel costs for the one day a week you stay home. However, this kind of fiscal restraint is not for everyone, and I'm not saying you should do it. I didn't - I chose a different option: keep my full pay and make up the one day a week instead.

Yes, officially I still work five days a week. How do I make up the one day a week when I am not at work? Over one year, that is 52 days. I use a variety of ways to make up this time. I receive 11 statutory holidays and three weeks (15 days) of vacation that I use. I work slightly longer than the standard eight hour work day - putting in an extra 30 to 60 minutes of overtime each day. A simpler option would be to just work ten hours a day, which over four days adds up to the 40 hours needed per week, but that is too much for me. As I wrote in my article Overtime Considered Harmful, my productivity and motivation drop too much when I work that much overtime. I have noticed, however, that I can handle slightly higher levels of overtime working four days a week than I could working five days. Assuming on average an extra 40 minutes a day of overtime works out to about 17 extra days over a year. This gives a total of 11 + 15 + 17 = 43 days, leaving 9 days (52 - 43) to make up. One final option I take advantage of is to go on-call. When I am on-call, I earn 9 hours a week for holding the phone, even if it does not ring. Many people dislike being on-call, but in my current role I am able to respond to calls from home, without traveling to the office, and the phone rarely rings. So by going on call one week a month, I earn approximately 14 more days a year. This is five more days than I need, leaving one week of vacation.

Using the approach outlined above allows me to work four days a week and still pull in my full salary. But I do have to sacrifice most of my annual vacation and be on-call. This approach will not work for everyone. Not all workplaces offer flexible work schedules, and only certain types of jobs have an on-call role. But there are many other options to arrange a four-day work week. One option is to combine a pay cut with making up time. Taking a 10% pay cut will give you one day every two weeks, which leaves only 26 days to make up a year, which is possible just with statutory holidays and vacation. If you don't want to use up your vacation, you can work some five-day work weeks - doing this once a month with a 10% pay cut leaves just 4 days to make up after holidays. Working from home might also be an option worth considering. Even if your workplace does not officially support a flexible work schedule, try talking to your manager. Especially if you are a valued employee, they will be motivated to keep you happy.

Before switching to a four-day work week, you need to decide which day to take off. I believe it is best to consistently take the same day off each week to minimize confusion for your coworkers and boss. I personally like taking Mondays off, mainly because many statutory holidays fall on Mondays. If the majority of your work involves dealing with others and attending lots of meetings, then I suggest taking Fridays off - that seems to be a favorite day for people to take off, especially in the summer, and there seems to be less meetings scheduled on Fridays than any other day of the week. I have also heard people mention taking Wednesdays off, as that would split the work week in two, but then you lose the three-day weekend.

I heard recently that research by psychologists has shown that people working a four-day work week report on average higher levels of overall life satisfaction, particularly concerning their work-life balance. This matches my experience. I recommend you give it a try and find out how well the four-day work week works for you.