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.

To those with a bureaucratic mindset process and audits are the answer to every problem: if something goes wrong, add more process and then audit to ensure it is followed.

Audits serve a purpose, but they do have drawbacks. Over-reliance on audits can actually cause negative consequences to the organization which are often not taken into account by those pushing for more auditing. Audits should be designed to minimize these drawbacks, and the organization should introduce additional mitigations as necessary. In fact, I would go as far as saying that the use of audits should be kept to a minimum.

So what are these drawbacks? I have organized them into the following categories which are explored in detail in the remainder of this article.

• Reduces Productivity
• Harms Organizational Culture
• Limits of Assessment

Reduces Productivity

I define productivity as the amount of value produced for stakeholders based on the effort expended. In other industries such as manufacturing with more concrete notions of value it is possible to effectively measure productivity. In I.T., however, this is difficult to do, and I have never heard of an I.T. audit that evaluates productivity, value produced, or even effort expended. Audits typically instead measure compliance to documented processes based on historical documentation regarding the work that was done. This disconnect inevitably leads to a reduction in productivity in the following ways:

Do work to pass audit rather than deliver value

Auditing documented evidence of following documented processes causes people to produce documentation, whether or not it provides value, in order to pass the audit. This is especially true when the work becomes about producing the documentation instead of producing value.

Assessing quality after the fact is wasteful

Two important concepts from lean thinking are that any time delay in a process is waste, and that quality should be built into the process to avoid the waste associated with undetected quality problems remaining in the work-in-progress. Performing an audit long after an activity has been performed violates both of these concepts. In some cases I have seen audits are performed months after the activity has been completed - for example, an audit of a software enhancement that has already been deployed to production. If problems are found, it is too late for that activity. And the follow-up to determine if the problem has been resolved typically does not happen until the next audit, which is an even longer delay.

Harms Organizational Culture

An organization in which formal audits are a common occurrence risks, in my opinion, serious harm to the organizational culture by shifting the culture towards a more bureaucratic, stagnant, and confrontational atmosphere. This can happen in a number of ways:

Shift of focus away from organizational objectives

People generally have difficulty focusing on more than one or two priorities at a time. When the focus is placed on passing audits, attention is diverted away from achieving the organization's objectives or purpose. This is similar to the problem faced by traditional project management - making scope, schedule, and budget the goal runs the risk of not actually meeting the business needs.

Compliance mindset rather than improvement mindset

Formal audits, especially when they are treated strictly by management, tends to lead to a fear-based compliance mindset. The unspoken message is "pass the audit, or else...". This is inimical to a mindset of continuous improvement, specifically the attitude of being willing to change the process when a better approach is found. In theory a process-centric mindset and a continuous improvement mindset can coexist - Toyota seems to be successful at this. But adding audits into the mix adds a rigidity or bureaucracy to processes that impedes continuous improvement. Worse is when people blindly follow process rather than question whether there is a better way.

Attitude of confrontation rather than collaboration

Formal audits almost always involve separate auditors external to the group being audited, and sometimes external to the organization. And these auditors are trained and motivated to find non-conformities - deviations from process. Auditors are not engaged to work with the group to understand what they have done and to help them do better. In fact, they are often instructed to remain aloof in order to remain impartial. This tends to lead to an attitude of confrontation rather than collaboration - an us-versus-them mentality - which means that any useful feedback that the auditors might have is at risk of being denied or ignored.

Discourages context-based expert judgement, creativity, and initiative

The Dreyfus model of skill acquisition explains the difference between beginners and experts. Having a clearly defined, step-by-step process to follow is essential for beginners, but has been demonstrated to actually reduce the performance of experts, who use their judgement based on the context at hand to determine what to do and how to do it.
Enforcing adherence to a common process also discourages creativity, initiative, and innovation. This can happen in a bureaucratic environment without audits, of course, but I believe that a regime of formal audits will exasperate the problem.

Limits of Assessment

Audits at their essence are about assessing a group with respect to some standard. This assessment has certain fundamental limitations due to the nature of audits, and over-reliance on audits risks developing an incomplete or inaccurate picture of reality. These limitations include:

Cannot assess intangibles

Audits only assess concrete items that are documented and completely ignore intangible aspects of work such as motivation, creativity, and initiative. (Some of these intangibles can be assessed by other 'formal' mechanisms - e.g. assessing motivation through surveys.) The corollary to the adage "you get what you measure" is that you risk not getting what you don't measure. This would not be a problem if the intangibles were not important. But software development is knowledge work, and the research is clear that people are by far the most significant factor determining productivity, far ahead of process. So relying on audits, which typically only look at process, ignores the more intangible, people factors.

