What do Mark Zuckerberg, Jeff Bezos, and Larry Page all have in common?
Yes, they’ve founded multi-billion dollar businesses with virtually no formal business training, with combined revenues of over $80 billion. But they are also former software engineers and hackers, an experience that undoubtedly taught them skills in critical thinking and problem solving. Making savvy business decisions is not only about engineering, but also sales and marketing, business development, recruiting, and all the other functions of business. (Bezos had experience working as a quant investor at hedge fund DE Shaw prior to founding Amazon, but his duties had little to do with entrepreneurship or operations). I argue that their programming backgrounds was critical to their success in these other areas as well.
I haven’t been an active coder since I was in my late 20s, but there’s no question that my experience learning how to code when I was 12 and teaching children and adults how to program has changed the way I think about every aspect of my life. I developed an obsession with research and formal process documentation in investing, entrepreneurship, education, and even in my personal life, which all derive from that formative intellectual training.
Justin James, lead architect for Conigent, notes that great programmers understand not only what their code does, but also how and why. Programming is effectively high-level problem solving.
Writing code, however, is no easy feat. Compilers (which are responsible for translating the programmer’s code into machine language) don’t tolerate the ambiguity and imprecision of everyday speech. The challenge for programmers, then, is specifying requests in such a way that the compiler, and ultimately the central processing unit, will understand them. If a programmer can explain problems in a way that a computer can understand them, those problems are already effectively solved, because the programmer has figured out how to do it. Problems may not always appear computational, but a skilled programmer nevertheless finds ways to solve them computationally.
Programmers formalize, quantify, and solve problems (primarily with the aid of a computer) using algorithms, or finite sets of well-defined instructions which, when followed exactly and applied to a relevant problem, produce guaranteed results. With the exception of a small number of well-documented problems in computability theory (e.g., the halting problem), algorithms are theoretically capable of solving any computational problem. Not all algorithms can be carried out in a reasonable amount of time, but a great many can.
It should be no surprise, then, that leaders who bring their programming experience and algorithmic thinking to business have reshaped the playing field. After all, in the eyes of an algorithmic thinker, solving problems based on intuition, opinions, and unsystematic analysis of data is not an option. The algorithmic thinker will find a better solution and eat his or her less savvy competitor’s lunch.
A skeptical reader might be thinking that algorithmic problem solving is abstract and unnecessary—that such an approach is “overthinking it.” I definitely heard that response when I applied algorithmic thinking to finding a spouse. But they would be missing the point. Failing to use the right algorithm is far more costly than taking the time to come up with the optimal solution.
Consider a task in which students are asked to sort a list of 100 integers with no specified range of values. Many would undoubtedly start by finding the smallest number and putting it at the front, then finding the next smallest number out of the remaining 99 integers, and so on. This method is called selection sort. A clever student, however, might realize that she could divide the list into 100 single-integer lists, then compare each adjacent list to create 50 sorted two-integer lists, and so on. By the time the student has merged up to a single 100-integer list, it would be fully sorted. This method is called merge sort.
The first algorithm requires both a maximum and minimum of 4,950 comparisons, while the second requires a maximum of about 450 comparisons and a minimum of about 275. To put the difference in practical terms, if each comparison took one minute, merge sort could accomplish in 7.5 hours what it would take selection sort over 3.4 days to do. Good algorithms make a big difference, and merge sort isn’t even necessarily the best or most sophisticated sorting algorithm. Algorithms may sound abstract, but they are used to solve problems we face on a daily basis (sorting the mail, scheduling, and deciding on the most efficient path from point A to point B, for example).
Put simply, algorithmic thinking is breaking down a problem and constructing a set of well-defined steps to solve it. In practice, this involves rigorous testing, documentation, analysis, and procedures. The problem of solving problems is not itself well enough specified to be solved with a formal algorithm, but I’ve listed the basic steps that an algorithmic thinker takes in tackling a problem:
1. Analyze the problem and define it tightly. What are you trying to find or optimize? What information is available to do so? Are there any constraints? Elegant code is simple code, and simple code removes anything not conducive to meeting the why of the user. E.g., what concrete tools should I use to recruit great technical talent? How do I find a great startup idea? How do stay fit while working an office job?
2. Break the problem down into components (also necessary for finding the brute force solution). What specific set of steps is required to comprehensively solve the problem? Solving a simplified example can be a useful exercise at this point.
