Automaticity in programming and math

I’ve been learning how to program for a long time, a task that has much in common with mathematics. Both programming and mathematics involve being able to solve problems. Some of the problems in programming and mathematics have well established solutions and other problems do not. On a micro-level, programming involves manipulating code, a task much like the symbolic manipulation often used in mathematics. On a macro-level, programmers and mathematicians both need to be able to trouble-shoot, organize, and communicate their solutions.

Sample code:

When I learned how to program, I taught myself, and I know that as a result, the code I create does not always follow the most appropriate industry standards. I have some unconventional solutions to some of the standard problems in programming, and I have less than optimal solutions for some basic problems in programming. I’ve yet to develop my own library of solutions, a standard practice in the industry.

On the other hand, I’m not a professional programmer. I program to solve problems I run into in life, and I program for fun. I have many programming projects that I’ve started and not completed. I’m an amateur programmer. I don’t need my work to look exactly what professional programmers’ work looks like because I rarely, if ever, share my programming with other people. I often share the results of my programming though, and this has helped build some useful tools for my students.

There are many low-level tasks that I no longer need to reference. I don’t need to look up how to define variables or functions, and I don’t need to look up loops, conditionals, and other basic parts of the structure of the programming languages that I know. I still need to look up the methods and properties of some higher level objects in the programming languages I know though, and when I program in PHP, I have a reference manual for the hundreds of functions available in PHP always open. I could be said to have developed a certain amount of automaticity in learning how to program, especially for the more basic tasks.

This automaticity was not learned by memorizing programming structures. I didn’t develop automaticity by doing practice exercises. I didn’t develop automaticity by reading books on programming. I developed automaticity in the low-level programming tasks by programming, by giving myself projects to work on that required me to build my skill, and by repeatedly looking up reference material when I got stuck. I developed automaticity because it is frustrating to write code that doesn’t work. It’s frustrating to get error messages that are nearly incomprehensible back from the computer when you make a mistake in the structure of your code.

If we look at mathematics education, we see that many, many of the problems given to students which have standard solutions. We expect students to develop fluency in these problems, often before they ever get to see any of the non-standard problems. In fact, in k to 12 education, students can potentially never be given an open-ended non-standard problem. Unfortunately, I believe this approach has failed our students in the past, and I’m not alone.

I’d like to see a system without a focus on fluency and automaticity in mathematics. These are the wrong drivers of mathematics education. Instead of focusing on the lowest level tasks mathematicians do, and assuming that fluency in these tasks leads to mathematical reasoning, we should focus on the most interesting and challenging tasks, and expect that a certain degree of fluency and automaticity will be developed as a result of these tasks. Instead of expecting students to memorize recipes and algorithms, we should allow them to develop toolkits and libraries to use of their own that they can reference as needed. Instead of feeling that every problem students need to do has to be solved quickly or efficiently, we should allow for alternate solutions and methods to be used.