Assessment is twice removed from objectives

Each group or organization has a purpose for existence, and objectives by which it tries to achieve that purpose. Audits do not assess this. Organizations put processes into place to support meeting these objectives. But audits, strictly speaking, do not assess this either. Audits assess the historical, documented evidence that the processes were followed. This means they are twice removed from the true objectives, which makes them an incredibly weak tool for helping an organization meet its objectives.

Audit results may be invalid

Audits suffer from four failure modes which can cause them to report invalid results:

1. The group is actually following the process being audited, but is not correctly producing the evidence.
2. The group deliberately deviates from the process in order to meet organizational objectives or in order to be more effective.
3. The group produces the documentation used as evidence for following the process without properly following the process. They will pass the audit, but there is a hidden problem. Rubber-stamping, where a review or approval is given without any actual check or thought, is an example of this.
4. The group properly follows the process and produces the evidence, but fails to achieve organizational objectives.

In conclusion, be very careful in how you use audits and watch out for the drawbacks. Maybe you should audit your use of audits :)

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 ability to work independently and the amount of assistance provided to others both correlate negatively with task difficulty and correlate positively with the level of contribution to the team. This similarity of relationship allows us to combine both the independence and assistance measures into what I call "net team contribution". Similar in concept to a financial balance sheet, net team contribution is calculated as contribution assets - personal achievements and the help provided to others - minus contribution liabilities – the help that others had to provide.

I explained in my prior article that there are two thresholds of task difficulty: the level of difficulty at which you start to require assistance, and the level of difficulty at which the task is so excessively difficult for you that it is completely beyond your capabilities. Relating these thresholds to net team contribution results in four zones of contribution. The graph below provides a visual representation showing net team contribution as a function of task difficulty.

The four contribution zones are as follows:

1. Provide Assistance Zone: The task is easy for you to complete. You can easily see the way through obstacles faced by others and can effectively help them with their issues. Working primarily on such tasks yourself probably is not the best use of your time.
2. Independent Work Zone: the task is just easy enough that you can work on it independently with minimal assistance, but it is still somewhat challenging.
3. Help Required Zone: the task is difficult for you and you require some assistance to complete it. This zone starts at the first threshold of difficulty of requiring assistance.
4. Negative Contribution Zone: the task is very difficult for you. You require so much assistance from others on the task that they are essentially doing it for you. It is more cost-effective for others to simply complete the task themselves. This zone starts before reaching the second threshold of excessive difficulty.

Understanding these contribution zones and the underlying relationship between contribution and difficulty is helpful in ensuring a team is running smoothly. Is someone who has previously worked largely independently now struggling with a task? It is probably beyond their threshold of ease, so be sure to provide some assistance. If a developer is completely stuck and at a loss for how to proceed, the task may be completely beyond their abilities, in which case reassign it. When looking at the set of tasks to be tackled by the team within a single iteration, ensure there is a balance of complexity. Too few complex tasks leaves the more capable members under-utilized. Too many complex tasks is especially dangerous: it will result in the more capable members being too burdened by tasks near their level of ability to effectively provide the assistance required by the more junior members, while the juniors will be largely unable to make effective progress due to the complexity.

Some authors recommend focusing on improving your (or others) weaknesses. They generally believe that being well-rounded is important, and a common analogy is a chain of many links only being as strong as the weakest chain. The strongest case for this position I feel comes from the entrepreneur literature: for a business to be profitable, you not only need a good product or service, but you also need the marketing and sales to have sufficient sales, and the financial management to manage your cash flow and ensure profitability. A weakness in just one area can jeopardize your entire business.

Other authors recommend focusing on developing your strengths. A common argument is that building specific expertise generates the most value, and that it is easier to improve areas of natural ability than weaknesses. Areas of weakness can be delegated or outsourced to others. This recommendation corresponds with the general trend in the labor market of increased specialization.

As I have observed the performance of individuals and teams and dealt with employee performance problems, I have come to realize that this strength / weakness categorization is largely artificial and is not the best model.

I have instead adopted a model based on defining the minimum and optimal thresholds of competence for different aspects of a specific role. The minimum threshold defines the level under which a person will fail (have inadequate performance) in the given role. As your ability increases above the minimum threshold, your performance in the given role improves until you reach the optimal threshold. Beyond this point, increased ability will not improve performance. See the diagram below for a visual representation.

