Do Not Disturb: Working

December 28th, 2010

Jason Fried gives a talk entitled Why Work Doesn’t Happen at Work. He presents his observation that people feel more productive when they work at places other than their office, into which companies invest heavily with the hope of maximizing worker productivity. He concludes that people find other places for work more conducive to productivity, because those places have fewer involuntary distractions.

Fried draws a similarity between sleep and work by claiming that constant disruption of these tasks causes similar effects. Constant disruptions reduce the positive effects of both tasks. He highlights two significant sources of work disruptions and identifies them as M&Ms: managers and meetings.

To make the office a place where more people feel that they can get a lot of work done, Fried makes three suggestions to minimize constant disruptions to work. He encourages managers to foster a work environment that uses asynchronous forms of communication such as email or instant messaging. Although these forms of communication are also a source of distractions, the recipient of the communication can choose a convenient time for the distraction. Fried also recommends adopting a company policy that insulates workers from disruptions by barring communication between workers for a specified period. He suggests that it be labeled “No Talk Thursdays” or something similar. Lastly, he proposes the elimination of meetings. The issues that are typically addressed in larger meetings can potentially be resolved through emails between a few individuals.

I have labeled the impact of disruptions on work as “context switch overhead,” which is a phrase commonly used in discussions on multitasking operating systems. Recognizing the resource intensity of a context switch allows the value of predefined periods of uninterrupted work to be apparent. Using email, and instant messaging as needed, for communication allows workers to schedule convenient times for these disruptions. These recommendations are fairly easy to accept.

Certainly, some development teams will have trouble adopting Fried’s last recommendation, the total elimination of meetings. Latency in email responses are a possible cause of schedule slip. In extreme but not so rare cases, delays in or lack of communication are sources of work stoppage. A weekly meeting, one that Fried seems to oppose, is a good mechanism to allow all team members to coordinate their work efforts. Though meetings are set to begin at particular times, there is no reason that meetings cannot terminate before their entire allocated 15-minute blocks are used. The rigid adherence to using all of a meeting’s allocated time, as observed by Fried and used by him to justify his suggestion, is not required nor recommended. Because such adherence is not always practiced, absolute elimination of meetings is not justified. Unlike Fried’s development experience, I have had the experience of developers calling meetings between themselves that resulted in allowing each developer to more effectively focus their efforts.

Judging a Book by Its Table of Contents

December 23rd, 2010

I stumbled upon a draft of a book on programming languages, which from a look over the table of contents seems to cover topics for a compiler book. Robert Harpers’s home page links to his book, Practical Foundations for Programming Languages. Whenever I find the time to read up on programming languages and compiler, I can find my local copy here.

On Thanksgiving Vacation

November 21st, 2010

2010 has been a very busy, yet brutal, year. I have used more vacation hours this year than any of my previous years of employment. By leveraging the Thanksgiving weekend, I am able to have nine contiguous days of rest from work at the cost of three vacation days. As is the case for sleep, having a nice contiguous amount of time for a vacation is more fulfilling than interrupted short bursts of rest. I am relaxed, and I am feeling pretty good.

Write Less Code

August 27th, 2010

I have recently come across multiple sources that recommended writing less code or just enough code to get the job done. Fewer lines of source code mean fewer lines of code that needs to be documented, tested, and maintained.

In a situation where lines of code is not being used as a performance metric, lines of code should be minimized while adhering to a project’s constraints. A project’s constraints may require that the source code is readable. In the interest of security, it may require checks to be redundant. The project may also require the software to be compartmentalized with well defined interfaces. The need to add whitespace for enhancing readability, conditional statements to address security, and interface declarations to increase modularity will undoubtedly increase source code length. Writing less code should be done by writing only code that addresses the project’s objectives, and eliminating unnecessary or nonoperational code.

I have seen code implemented as follows:


int f( int x )
{
  int y = 0;
  if( x > 0 )
  {
    // some processing...
    y = 1;
    goto DONE; 
  }

  if( x == 0 )  
  {
    // some processing....
    y = 0;
    goto DONE;
  }

  if( x < 0 )
  {
    // some processing...
    y = -1;
    goto DONE;
  }
DONE:
  return y;
}

Using goto to handle cases in C or C++ where Java’s labeled breaks would be useful is arguable. The same arguments for the use of goto do not apply to the code that resembles the sample that is presented above.

Some may say that the use of an explicit goto, increases security by creating a redundant jump statement, one that is explicitly added to the other that is implicitly inserted into machine code by the compiler. After viewing the assembler code that is optionally generated by the compiler, it is proven for the situation that I experienced that the goto is ignored.

Though the goto statements are ignored by the compiler, they are distractions to people who read the source code. Rather than simply reading code that is well structured, a reader will need to search for the code label that is the target of the goto. The insertion of redundant jump statements is best implemented by the compiler. This reduces the noise that is introduced into the application source code.

In my most recent experience, minimizing lines of source code was accomplished by eliminating superfluous gotos. The updated source code is similar to the following:


int f( int x )
{
  int y = 0;
  if( x > 0 )
  {
    // some processing...
    y = 1;
  }
  else if( x == 0 )  
  {
    // some processing....
    y = 0;
  }
  else if( x < 0 )
  {
    // some processing...
    y = -1;
  }
  return y;
}

As a result, source code length is reduced, readability is increased, and testing coverage is simplified.

Watch Update Acquired!

August 17th, 2010

Swiss Army Active Original Red Bezel and Victorinox Swiss Army Classic Infantry Mechanical Self-windingMy parents gave me the Swiss Army Active Original with Red Bezel (#24221) as a gift for high school graduation, which had a retail price of 155USD at the time of purchase and is now sold by authorized dealers for 195USD. The Original features a Swiss analog quartz movement and scratch-resistant mineral crystal. Its strap consists of leather and nylon mesh with stainless steel buckle. The dial of the Original is white with bold black numerals and small red military time numerals. The Swiss Army Active Original is battery operated and water resistant, and its hand and hour markers are luminous. The day of month feature is the Swiss Army Active Original’s sole complication.

After 12 years, I upgraded to the Victorinox Swiss Army Classic Infantry Mechanical Self-winding (#24695). I purchased the timepiece, which has a retail price of 525USD, by special order through Classic Design Fine Jewelers at the Glendale Galleria. The Classic Infantry Mechanical Self-winding features a 25 jewel Swiss automatic mechanical movement, scratch-resistant sapphire crystal, stainless steel case, and a see-through caseback. Its strap is leather with a stainless steel buckle, and its dial is black with white hands and markers. Aside from the dial, the crown and buckle are embellished with the Victorinox Swiss Army logo. The Infantry Mechanical Self-winding includes two complications: day of week and day of month.

The transition from a quartz movement timepiece to one with an automatic mechanical movement has surely renewed my enthusiasm for owning and wearing a watch. The Victorinox Swiss Army Classic Infantry Mechanical Self-winding allows me to appreciate the awesome engineering feat that is accomplished in a quality timepiece.

A Microsoft Windows Media Video that presents the Victorinox Swiss Army Classic Infantry Mechanical Self-winding timepiece with an ETA 2836-2 movement operating at 8 beats per second is found here.