# (guest@joequery.me)~ $| # A note to beginner programmers: Programming is Teaching I "formally" entered the informal coding education field almost two years ago. Before I began teaching at local programming schools, such as CoderVox and Austin Coding Academy, I spent a substantial amount of time writing articles and making YouTube videos. I typically covered concepts I previously had a hard time understanding, like pointers and recursion. The creation of this content was inspired by my own frustration. Computer Science education is proudly apathetic to those who initially lack intuition for the subject matter. I firmly believe that intuition should be treated as an advantage, not as a prerequisite. During my time at these local coding schools, I had the privilege of interacting with students from extremely diverse backgrounds. And while the students had many different motivations and end-goals, they shared a common goal each time they stepped into the classroom: understand. As with any subject, certain students grasped the material quickly while other students struggled. While I care deeply for all of my students, the students quick to comprehend the material did not occupy my thoughts nearly as much as the students who struggled. I could give the acquisitive students supplemental exercises and trust they would learn the material required to complete the exercises on their own. The students who did not understand the concepts were the cases I found extremely interesting. In my quest to help these students understand fundamental concepts like arrays and functions, I began to observe the striking similarities between teaching programming and programming itself. ## The 3 most important questions I assert that there are 3 basic questions that stand out from the hundreds of internal questions a programmer's mind bombards itself with through the course of a standard work day: 1. What is the goal? 2. How can we reach the goal? 3. How do we know when we've reached the goal? These broad, basic questions help produce the more specific questions that guide the design of a program. We can apply this line of questioning to a general problem as well as its subproblems. These simple questions can provide structure to our thought process, increasing the chance we find a solution to the problem at hand. The 3 questions mentioned above not only form the basis of structured programmatic thinking, these questions also form the foundation of lesson planning for instructors. ### 1. What is the goal? When creating a lesson plan, instructors must determine what students should be able to accomplish by the end of the lesson. This is formally known as an objective. ### 2. How can we reach the goal? This is where the instructor reaches into their toolkit and determines what examples, models, diagrams, visual aids, etc, would best fit the lesson. ### 3. How do we know when we've reached the goal? An assessment administered at the end of the lecture informs the instructor if the objective was met. This is how instructors test their work. For each unit in the curriculum, there is a test to determine if the objectives of the unit were met. ## It's all problem solving Programming, plumbing, designing, writing, woodworking, car repair, and so on are all instances of the same idea - problem solving. An electrician uses problem solving to diagnose issues with power. A copywriter uses problem solving to determine if the copy addresses the needs of their client. A teacher uses problem solving to teach problem solving. This is one reason why I find teaching so fascinating. ### Programmers teach computers how to solve problems Programs consist of sequences of instructions for a computer to execute. This, as the word implies, makes the programmer the instructor of that program. Characteristics exhibited by the typical instructor-pupil relationship can be observed between a programmer and their computer. No matter how simple the program, the programmer is tasked with teaching the computer how to perform a task (and how to perform it well). ## Programming is hard because teaching is hard Teaching a skill is its own skill. Being extremely proficient at a skill does not guarantee you will be a good instructor. Many extremely talented programmers have not developed self-awareness of their own knowledge, preventing them from understanding the challenges beginner programmers face. Consider the analogous scenario of explaining directions to a lost stranger: When I first visited the US I was surprised to realize that whenever I asked for directions the person who gave the instructions ended with "You can't miss it." In most cases, I missed. If so, what do people mean by "you can't miss it"? Only this: "I can't understand the problem. As someone who is familiar with the way, I don't see why it's difficult" — Why teaching is difficult (PDF Link) As a fun example of how knowing something doesn't imply the ability to teach it, here's a clip of Katie Holmes attempting to teach Ellen DeGeneres how to tap dance (Skip to 50s): In our minds, teaching a skill we already have seems simple, but reality disagrees. From day 1, programming instructors should demonstrate the large disconnect between one's ability to do and one's ability to explain. An exercise to make this disconnect apparent to new programmers is to have them create instructions for common tasks, such as Live demonstrating the potential ambiguities of their instructions can help create a frame of reference for the challenges ahead. ### Computers know nothing Similar to how the author of the quote above had no context for navigating their new neighborhood in the US, computers have no context for the tasks we want them to perform. Consequently, we have to explain even the most basic of concepts to computers in such meticulous detail. ### Translating idioms is challenging As a programmer, not only do we have to provide extremely detailed instructions for how to complete a task, we must do so in a language that is not our native language. We have to translate ideas into the idioms of our programming language of choice. Precisely explaining ourselves in our native language is hard enough! What is an idiom? To quote wikipedia: [An idiom] is a phrase or a fixed expression that has a figurative, or sometimes literal, meaning. Examples of English idioms include: For example, the idea of "Did the user provide their last name in the form they just submitted" may look like the following when translated to the idioms of PHP: <?php if(isset($_POST['last_name'])){
// last name was provided
}
else{
// last name was not provided
}

?>


So "Did the user provide their last name in the form?" had to be translated to "if the isset function returns true when passed the value matching the key 'last_name' in the \$_POST associative array" in order for PHP to accomplish the desired task. The overall translation process requires multiple layers of translating individual idioms, which itself requires extensive knowledge of programming vocabulary. This translation process requires extensive practice before one become fluent, similar to speaking a new language.

Vocabulary and idioms can be learned with time and effort. Unfortunately, many introductory programming resources do not emphasize the importance of learning vocabulary and idioms, often contributing to a very shallow understanding of programming concepts.