The Chainstore Paradox, Blink, and Think

As I was reading up on the Chainstore Paradox I came across an interesting point on the economy of decision effort which classified decision making effort into 3 levels

  1. Routine
  2. Imagination
  3. Reasoning

At the Routine level decision making is requires little effort as decisions are typically arrived at by default in this situation. At the Imagination level the decision making requires more effort and the ability to see oneself in the opponents position, it is here that the majority of decision making in business is made due to the additional costs of moving to the next level of decision making, Reasoning. Interestingly moving from the imagination level to the reasoning level may not yield better results, especially if the computational complexity introduced is prone to error or bias.

Determining at what level to make a decision is a real skill. I have read a couple of contrasting books on this subject, Blink by Malcolm Gladwell and Think by Michael LeGault. It is the decision, whether to approach a decision with the intuitive thinking promoted by Gladwell or the critical thinking promoted by LeGault, that is of interest to me. In the end I guess it comes down to situational factors, what is the timeframe for the decision, the relative costs, and ability to change a decision when more information is known.

On Interviewing

“If you believe that pleasant interviewing skills, a good handshake or the right outfit are a better predictor of future performance than what the person has actually shipped in the past, I think it’s worth pointing out that you’re nuts.” – Seth Godin

Well interview season is coming up for me as I look for an internship this summer. One thing I’ve learnt from my HR class last semester was that behavioral interviews were one of the most accurate way of assessing future performance. So I’ve been busy practicing to be a good interviewee, it’s a different mindset than I had approaching it from the other side of the table as a hiring manager!

Supplemental Reading #1 Linchpin

When I was younger I was given some advice about running a business, if someone became indispensable then you should fire them. At the time I thought this sounded counter-intuitive and didn’t understand why someone would advocate such a tactic, it didn’t make sense to me, surely you would want to get the most value from your employees for your business? After reading Seth’s book, Linchpin, I recognized the risk reducing tactic in the stories that are shared of how people fear standing out and avoid risk.

Seth’s book is an interesting read, I’ve read several books that focus on the “tactics” of success but Linchpin is one that explains why we so often fail to implement the great tactics we learn. The book covers a lot of ground but is a really engaging read. Becoming a linchpin carries it’s own risk but for me risk and reward are intertwined, if we aren’t willing to take risks in our life then we become part of the middle ground, unable to make a substantive difference in the world around us. It’s an interesting book with some great insights and interesting stories.

Random π

The ridiculous fish blog recently posted an entry about using “random” large integers to calculate π. That post was in the context of getting blog commentators to enter two large integer values as a kind of CAPTCHA to keep out spammers automated commenting bots. The idea of calculating pi using just random sequences of integers was intriguing to me so I set about implementing it in JavaScript. I’ve included the functions used below:

First a fairly simple function that returns a random positive integer:

function randomPositiveInteger()
   return Math.round(Math.random() * (Math.pow(2, 31)-1));

Next a JavaScript implementation of the binary greatest common denominator algorithm followed by a simple coprime function that takes two positive integers and determines if they are coprime or not (by determining if the gcd is 1):

function gcd(u, v)
   var k = 0;
   while ((u & 1) == 0  &&  (v & 1) == 0)
      u >>= 1;
      v >>= 1;
      if ((u & 1) == 0)
         u >>= 1;
      else if ((v & 1) == 0)
         v >>= 1;
      else if (u >= v)
         u = (u-v) >> 1;
         v = (v-u) >> 1;
   } while (u > 0);
   return v << k;

function isCoprime(a, b)
   return gcd(a,b) == 1;

Finally the function that ties it all together; Note the assignment of properties to the function object so that the function can maintain a history of results without having to store variables outside its scope:

function nextPiEstimate()
   /* Initialise the properties used to hold the tallies if required. */
   if (nextPiEstimate.totalCoprimePairs == null)
      nextPiEstimate.totalCoprimePairs = 0;
   if (nextPiEstimate.totalPairs == null)
      nextPiEstimate.totalPairs = 0;

   /* Generate two random integers */
   var a = randomPositiveInteger();
   var b = randomPositiveInteger();

   /* Determine if we are dealing with a coprime pair or not */
   if (isCoprime(a,b))

   /* Determine the percentage of pairs that were prime and calculate Pi */
   var invertedPercentage = nextPiEstimate.totalPairs / nextPiEstimate.totalCoprimePairs;
   var pi = Math.sqrt(invertedPercentage * 6);

   return pi

