Computational Thinking

programming = language + process

Successful programmers know more than a computer language. They also know how to think about solving problems. They use "computational thinking": breaking a problem down into segments that lend themselves to technical solutions. Programming isn't a linear process; it's iterative. Good programmers define the problem, attempt a solution, discover their assumptions are wrong, fix the problem, attempt another solution, and re-define the problem until they have the solution they want.

Yet, much of computer education is focused on learning syntax; simply teaching the structure of an if-then-else statement. Sure - syntax is important, but all the correct syntax in the world isn't going to self-assemble into the algorithm necessary to solve a problem. That's the programmer's job.

I've influenced a sizable number of Computer Science Students and Professionals. My job as the Content Manager for the Developer Segment at lynda.com has provided me with a soapbox from which to prognosticate on the future of computing - and what skills will be necessary to participate in that field. I'm responsible for bringing courses and authors to the lynda.com library and in the process, influencing what my audience perceives to be important.

The skill I believe to be most important is the process of programming, and how it is more important than syntax. You can see my soapbox position manifested in the collection released last year as Code Clinic . I enlisted six programmers to use their favorite language to solve six problems: big data, image analysis, the classic Eight Queens, recursion, building a web page and building a musical instrument. These courses are about programming process - rather than programming syntax.

Learning to fail

I knew some of the Code Clinic problems would be impossible. For instance, using PHP to handle the real-time interaction required by a musical instrument is not feasible. But success wasn't the goal. The goal was to learn to fail - then restart. Thomas A. Edison said it best; "I have not failed. I've just found 10000 ways that won't work."

The task of a programmer is to fail quickly, recognize the failure point, then fix it. This process is commonly referred to as "debugging" - some groups estimate it is 50% of the development process. Debugging is every bit as important as syntax.

In Code Clinic, I encourage our programmers to discuss their failures, how they discovered the problem, approaches they tried and what attempts led to success. Some time is spent discussing libraries and syntax - but a large part of the course revolves around the idea of implementing a solution.

Teaching debugging techniques or quality assurance isn't popular, and teaching the importance of failure is hopelessly abstract. Language syntax is concrete and therefore much easier to teach - so traditionally, that's what gets taught.

Code Clinic is a step outside of that concrete box. I'm hoping viewers will appreciate the complexity of the programming task and take heart the next time they are mired in a non-working solution. That's my goal with Code Clinic and will continue to be a focus of the courses I bring to the lynda.com library.