Thinking Like a Programmer

A large goal of this program is to give you practice thinking  like a computer programmer. Longtime programmers will often talk about  how the programming thought process has helped them in other areas of  their life, but what does it mean to "think like a programmer?" In this  program we will focus on five specific ways of thinking that all  programmers have to use all the time. . 

1. Procedural Thinking

Procedural thinking involves creating perfectly clear  and unambiguous instructions for a computer to follow. It may be easy to tell a person how to sort a deck of cards, but  getting a computer to do that requires more thought. But once you've  learned to think this way you'll find that computers can do it much faster. 

2. Abstract Thinking

Abstract thinking means finding similarity, or as programmers would say, generality amongst seemingly different things.  It  would be impractical for a programmer to specifically program each of  these pages individually. 

3. Systems Thinking

Systems thinking happens when you break a big problem down into  smaller pieces. Programmers do this when they create a plan (often on  paper) for how a program will work. It involves big-picture thinking and  decision-making about a problem and how different pieces of a program  can work together to solve it. If this is unclear now, don't worry!  

4. Technological Empathy

"Technological empathy" comes in many forms. For example, computer  empathy is the ability to understand what a computer is, how it works,  and what it's good and bad at doing. A computer is a tool, as are the programs we use and the programming  languages used to write them. It's almost impossible to program anything  substantial without a basic understanding of how these tools work. 

5. Debugging

Debugging is a systematic process of relentlessly identifying the cause of a computer program that doesn't work.  When a program doesn't work, it's because there is a mistake (also  known as a "bug") somewhere in the computer code. Since these mistakes  are an unavoidable part of programming, every good programmer has a  system for fixing them and that system usually looks something like  this:   

1. Collect evidence (what makes this program fail?)
2. Generate theories (what may have caused this problem?)
3. Test those theories (if my theory is correct, how could I find out?)
4. Fix the problem