This model accounts for the phenomenon where people who have been doing well or even excelling in a particular position suddenly encounter difficulties when moved into a different position. The reason is that the new role demands a different set of thresholds for which the person falls below the minimum in one or more areas. The classic example is taking an exceptional software developer and promoting them to a manager. This person’s software development skills now exceed the optimal threshold required for a manager, whereas the communication and management minimum thresholds required as a manager are much higher.

The impact of what are traditionally considered strengths or weaknesses depends on the particular role. In some cases a personal weakness may still at a sufficient level to exceed the minimum threshold of competence. One example is having a fear of public speaking (which is apparently quite common). For the typical software developer position, the minimum threshold required for public speaking is very low – a developer just needs to be able to participate in team meetings and group discussions. So this weakness is not particularly relevant for the role. In other cases the team has mitigation strategies in place to address common weaknesses, thus lowering the minimum threshold required for certain roles. One example is developers performing manual testing. This is often not a strong ability for many developers due to the different mindsets required. So development teams incorporate dedicated testers to address this issue.

If personal strengths and weaknesses are misaligned with a role’s minimum and optimal thresholds, with a person being above the optimal and below the minimum in a number of areas, then this generally indicates that the person is in the wrong role.

Even personal strengths may fall below the minimum threshold of competence. This often indicates that the person has been given an assignment too difficult or challenging for their level of experience. One example is giving a good junior developer extremely complex functionality to implement from scratch without guidance. A senior developer could get the job done, but the junior lacks the knowledge and experience – their ability falls below the minimum threshold, despite being a strength for them personally.

A common mistake is to continue to focus on developing your strengths after you exceed the optimal threshold, due to a logical slippery slope. If you begin a new role with most areas below the optimal level, then you will naturally be motivated to improve your strengths and see a corresponding improvement in performance. This motivates you to continue to improve in these areas, even after they exceed the optimal threshold. Malcolm Gladwell in his book Outliers the Story of Success provides a specific example of this phenomena dealing with I.Q. Most people believe that being smart helps one succeed in most areas of life, and that having an even higher genius-level I.Q would be better. I admit to having shared this belief. The extensive research study discussed by Malcolm, however, clearly contradicts this by finding that individuals with genius-level I.Q. did no better in terms of career than those who are ‘only’ smart. So across many fields I.Q. does have an optimal threshold as well as a minimum.

Using this model of minimum and optimal thresholds of competence clears up the confusion in the literature on whether to focus on strengths and weaknesses. Ignore those labels and instead focus on how your abilities align with what the minimum and optimal thresholds are for a given role – either your current role or the role you desire.

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.

There are many resources for personal development but they tend to be fragmented and look at only one aspect of life: i.e. a book on health versus finances versus character-building. I recently discovered that Steve Pavlina, a renowned personal development expert, had developed a unified conceptual framework for personal development and was presenting it in his book Personal Development for Smart People: The Conscious Pursuit of Personal Growth. This peaked my interest so I took advantage of the opportunity to get a free review copy of the book in advance of the release date. What follows is my review of the book, particularly my impressions of it and how I think it is relevant for software developers.

The book consists of two sections: the first identifies the seven principles that make up Steve's unified framework for personal development, and the second section covers the practical application of these principles to all major aspects of life. The seven principles consist of three core principles: Truth, Love, and Power, and four derived principles: Oneness, Authority, Courage, and Intelligence that are combinations of two or more of the core principles. One of Steve's main thesis in this book is that all personal development issues can be addressed through the proper application of the three core principles. An interesting corollary is that one's problems in life can be traced to an imbalance or lack of one or more of the core principles. For example suffering from low motivation at work is likely a sign that your heart is not invested in what you are doing, which comes from the principle of love.

I think the book is worth reading just for this framework of principles. I love the way the material is logically organized in this first section; it appeals to my left-brain-oriented style. Each chapter within the first part covers a single principle and each principle is broken down into a small number of key components or aspects. The principle of power, for example, is decomposed into responsibility, desire, self-determination, focus, effort, and self-discipline. After covering the various aspects of a principle, the rest of the chapter covers obstructions to full use of the principle and exercises to help understand or connect better with the principle. I also like how the end of each chapter leads directly to the next principle. There is enough meaty material in this first section that it could have stood on its own, but fortunately Steve provided the second section.

