Sunday, August 28, 2011

Review of "The Genius in All of Us"

Subtitled "Why everything you've been told about genetics, talent, and IQ is wrong" by David Shenk.

I first saw this book at a swim meet. A parent sharing at our table was reading it and I dismissed it based on the cover main title alone. Through a discussion with the reader's wife she asked me "Are you judging a book by it's cover." My prejudice was exposed therefore I was determined to read it if only for penance.

I recommend this book especially since it is only 134 pages (with 168 pages of notes and bibliography). It starts with a story about Ted Williams that shows the dedication it took for him to become the best hitter in baseball. This theme is repeated many times.The author introduces you to the developmental systems theorists concept of GxE (genes times environment). The book attempts to debunk the myth that your abilities (and to some degree who you are) are mainly determined by genes. GxE will admit genes play a role, but that the choices one makes have a far greater impact than genes.

He then beats up Lewis Terman, but anyone who has read "Outliers" already knows the punch line: you can't predict the future based on some test, specifically one as limited as IQ. He lists some environmental triggers that I like:
  • Speaking to children early and often
  • Reading early an often
  • Nurturance and encouragement
  • Setting high expectations
  • Embracing failure
  • Encouraging a "growth mindset"
Next he introduces us to the with the work of Dr. K. Anders Ericcson. Ericsson and William Chase did studies on improving memory of "average" students. They concluded "With practice there is seemingly no limit to memory performance." From there he articulates the various myths people have spouted over the years about genius; focusing on Mozart (BTW his father was obsessed with making him the greatest composer in Europe as he had failed). He provides these themes for greatness:
    • Practice changes your body
    • Skills are specific
    • The brain drives the brawn
    • Practice style is crucial
    • Short-term intensity cannot replace long-term commitment
    Then he dives into a famous twin study (from 1981) that "proved scientifically" that genes determine 60% of intelligence and personality; 40-66% of motor skills and 21% of creativity. In case you haven't already guessed the author rips holes in this study and explains the results using GxE theory. Next he lists some emergent ideas from genetic testing of  high performers (Kenya long distance runners, Navy SEALS, Jamaican sprinters, etc):
    1. Despite appearance to the contrary, racial and ethical groups are NOT genetically discrete
    2. Genes don't directly cause traits; they only influence the system
    Guiding principles suggested by author for people who wish to be great:
    • Find your motivation
    • Be your own toughest critic
    • Beware the dark side (bitterness and blame)
    • Identify your limitations; then ignore them
    • Delay gratification and resist contentedness
    • Have heroes
    • Find a mentor
    More recommendations by the author on how to ruin (or inspire) a kid:
    1. Believe
    2. Support, don't smother
    3. Pace and persist
    4. Embrace failure
    His final point is: "Lifestyle can alter heredity."

    I admit I was surprised how much I didn't know about recent theory. I knew IQ tests were bogus. I had read Gladwell's "Outliers" and knew of his 10,000 rule, but I still held on to this idea that my genes had a lot to due to who I was. Reading this book didn't change my outlook on life, but it did change some of the dialogue around it.

    Saturday, July 9, 2011

    Lean 101

    Lean is a philosophy derived from manufacturing (see Lean.org for more details) that has made inroads into many things, including software development. When people try to adopt it they tend to focus on the techniques and often miss the big picture. When faced with a task, how you think about it will determine how you attempt to perform it.

    Take laundry for example. The most common method is to first sort all the dirty laundry into piles of like colors. Then wash them one at a time and as they wash throw them in the drier. As the dry hang and fold and/or make piles for each person to take care of their own. This divide and conquer approach is usually tool #1 in our tool-belt.

    A lean approach would start at a different place. Lean would start on value. Why do we do laundry? What's the end goal? For me it is clean clothes in my closet. If I could have elves do it for me while I slept I would be satisfied. Since I can't seem to find any nocturnal elves willing to work for free I am stuck doing it. I start with four laundry baskets (and some floors) filled with dirty clothes and I need a process for getting these clothes cleaned and put in the appropriate drawers and/or closets. The clothes need to be cleaned in the washing machine, dried (or laid out for those pesky clothes) and folded/hung in the correct location.

    Lean tells us to pull value, instead of pushing it. What does that mean? Pushing can be thought of as focusing on the sub task. Let's take the first sub task when doing laundry - sorting. Pushing is doing all the sorting before starting a single load. You make sorting the goal before you move to the next task. This can lead to suboptimization. In lean we are trying to maximize value. One tool lean has is to minimize work in process (WIP). WIP isn't value and utilizes resources without providing value. In my domestic example WIP is piles of laundry on the floor. So how do I get laundry done when I don't have pre-made piles to throw in to the washing machine?


    1. Take clothes that can be washed together from the dirty clothes hamper containing the most import clothes (mine) and toss them in the washer. 
    2. When they are done toss them in the dryer.
    3. Go to #1 until all clothes are done

    A problem this approach can run into is when I focus on maximizing the amount of clothes I can stuff in the washer. Doing this is similar to maximizing the output of a machine on a factory floor. When I do this the clean, wet clothes have to wait for the dryer. As I am maximizing the amount of clothes I put in the washer my WIP is bigger than it should be. Kanban (a practice from lean manufacturing) uses WIP limits to prevent this from happening. I simply need to learn the amount I can place in the washer so that the washing (a fixed time on my machine) matches the drying time (a variable time on my fancy dryer). This is the Lean principle of Perfection.

    In software development lean tells us to pull the value. Value is software that is being used by those that paid (at least indirectly) for the software. One common mistake when adopting a lean based software development approach is to force the business customer into breaking cohesive features into bite size ones that are of NO value to the business by themselves. Instead the development team needs to own the break down of features into bite size one and deliver the cohesive feature in a way that the business can use. Sometimes the feature can be delivered piecemeal, but often the feature is not useful until all parts (think CRUD) are done.

    The other mistake is trying to to the entire feature at once. This is comparable to shoving all the clothes in the washer. You need to find the smallest unit that works for your group. In a small group (one-two developers) in can be tackled in extremely small increments (one test at a time in TDD). In larger groups more coordination will be needed. It will be up to each group to find the sweet spot (like how many pants can my drier dry in one wash cycle).

    One thing to keep in mind when adopting a lean approach is there is NO ONE RIGHT WAY. Every situation is different and requires different practices and rules to be optimal. The key is the Perfection principle. Never be satisfied. Always look for ways to make the software better, faster and more valuable to the business. Sometimes you will try ides that cause a step backwards in productivity, but these are a step forward in knowledge. Remember perfection is not achievable, but with lean you should always be seeking it.

    Sunday, June 27, 2010

    Review of "The Shack" by William Young

    I loved this book. It wasn't well written (you are not surprised to find that William is a first time author), but the story and the depth outshines all it's flaws. It is not a easy read. I had to put it down several times as I couldn't take the images in my mind and I cried several times but I laughed even more.

    The story is based around a fictional character, Mack, and his weekend with Elousia (El - semitic for God; ousia ancient Greek for being), Sarayo (Sanskrit for wind), & Jesus. The chapters leading up to the weekend will turn many away as it isn't a pleasant story. Make sure you have a box of tissues in easy reach for chapters 2-4.

    Each chapter has a quote at the head. I liked each one. My favorites are:
    Chapter 4: "Sadness is a wall between two gardens." -Kahlil Gibran
    Chapter 6: "...no matter what God's power may be, the first aspect of God is never that of absolute Master, the Almighty. It is that of of the God who puts himself on our human level and limits himself." -Jacques Ellul
    Chapter 14: "God is a verb" -Buckminster Fuller
    Chapter 18: "Faith never knows where it is being led, But it knows and loves the One who is leading." - Oswald Chambers
    The meat of the book has some great lines as well:
    "Who wants to worship a God who can be fully comprehended...Not much mystery in that."
    "Faith does not grow in the house of certainty."
    "There are a lot of smart people who are able to say a lot of the right things...but they don't know me at all. So really how can their answers be right...?"
    For me this book has take the place of "Mere Christianity" by C.S. Lewis as the best book for an introduction to Christianity. I plan on reading it again.

    Addendum: The reason I read this book was because my father recommended it. He reminded me when we spoke :-)

    Sunday, June 6, 2010

    Measurement 101

    When I got from spring break I noticed that most of my pants were tight and my typically lose pants fit nicely...not a nice feeling! I shouldn't have been surprised I had stopped going to the gym on a consistent basis and I wasn't watching what I ate for long (just the short time it was on my plate :-) The first step was obviously to get back in the habit of going to the gym. After about a week I noticed some pants felt better, but I wasn't happy with the "just try harder" approach. I decided I needed a change in my approach. I got up my courage and took the big step of...getting on a scale. It was not pretty. In fact it was slightly depressing, but I kept doing it every time I was at the gym.

    The point of this post isn't my weight though. It is the about the saying: "If you can't measure it, you can't manage it." I have had an interesting history with measurement. I have always liked numbers. In fact I used to calculate (in my head) the estimated time of arrival (in minutes) to home every time I passed a sign with miles to home. Yes, I know I have issues. When I worked at Motorola they used to publish our software release sigma number. I found out that this number was the number of defects found in the last release divided by the number of lines of count. This was obviously wrong as I could have added NOPs and got that number lower without improving the quality at all. When I consulted with government contractors (almost all where SEI level 3 or higher) I found several measures that were more complicated but in effect similar to Motorola's sigma. When I spoke up about these measures being easily duped and misleading, the response was: what do you suggest we measure instead? Good question...I didn't have an answer. 

    How do you manage if you have no quantitative way of saying you are getting better or worse? The key, I think, is something I was taught my a measurement guru a worked with once (Chris Miller, please forgive me if I butcher this:-). 

    First start with the goal (i.e. improve productivity, quality, waist line). Next find some measures that are good predictors of those goals. Examples: 
    • Goal: medium rare meat - measure: internal temperature as measured by a meat thermometer.
    • Goal: smaller waist line - measure: same scale at the same time of day
    • Goal: software productivity - measure: lines of code (this is worth a whole post, but not this one)
    Be careful not to believe the measures are the goal as this trap will lead to manipulation and a false sense of where you are. Now, look at your process (lots of people use an idealized process...another trap) and see what measures you can capture cheaply. Start capturing (sometimes the historical data is laying around and you can go back in time) and do some simple statistical analysis to see if any of these measures correlate with the goal measures and thus can be your predictive measure. 

    Let me give me an example that most can empathize with. I have a goal of smaller waist line. My goal measure is my weight on the gym scale in the morning (experience has taught me my weight fluctuates widely throughout the day). My predictive measures eluded me until my wife introduced me to SparkPeople (image an intersection between Facebook and Weight Watchers) The web site is fairly painful to use, but the android app is quite good and lets me enter in all the food I eat fairly easily. Now I have a predictive measure that is fairly cheap. Now for the simple statistical analysis.

    We are after correlation coefficient (CORREL in Google Docs Spreadsheet) . Next we square it and display it as a percentage ("The square of the coefficient (or r square) is equal to the percent of the variation in one variable that is related to the variation in the other." from http://www.surveysystem.com/correlation.htm) The smaller the better. In my case it was .1% so I think it's a keeper.

    One trap I fell into, and still do at times, is the old accuracy/precision trap. I have already described this:
    I am sure there is quote out there, but here is my general rule: let the level of precision of a number be based on its accuracy. Accuracy of an estimate is always low so please don't use decimals (precision) If you don't understand, please read this explanation of the difference between precision and accuracy.
    In my case it isn't estimation as much as it math. If you spend hours getting your predictive measure (i.e. calories consumed) you are wasting precious time. Let me give you an example. SparkPeople keeps my calories to 1/10 a calorie, but what if round my calories to the nearest 100....my correlation changes to .02%...yes in actually gets better (its a math trick...given different sets of data it could have gone .08% the other way) but the point is .08% or even .8% isn't worth the time it took to write it. If I round my correlation to the nearest whole percentage they both are 0% or practically perfectly correlated. So don't sweat the small stuff and keep you mind on the goal whether it be fitting into old pants or productivity improvement.

    Monday, September 28, 2009

    Stuff I Have Found Interesting Last Week

    9 Ways Marketing Weasels Will Try to Manipulate You

    People sure are a funny bunch.


    Rich, Black, Flunking

    Fascinating story about a researcher's conclusions and the negative reaction it caused.


    Where The Buffalo Roamed

    I find this interesting. For those to lazy to read the farthest you can get from a McDonalds in the contetental US is 107 miles and can be found in South Dakota.