stevedoria.net

The winds of change have scattered my team among several companies. The cohesive forces experienced between team members at my previous company have resulted in groups of people finding themselves working in new environments with others of our previous company. Two former teammates have relocated to a semiconductor company, and two others took up positions at an aerospace company. I joined two colleagues from my previous company to be a part of another company. Other groups have similarly formed, and they work together at other companies.

Having been at a small technology company has allowed each team member to develop skills that are highly marketable. With each team member interested in developing their skills, an arrangement evolved where an engineer earned experience in all phases of the development life cycle. The software development team, for example, rotated the responsibilities of designing, implementing, and testing software components. At some point during the projects, the latest additions to our team would be responsible for critical and complex parts of the systems. Each member gained experience delegating work and tracking the progress of their modules. The team as a whole was also responsible for integrating these software components to yield the final deliverable products. This environment, with its opportunities for self-development and enhancement of professional maturity, was fostered by an effective managerial style practiced by experienced management.

I have interviewed at numerous companies, and received several offers. My interview experience and results are shared with many of my former teammates. The former company left us in a stronger position that allowed us to select our next company among those that would give us opportunities. While I was engaged in interviewing, I was interested in the team that I would be joining, the type of projects, and the environment overall.

I am thankful that many of the people with whom I interviewed were very candid. One company explained to me that being at the office for at least 60 hours per week as well as being reachable while away from the office was expected and typical. Another company informed me of their lack of process and documentation, and gave me a warning about a challenging transfer of knowledge and steep learning curve. The management of this company expressed interest in increasing formalism, and I was willing to be accountable for effecting positive change, but the environment seemed too challenging to encourage change without real authority. Ultimately, my selection of an opportunity depended on the team, the company, and my interests. My former teammates have also made their selections based on their preferences.

It is here, then, that I wish my former team members the best of luck in their endeavors. I hope that their careers lead to achievement, personal fulfillment, and betterment of society as a whole. And, I would strongly consider taking the opportunity to work with any of my former team members in the future.

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.

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.

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.

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.