Section two of the book covers the application of the principles to the areas of Habits, Careers, Money, Health, Relationships, and Spirituality. In each chapter Steve relates that life area to each of the seven principles and often provides exercises or tips for how to gain insight and improvement within that area. There is a lot of good material in this section, but at times I was left feeling like there could have been more. For example, I hoped to find in the Career chapter information related to developing and growing within your career. The focus of the chapter, however, is on ensuring you have chosen the right career, which is not what I was personally looking for. Some chapters do not explicitly specify any exercises, although some are implied. I view this second section as more of a reference or resource section where you pick and choose the chapters relevant to your needs.

One thing I found generally lacking in the book was the use of diagrams or pictures. This might have been because I received an electronic PDF review copy of the book, rather than a paper copy. But I would have liked to see a diagram showing the seven principles in the book's introduction (Steve used a nice diagram in one of his promotional articles about the book). I also would have liked to see a diagram, ideally a mind-map, at the start of each chapter in section one showing the principle being discussed in the center and the various components of the principle arrayed around it.

If you are not a regular reader of Steve's blog then you may be surprised by some of Steve's non-mainstream viewpoints on topics such as diet, career, and spirituality. Steve does a decent job of not pushing his own agenda, but given his passion for the topic of personal development, his viewpoints can not help but shine through. Steve does emphasize the importance of experimenting and figuring out what works for yourself (from the principle of Truth), and does say to ignore his own advice if it does not work for you.

My final impression of the book is that it is not really trying to provide specific answers but instead enables readers to discover their own answers and approaches. With this in mind, let me turn to the question of how this book is relevant for software developers looking to advance their craft and capabilities. I am going to follow the template used in section two and reflect on how each of the three core principles applies to software developers.

Truth

The principle of truth requires that our perception of ourselves and of reality is as accurate as possible. Assuming that software development is the right career for you still provides a wide latitude of options regarding the roles and responsibilities you have within this career. For example, do you like developing user interfaces or back-end batch processes? Commercial software, enterprise software, open source software, or public web sites? Focus on coding only, or include other activities such as design, requirements, or project management? Examine what you are currently doing: is it right for you?

We evolve our model of reality by encountering new experiences that fall outside our current model and force us to adapt. I liked Steve's statement "excessive routine is the enemy of growth". To continually grow we must therefore constantly be seeking out new experiences, challenges, and ideas. The Pragmatic Programmer's recommendation to learn one new programming language a year, preferably ones that use a different style of programming, is one example of doing this. The goal I aim for is do at least one thing new or different on each project. I like to refer to these as experiments, in large part because it removes the stigma of failure. If the experiment does not work out you still learn something. Here are some suggestions for experiments:

• Use a new library, framework, or tool. I like to maintain a list of ones that I want to try out, and then if one of them is applicable to my current project use it. My current list includes Google Web Toolkit, TestNG, MavenMaven, and Joda Time
• Work on a system with a different architecture such as web 2.0, client-server, rules engine, extract-transform-load process, reporting, or messaging.
• Perform one or more non-coding activities that you normally would not such as requirements analysis, system testing, performance testing, project management, or database design.
• Change your methodology or process. Try out practices such as automated unit testing, continuous integration, or code reviews. If you are doing iterative development, try changing the length of the iterations. Try doing less (or more) formal documentation. Try doing more design up front or as late as possible.
• Use a different style of coding. Try test-driven development or design-driven development. Try to comply with particular design and coding principles such as the Law of Demeter.

Steve points out that uncertainty is an essential part of reality that we need to accept and even thrive on. The idea that we cannot plan or anticipate everything in advance and that change will happen is closely aligned with the principles of agile development. I believe that agile approaches are more successful than other approaches (i.e. waterfall) because agile is a better match for reality. In terms of Steve's framework, agile aligns more closely with the principle of truth.

Love

It probably seems weird at first glance to discuss how the principle of love relates to software development. But that is just the cultural baggage behind the word "love". Consider how being passionate about your work might be relevant to our effectiveness as software developers, and suddenly it does not seem so bizarre. In fact I believe that all three aspects of the principle of love – connection, communication, and communion – are very relevant to software development.

Steve defines the act of connecting as "to give something your attention, to think about it, and to engage with it." If our goal is to learn and grow as software developers, connecting with the craft of software development in terms of giving it our time and thinking about it sounds necessary. Part of the key is to consciously choose what to connect with versus disconnect from: aspects of software development that do not interest you or that you feel you have mastered and can gain no more from should be discarded in favor of aspects that you feel drawn to.

