Swimming with Asian Sharks - Business Secrets from the Pacific Rim

How to Solve Problems like a Programmer

Sears was a very interesting project because it taught me that I was already a very good consultant; I was actually so quick on Sears Mobile that they gave me two other projects on which to work during my time.  The first project was Home Depot, which I finished in about a week, and then the second project was Sears Main, the main Sears site. To meet their deadline, Sears got us to come over; I ended up working at Sears for a couple of days and improving its process. I taught Sears how to use “Jing,” (http://www.techsmith.com/jing.html) a tool that Mr. PrintMan showed me, and I also showed it how to find broken characters; there were tons for some strange reason when Sears was converting its old site into its new site format and there were broken pages. Sears didn’t know why, and I helped the company find out that the pages were broken and that there were characters on the page that could not be rendered. I showed the company a technique for eliminating them 50% of the time. This is a programming technique and I also apply it to real life, but whenever you come across a problem or you’re not sure what the problem is, you eliminate 50% of the code or the problem and then you look at which half. If the problem still exists, then it’s still within the 50% and then you have to do it one more time until you find the piece of code that’s actually broken. This is actually a very fast way; it’s basically binary search, essentially the fastest search. In programming, when you have a list of elements that already are sorted, the fast way to look through them is to use something called binary search, which is remarkably fast:  Binary search is a computer science searching technique. First you must have a list of items that already are sorted; for example, a contact list. If you need to find a person’s name, you could go item by item down the list until you arrive at the name. This could take a really long time if the list was extremely long. The binary search approach would be to split the list into two pieces. You look at the top name of both lists, and you decide which half contains the name you are seeking. Let's say the name is Tom, and after you split the list in half, the first half of the list begins with Alan, and the second half begins with Jack. You know now that Tom lies in the second half of the list because you know the contacts are sorted. Next, you divide the Jack list in half. You look at the two new halves, and see that Jack is on the first list, and Victor is in the second half. You now know that Tom is in the smaller Jack list. You keep dividing the list in half until you land at Tom. For a list of about a million people, you can arrive at Tom in about 16 divisions of the list. That is why binary search is so fast, as long as the list is sorted. 

In real life, whenever you have a problem, to solve it once and for all, you must identify its source or root cause. To do this, you can also apply binary search. First, you list out steps in the process. For example, if you are baking a bunch of pies, and you find that the first pie is bitter, you want to know what caused the bitterness. Is it the flour, too little sugar, the pan, or the butter? Pie baking usually follows a sorted list of steps. The way binary search works as a fast way to identify the problem would be to divide the steps in half. You do the first half of the steps, and you taste the pie. Is it bitter? No, then you know immediately that the problem is in the second half of the recipe. In the case of a pie, you would do the next quarter of the recipe. If it's bitter, then you know it's within the tinier subset of ingredients or steps that caused the bitterness. This beats tasting every ingredient and tasting the pie at every step of the process because that would mean tasting the pie many more times than splitting the problem into halves.