unearthing myself

monty hall

2008-07-30T03:54:00.001-07:00

The other day I was introduced to the Monty Hall problem. I had never heard it before and my first guess at the answer was wrong. After some thought (and some reading), it's obvious to me why I was wrong. Being a geek, I wanted to prove it myself with code so I wrote a quick Python class to model the problem.

import random

class Monty:
  "The Monty Hall problem"

  def __init__(self):
      print "init"
      iterations = 100
      # keep track of how often the keepers and changers win
      countKeepers = 0
      countChangers = 0
      for i in range(iterations):
          countKeepers += self.doit(1)
          countChangers += self.doit(0)
      print "of the %s iterations, the keepers won %s and the changers won %s" % (iterations, countKeepers, countChangers)

  def doit(self, keepSelection):
      print random.randrange(1,4)
      # setup the doors
      doors = [0,0,0,0]
      # pick one for the car
      doorWithCar = random.randrange(1,4)
      print "door %s has the car" % doorWithCar
      doors[doorWithCar] = 1
      # pick one as a contestant
      userChoice = random.randrange(1,4)
      print "the user chose door", userChoice
      # if the contestant is a keeper, then we can stop here
      if (keepSelection):
          if (userChoice == doorWithCar):
              return 1
          else:
              return 0
   
      # reveal a door
      for i in range(1,4):
          if (i != userChoice and doors[i] == 0):
              revealedDoor = i
              print "revealing that door %s has a goat behind it" % revealedDoor
              break
   
      # determine if the contestant wins when they change their selection
      if (userChoice != doorWithCar):
          return 1
      else:
          return 0

m = Monty()

easy does it

2008-07-25T14:32:00.000-07:00

Please do not ever tell me something is easy to do unless that task is 100% defined (which rarely happens in the world of software development) and the scope around the task is also understood by all parties (this also rarely happens).

Easy is a relative term

for a professional swimmer, 1000 meters is an easy swim
for a professional basketball player, a slam dunk is easy
for the average person, tying your shoes is easy

Easy is misunderstood

Take this into consideration. Assume that a new client of your asked for those 3 things. You thought to yourself "well, I can get a professional swimmer for the first task, a professional basketball player for the second, and I can do the last task, all in all this is an easy request". So you quote the client a cost and a time and get to work on things. You schedule the professionals to come in and have everything set to go -- you're even ahead of schedule. You call up your client to schedule the presentation and tell them to meet you at the local gym next Tuesday at 3:00pm. Your client pauses for a second and asks "why are we meeting there?". Now it's your turn to pause and then you say "well, it's for the demo of the three tasks that you asked to see". The client then goes on to explain that the swimming should be an outdoor swim in water with 2-3 foot waves, the basketball player needs to jump from a distance of 8 feet from the rim and the rim is at a height of 12 feet, and the person tying their shoes should be a dyslexic middle-aged man with lower back pains.

A level playing field

Easy assumes that everybody involved is working on a level playing field, but in reality, how often does that really happen? I'd venture as to say never. Even team members who have been working on the same project together for 4 months can still have communication breakdowns -- I've been there.

Easy doesn't do it

While it isn't my first rule, it's up there in the list. Do not use the word easy when discussing the difficulty of a task. Don't do it. I beg of you, don't do it.

jack of all trades, master of none

2008-07-25T08:50:00.000-07:00

Would you rather have the ability to do 25 tasks with an average level of expertise or 5 tasks at an expert level?

tenets of project management

2008-07-10T13:20:00.000-07:00

The manager should empower the team
The manager should guide the team
The manager should be the buffer between the team and outside forces
The manager should never lie to the team
The manager is accountable for the team
The manager must be a good communicator

pet peeve

2008-07-10T13:13:00.000-07:00

Don't present me with a solution to your problem, present me with your problem and I will help you understand your problem and work with you towards a solution to your [newly] well-defined problem.

focus

2008-07-10T12:57:00.000-07:00

Sometimes I am so focused on a task that anything unrelated to that task is completely lost on me -- conversations, appointments, breathing. This is both a good and a bad thing. Good because when I'm focused on something, I can really get things done. Bad because I lose all flexibility to think outside of what I'm doing.

This has bit me in the ass on several occasions recently.

In my current role, I am managing the development efforts for a pretty big project. This is my first role as a project manager and has been an enormous learning experience for me. Anyway, one quality of a good manager is being able to think and react quickly to any number of challenges that arise throughout the day. If I'm super-focused on a specific task or mindset, I become less effective in responding to the issue at hand.

And that leads me to yet another challenge: how to balance focus and determination in my task work with being open-minded and agile in handling the many issues that arise on a daily basis.