Communication is ever-present for most software development efforts: there is communication between the users or clients and the development team, communication between team members, communication between development and maintenance or quality assurance teams, and communication between the team and management. Effective communication is therefore almost always a critical success factor. To emphasize this point I want to share a discussion from a recent continuous improvement meeting I chaired. We were discussing the development activities of a particular team that had experienced repeated problems with users finding numerous issues and defects in acceptance testing despite an apparently-thorough successful system test. The team representative mentioned that code reviews were not really being done and that automated unit testing was haphazard at best. I quickly jumped on this as the reason for these problems and began trying to identify improvement opportunities. The team rep stopped me, thought a bit, and then surprisingly stated that he did not feel lack of reviews or unit testing were really the root cause of this problem. As he reflected and we discussed further, we identified that the real culprit was that users were not sufficiently involved throughout the development activities. Brief requirements were gathered from users at the start, documented, and reviewed by the users, but then there was no further interaction until acceptance testing. Limited communication between the business analysts gathering requirements and the developers was also a contributing factor.

So if effective communication is critical, how can it be achieved? Steve points out that face-to-face conversation is the richest form of communication. This happens to be one of the principles behind the agile manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." Steve goes beyond this surface level, however, by saying "genuine communication requires mutual understanding rooted in ... trust.", and trust is in turn based on establishing a connection with the other party. Again there are echoes of this in one of the agile manifesto's values: "Customer collaboration over contract negotiation".

Communion is the sense of bonding that arises from communicating and establishing a connection. DeMarco & Lister in Peopleware discuss the importance of what they call "jelled" teams in making a drastic improvement in team performance. Actually elsewhere in the book they instead use the term "bonded team" (see page 121), which maps directly to Steve's terminology. I believe that this can be expanded beyond just the boundaries of the team to include users, clients, and management. This is sometimes referred to in a diluted form as "partnership" or "mutual respect and trust". I think many of the less-efficient or dehumanizing aspects of software development are due in large part to this lack of communion. Typical industry examples of this include: management requiring extended unpaid overtime from developers, us-versus-them attitudes between developers and testers or developers and users, clients requiring detailed statements of work with fixed price estimates in contracts, and vendors winning a contract using senior resources and staffing the contract using less experienced resources. The net effect of this disconnection is either more overhead or reduced developer motivation.

I recommend the values & principles of the Agile Manifesto and reflect on how much of it actually aligns with the principle of love in terms of relating to either connecting, communicating, or communing. I think one reason for both the effectiveness of agile approaches and its wide-spread adoption by the development community is this alignment.

Power

The principle of power is essentially about making decisions and taking action. The two primary sources of power are motivation and willpower.

The strongest motivation comes from pursuing goals that you are passionate about and are committed to. Psychologists classify this as intrinsic motivation and contrast it with extrinsic motivation, which in the workplace consists of factors such as paychecks, promotions, and pressure or praise from peers and superiors. This suggests that an important element of asking people to do work, whether it is your development team starting a project or just a coworker to which you are delegating a task, is to share your passion and commitment by explaining why this activity is important and worth pursuing. This can backfire if you are not sincere, so make sure you have that intrinsic motivation first. Steve provides an excellent metric for determining if a goal is sufficiently motivated: "If your goals don't inspire you at least as much as going on vacation, they're lousy goals." One counter-intuitive strategy for boosting productivity is to choose activities to perform based on your current motivation rather than the priority of the task. This helps maximize throughput, as you will tend to be more productive on each task.

Motivation based on passion and commitment is actually an interaction of the three core principles: passion comes from the principle of love which we need to become aware of via the principle of truth and then decide to commit to via the principle of power. While motivation is a necessary ingredient to achievement, it is not sufficient. As Steve says: "Motivation starts the race, but self-discipline ultimately crosses the finish line."

Willpower, or self-discipline, needs to be applied intelligently. Steve says "This includes having the discipline to get things done on time without resorting to extreme measures." When I read this, I immediately thought about the common practice of overtime in software development, which I consider an extreme and unintelligent measure. Many of the causes of overtime can be traced back to one of two sources: The first is an unrealistic project plan, which is a failure to align with the principle of truth. The second is a desire by management to get the software done faster with no regard for the people working the overtime, which is a failure to align with the principle of love.

Conclusion

The main message of Steve's book is the subtitle "The Conscious Pursuit of Personal Growth". Part of my vision is to help software developers learn and grow, and I hope my points on how the core principles of personal development – truth, love, and power – apply to software development inspire you. I leave as an exercise for the reader to consider how the other four derived principles of oneness, authority, courage, and intelligence apply to our field. I recommend that you get the book to help answer this question and guide you along your chosen path.