3. Refine your basic solution. Are there any patterns in the brute force algorithm? Are some steps reformulations of other steps or already-solved problems?
4. Recurse these initial steps to the subproblems. Apply steps 1-3 to the steps/subproblems identified in step 3.
5. Implement each subproblem solution. Along the way, it’s important you design your process for repeatability. In a coding context, that means using standard best practices like defining terms (naming variables in a way that makes sense to another reader), adding explanatory notes (commenting), and formatting properly (spacing). More on that below.
6. Test each subproblem solution. Be sure to check boundary cases. Separating code into modules and rigorously testing each allows the programmer to localize errors so that instead of having to search the entire program, he or she need only search one small section. This general principle applies to pretty much any complex system.
7. Critically assess inefficiencies and iteratively improve solutions. Programming often involves returning to one’s work to make further optimizations or adjustments—ie, never being satisfied. , for example, the name of one of the most famous and elegant algorithms in computer science, was the product of decades of iterative improvements by multiple academics. The Lean Startup movement draws from this same philosophy.
8. Once all subproblem solutions have been implemented, tested, and refined, do the same for the overall solution.
How would you modify this rough pseudo-algorithm for solving problems?
While not discrete steps, two best practices are also critical for effective algorithmic problem solving:
1. Document process and results. An example of documentation is the use of metadata, defined by Frank Dilorio’s guide as “data about data and the processes that support the creation of data and related output.” Dilorio notes that designing metadata is “part fine art” and “part black art,” meaning that programmers need both an aesthetic sense and programmer intuition. To be sure, inserting metadata is extra work in the short run, but in the long run it’s a Quadrant II activity which makes your work much more useable.
2. Set up the process for long-term, unmanned use. A final characteristic of great programmers is the ability to sacrifice short-term convenience for the sake of sustainable longevity. Programming that takes easy shortcuts for the sake of expediency (e.g. non-intuitive variable naming or inefficient use of libraries) leads to unscalable, problem-ridden code. First-class programmers create with an eye for the long-term consequences of what they develop. The ability to control impulses and delay gratification is a relatively stable and important trait.
A well-known study found that children who are able to resist the temptation to eat a marshmallow for 20 minutes in order to receive a second marshmallow turn out to be better psychologically adjusted, more dependable, and to score higher on the SAT years later than children who eat the marshmallow right away. Fortunately, it is possible to improve self-control simply by thinking about the world in a more global, abstract, and high-level way.
Given the efficacy and broad applicability of algorithmic thinking, I think it should have a place in the standard academic curriculum. Here’s a proof: it’s common for employers and VCs in some of the industries with the highest recruiting standards (software, strategy consulting, finance) to hire/back people who have degrees in disciplines like philosophy, physics, and electrical engineering. This is surprising since those professions have virtually nothing to do with those intellectual disciplines.
The reason employers do this is that certain disciplines like those listed provide training in algorithmic thinking, and employers/VCs assume that if you can master those disciplines you’ll be able to master the skills to work in the specific functions for which they’re recruiting. The four highest-paying degrees in 2012 are engineering, computer science, physics, and mathematics. The marketplace clearly values them, even though relatively few students with degrees in physics or math actually work in a job that requires only those skills.
As Prof. Cathy Davidson of Duke points out, our current gold standard for large-scale testing, multiple-choice tests, was invented in 1914 on the model of the assembly line. Its creator characterized it as a way of assessing lower-order thinking. Indeed, multiple-choice tests reward rote learning.
Why not ask algorithms questions instead wherever possible? An algorithm is right if it works and wrong if it doesn’t, with better algorithms having shorter run times. Algorithmic thinking is process-oriented and exhaustive. It forces students to think meaningfully about problems: they must deconstruct the logical structure of the problem, consider every contingency, and come up with a solution. Because there is rarely a single right answer, students are always creatively engaged in finding more and better solutions. Best of all, algorithms are easy to teach. Michelle Levesque of the Mozilla Foundation, has even started testing out a few strategies to do this.
What else in your life is computable?
Thanks to Matt Joyce for help researching and drafting this, and Joan Xie for initial research.
