Saturday, January 31, 2009

Playing Hurt - Can you sprain your corpus callosum?

As s long-time reader of the C2 wiki, I was pleasantly surprised to find another blogger who referenced it in a post about Playing Hurt.  Now, in comparison to, say, pro football players (American football), who play in freezing weather with sprained ankles, cracked ribs, and minor concussions, the "hurt" a programmer experiences is small potatoes.  On the other hand, since what we do is nearly 100% mental
("95% of this game is half mental" -- Yogi Berra), our "hurt" is all mental. 

The leading issues are burnout and overload.  Burnout is the end result of chronic overload, but can also be caused by other things, like continual dismissal of complaints about bad process, lots of time working on projects that go nowhere, lack of recognition, the host of typical workplace issues, and
conflicting priorities (aka matrix management)

Now, there is not anything conclusive that shows that playing hurt in Software Development leads to drastically worse software.  It's fairly clear that your product will be lower than your best, but nothing that shows it will be in the bottom half of your ability.  However, you will find that over time, your lower quality will snowball into larger problems.

Possible solutions are:
  1. discuss better work conditions with your boss - more input into schedules, process improvements, better recognition
  2. find another job - not that it's any better anywhere else, but the change in environment and the learning you have to do will make you feel better.
  3. a side project - pick something you want to fix at your job, and start carving out an hour or two a week to work on it.  Maybe it's test harnesses for your systems, or automating a build, or just learning about another part of the system.  Try to find something fun to do.

Technorati Tags --
, , ,

Friday, January 30, 2009

Probabilities and Innumeracy

As part of the National Too Much Information Week, I'm explaining some of my blogging habits.  I have a few searches looking for interesting posts in the blogosphere, and a feed reader across a number of programming-relevant sites, and I glean interesting posts from them as fodder for my posts.  It's my small part of making sure the blogs are a self-referential recursive rabbit hole.

I read this a few weeks ago, and having taken a number of math and biology classes in my years, immediately saw that the correct answer was 2/3s.  But reading the comments really depressed me.  Not because so many people jumped to the naive conclusion of 1/2, but that they are seemingly resistant to learning why the naive answer is wrong.

I'm not talking about the people who take the "commonsense" approach that the father saying "One of them is a girl" meaning "only one" is a girl - most of them seem to agree that is a semantic issue.  But those that continue to insist that with 4 outcomes, the odds of 2 of them don't add is just dumbfounding.

Just for those not wanting to just through the long discussion, here's the short form correct answer:

Dad says "I have 2 kids, and one of them is a girl.  What are the odds that I have one son?"

the grid:
             1st B     1st G
2nd B     BB         GB
2nd G     BG        GG

That is the sum total of possibilities for the family makeup

Now, the odds of a given child being male is 50% (overall, ignoring the slight differences of survival, etc), so each "box" of the grid has a 25% chance of being the "real" family makeup.  But Dad says he's got one girl, so we can exclude the upper left box, leaving 3 boxes each with 25% chance.  Now, note that there are 2 boxes with mixed kids, and one with only girls, so the odds of having a boy are 2/3s.

I think I have found the problem that everyone who says 50% is running into - they are flipping the meaning of "one of them is a girl" - they are taking this to mean they get to pick one of the BG or GG cells, but they can't do that with an even probability - all they can really do is exclude the BB cell.  In other words "one of them is a girl" only uniquely identifies a single cell for exclusion.

[later edit]
Here's a small Python program that details the logic, and shows how the bad assumptions work.  It's especially useful because the bad assumptions play directly to the numbers of boys and girls in the generated families. (some lines got folded, so if you cut&paste this, be awa

# 2kids - run simulations to test
# generate 1000 random 2-kid families
# 0 = boy, 1 = girl

import random

# generate child
def genChild():
     sex = random.random()
     if sex < 0.5:
         return 0
         return 1

# define Family class
class Family:
     def __init__(self):

     # generate family
     def genFamily(self):
         self.child1 = genChild()
        self.child2 = genChild()

     # see if there is at least one girl
     def hasAGirl(f):
         if(f.child1 == 1 or f.child2 == 1):
             return 1
         return 0

     # see if there is a boy
     def hasABoy(f):
         if(f.child1 == 0 or f.child2 == 0):
             return 1
         return 0

familyList = []
for f in range(1000):
allBoys = 0
allGirls = 0
for family in familyList:
             allGirls += 1
             allBoys +=1
print "Family breakdown: BB = ", allBoys, " GG = ", allGirls," mixed = ", 1000 - (allBoys + allGirls)

brothers1 = 0
for family in familyList:
             brothers1 += 1
print "filter by hasAGirl first, then hasABoy, number of familes with boys = ", brothers1

brothers2 = 0
for family in familyList:
    if(family.hasAGirl() == 0):
         brothers2 += 1

print "filter by !hasAGirl first, then hasABoy, number of familes with boys = ", brothers2

print "filtering by eliminating all-boy families first"
brothers3 = 0
familiesWithGirls = []
for family in familyList:
print "# of families that have 1 or more girls = ", len(familiesWithGirls)

for family in familiesWithGirls:
         brothers3 +=1
print "# of families with 1 or more girls that have one boy = ",brothers3
print "% of families with 1 or more girls that have one boy = ", ((1.0 * brothers3) / en(familiesWithGirls)) * 100

Technorati Tags --
, , ,