See the code in action

JavaScript & Java; Object-Orientated vs. Class-Orientated

A software developer can sometimes choose the language they use to program with, but often the decision is already made. When developing software using a language a developer is not familiar with they can go one of two ways, either learn the new language with its accompanying paradigms and idioms or seek to leverage their current programming style into the new language.

In many cases the transition between them is not especially difficult, Java and C# are reasonably close cousins for example, and a competent programmer can switch between them without much cognitive dissonance. Sometimes the distance between the two paradigms is substantial.

When I think of the conceptual differences between languages I am often reminded of Java and JavaScript (recently christened the “worst invention ever“). Owing to its name and curly braces style JavaScript is often though of as very similar to Java, at least by people who’ve never programmed seriously with it. When these developers do begin using JavaScript for serious work they soon stumble into the differences. We then come back to the learn or adapt choice.

“Leveraging their current programming style”, the word “Leveraging” comes from the word “Lever” which can be described as a bar or rod used in combination with a pivot point to transmit force. The goal of a software development is what’s at the other end of the lever. How we choose to apply the force, or our time and mental energy, to reach out goals is my area of interest. Leveraging our existing knowledge to achieve our goals is often a good idea, we learn a lot on the way to becoming the kind of developers we are after all. Discarding that and starting from scratch on each development is not a pragmatic approach. Another aspect of pragmatism however is recognising when our existing experience and skills are not currently a good match for the current problem domain. When our skills are a bad fit we can go through a lot of motion to “force” the fit. An example of this is when people try to make JavaScript into a class orientated programming language (aka a conventional OO language).

Coming from a background in Java, I’ve spent many hours trying to figure out how to make JavaScript objects act more like Java objects in every way. – Nicholas C. Zakas

Should we really be spending many hours trying to work against a language? While I am sure Nicholas is an accomplished developer I don’t believe his approach to JavaScript is the most effective. Concentrating your efforts on overcoming the perceived weaknesses of a language by coercing it to act like another language is not a productive use of time. Seeking to more fully understand that language and its underlying paradigms is a more productive use.

“Embracing the new style”, this alternate approach is also about leverage, however what we are leveraging here is not our current capabilities, but our capacity to improve our current capabilities. As well as the goal of achieving our development target we should also be focused on achieving our longer term targets. One of my longer term targets is to improve my software development skills. One way to do this is to continually improve our current knowledge, reinforce it with experience and expand it with learning and experimentation.

Knowing other systems and paradigms expands the world inside your brain. – Yukihiro Matsumoto.

As with all decisions we make there are tradeoffs, when considering the lever we choose to apply we need to weigh up the effort required to achieve the desired result. Remember there are always external constraints, such as deadlines for example! Remember though that the greater up front effort often has a better payoff in the end. In Steven R Covey speak “Sharpening the Saw” may have more overhead initially but subsequent productivity is increased. As far as JavaScript is concerned cast off any misplaced prejudices and come toappreciate that most misunderstood of languages called JavaScript, be prepared for an interesting world of closures and prototypical objects, and oh yeah you can use a string in a switch statement!

Some related reading:

  1. Emphasising the Role of the “Object” in Object Orientated Design.
  2. Evolution of a Haskell Programmer

Launched a new link blog

After a lapse in writing (due to my failure to roll my own blogging engine in my spare time) I’ve given in and started to use blogger as a link blog. This site will remain the source of my longer musings while my new site, Ben Meadowcroft, Link Blog, will contain all the interesting links I’ve wanted to blog about but never had the time to manually add.

The new blog comes with a ready made atom syndication feed so feel free to subscribe to that (I currently recommend SharpReader as my feed reader).

New release of my popular CSS templates

The most consistently popular section of my site is the CSS templates [zip file] that I provide, as such I have spent a bit of time on the templates and given them an overhaul. There is some nice use of semi-transparent backgrounds and user scalable font-sizing on show (using the browsers own controls!).

screenshot of one of the templates

The CSS template is now licensed under a creative commons license specifically the Attribution-NonCommercial-ShareAlike license. Only the templates (HTML, CSS and graphics) have been licensed under this creative commons license, the rest of the content of this site remains under my copyright. Note that for the attribution purposes of the license retaining a comment in the source code is sufficient attribution. If you distribute the graphics desperately then please attribute them appropriately.

If you have any comments on the templates, or wish to license them for commercial use, please contact me.