stevedoria.net

The question about my greatest weakness has been raised in almost all my job interviews. Many books on job interviews discourage people from construing a strength as a weakness. One of my greatest weaknesses is my drive for perfection. When I perform a task, I want its completion to approximate perfection. Paying attention to details in workmanship and quality is viewed by many people as a positive characteristic for an employee. Being obsessed and compulsive about achieving perfection at the levels that are satisfactory to me actually serves as a big drawback.

My high school English teacher made me aware of my perfectionist nature. She told me that my persistent drive toward perfection would be a source of many failures. With the memory of her warning imprinted on my mind and some introspection, it is easy for me to remember instances when perfectionism caused failure. I state that perfectionism is my greatest weakness for this reason.

As a project milestone draws near, I feel my desire for perfection resurface. My apparent options are to continue developing an environment that will simplify future tasks with the cost of missing the milestone or delay the development of the environment, switch to a brute-force coding effort, and attempt to reach a milestone with a low probability of success. I believe that game theory calls this a “lose-lose” situation. I am, however, driven to lose this situation in such a way that winning future situations is easier.

Although I see perfectionism as one of my shortcomings, I believe that perfectionism or the desire to make future tasks easier is appropriate for the current situation. Sometimes, perfectionism serves as an acceptable heuristic for finding the best path to an optimal solution. One adage that I saw on a whiteboard at a previous company is “do things right the first time.” I shall commit myself to doing just that.

Just know that when it comes down to the wire, it’s just garbage in and garbage out. Reducing the implementation of software to the practice of accepting data from somewhere and preparing it to be used elsewhere has certainly helped me hit the ground running and get up to speed with existing projects.

Before setting resolutions for 2007, I should reflect on my 2006 resolutions of organizing, rethinking, focusing, and succeeding. Workspace organization has improved incrementally throughout the year, and it continues to be a work in progress. I have placed much effort in minimizing my drive for perfection and made myself more comfortable in dealing with systems that are less than ideal. I also started minimizing schedule risk while continually developing solutions by having functional implementations available when schedule milestones are reached. Throughout the year, I’ve been fairly focused on achieving my primary objectives. I have not given much time to other computing interests such as computer graphics programming and open source development. Success that was achieved in 2006 is based on an avoidance of total failure.

Now, for 2007, I will begin allowing myself to fully depend on others. I did not have the ability to depend on others, because of project time or quality constraints. Lack of team involvement will be minimized or eliminated in future projects through sufficient project documentation, subsystem modularization, and module-based implementation assignments. More people will be involved in the research and development of software modules. Localizing knowledge of a system to an individual with an inability to transfer that knowledge to others is a mistake that must be countered this year, and project documentation that is more meaningful will help significantly.

I need to displace some project accountability from myself. Although there may be an increase in schedule and quality risks for future projects, the determination of the team’s successes and failures will be more distributed within the team and less concentrated on me. The team should not fail, because I fail. It should fail, because the entire team failed. This is not to say that I am looking to shirk responsibility. I am merely opening myself to sharing more of the responsibility with others. I will depend on the team to deliver what is requested as the team depends on me to provide them with what is needed.

I’ve been reviewing and documenting other peoples’ code lately, and I found some vexing patterns that came up constantly. Seeing in an if-else statement that the first (or last) few lines evaluated when the conditional is true match the first (or last) few lines evaluated when the conditional is false was a little bothersome. It is as if someone copied code in their editor and pasted it where they needed it.

An example snippet of code is:

function f()
{
   if( g() )
   {
      // statement_1
      // statement_2
      // ...
      // statement_n
      
      // some stuff
   }
   else
   {
      // statement_1
      // statement_2
      // ...
      // statement_n

      // other stuff
   }
}

Firstly, if a sequence of code is present in two or more places, wrapping the sequence within a function and calling the function may make the code just a bit more elegant. Wrapping identical sequences of code within a function localizes the code that needs to be updated when the sequence of code needs to be changed. Localizing common sequences of code within a function eliminates the need for programmers to track down all identical code sequences where and when an update is desired.

Wrapping statement_1 through statement_n in a function, h(), results in the following code:

function h()
{
   // statement_1
   // statement_2
   // ...
   // statement_n
}

function f()
{
   if( g() )
   {
      h();

      // some stuff
   }
   else
   {
      h();

      // other stuff
   }
}

The code’s annoyance factor can be further minimized by noting that h() is the first statement that is evaluated after the if-else conditional expression evaluates to either true or false. Since h() is evaluated without dependence on the if-else conditional expression, it seems sensible to move h() out of the if-else statement.

The resulting code is presented here:

function h()
{
   // statement_1
   // statement_2
   // ...
   // statement_n
}

function f()
{
   h();
   if( g() )
   {
      // some stuff
   }
   else
   {
      // other stuff
   }
}

I noticed the issue after writing pseudocode that closely matched existing code and looked like this:

I thought that the following pseudocode would be easier to read and more concise:

Okay, David got me into this. The idea is to share five things about yourself that people may not know, then tag five bloggers so they can rinse, lather and repeat.

I was tagged by David Gagne, who was tagged by Speaking Freely, who was tagged by MarketingGuy, who was tagged by Aaron Shear. The game was started by Jeff Pulver.

I’m going to pass it on to Shanti, Truman, Kymbrla, the Force, and ZorbaTHut.

So here are five things you may not know about me-

1. I am interested in learning the languages of the Axis Powers. I gained some exposure to the languages of the Pacific theatre.

2. I have never read a fiction that was not assigned, and I sometimes didn’t read the fictions that were. I was really rooting for the Great Gatsby to get with Daisy and live happily ever after, though.

3. I am a hopeless romantic, I guess.

4. I looked down on web developers, and I even scoffed at the idea of being a “web programmer” along with some representatives from Boeing at a school career fair. Two years later, web applications development became my primary occupation.

5. I can’t swim, but I enjoy deep-sea fishing.

Tag! Yer it!