Bold Choices

One of my favorite adverts from 2011 is the Bold Choice advert for Jim Beam. I was reminded of this advert as I am facing some career choices of my own at the moment. The message that “the choices we make, and the ones we don’t, become you” certainly hits home when contemplating a dramatic change. When making these changes we look to the future and try to see what impact the choices will make on our lives.

One of the questions I have often been asked in interviews and during reviews revolves around this idea of seeing yourself in the future: “where do you see yourself in 5 years?” For me knowing the answer to this question has always been a bit vague, personally I don’t find motivation in considering what destination I may achieve after 5 years but what experiences I’ll gain and what impact I’ll be able to make over the next 5 years.

Why not focus on the journey and not the destination?

It’s all about delivering value to customers

I watched a great video today of customer talking about one of the products that I worked on at Mobysoft. One of the things I loved about working at an entrepreneurial company like Mobysoft, and now at a customer-obsessed company like, is delivering products and services that make a real difference for customers. Knowing that I am delivering value to a customer makes all the work worthwhile.

Here’s the video [1 min, 30 seconds] of Matthew Gardiner, Chief Executive of Trafford Housing Trust talking about working with Mobsyoft and the RentSense product.

In closing here’s a quote from Sam Walton, another visionary who understood the importance of serving customers:

There is only one boss. The customer.
And he can fire everybody in the company from the chairman on down,
simply by spending his money somewhere else.
—Sam Walton

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