Table of Contents » Chapter 1 : Preliminaries : What (Who) is a Programmer?
What (Who) is a Programmer?
Contents
Overview
Computer programming is a process used to write instructions (commonly called code) for a computer to follow to complete tasks or solve problems. These instructions are written in diverse programming languages, each with its unique syntax and applications, solve a set of steps. The set of steps created to get the solution is called an algorithm. Algorithms serve as blueprints that guide the computer through the necessary steps to achieve a desired outcome (task completion, problem solved, etc.). Given all of this, what does it mean to be a "programmer?" And, who is, or who can be, a programmer? Can you be a programmer?
On the surface, the answer to the questions above may seem obvious; it depends on how strict of a definition we choose. A commonly held definition of a programmer is someone who writes code for a living and has a job title like Computer Programmer, Software Developer, or Software Engineer. What about others? Can a person be a programmer without earning money from it? And if not for income, why would someone invest the time and energy to learn to write code without the end goal of making money from it? It is important to consider these questions because they may help inform your own questions: Why are you studying programming? What is your end goal? Can you be successful in learning and using programming for your purposes? Let's consider some things that might help answer these questions and also try to dispel some myths about programming, especially for those who are not studying Computer Science or STEM or who might be doubting the usefulness of studying programming for themselves.
I have an acquaintance, T, who has a degree in Computer Science. Her job title is Software Engineer (which is an advanced level of the computer programming profession), it is what she does for her employer each day, and the way she earns her living. I think T is a programmer because she fits the commonly held definition suggested above. I have another acquaintance, S, who works at Walmart. Her job there is as an Optical Technician in the Optical Center, and that is how she earns her living. However, to me, S is also a programmer. Why? Because she knows how to write code in a programming language to solve problems. S attended a coding boot camp some years ago independent of her Walmart job. A third acquaintance, D, has a Ph.D. in English and teaches literature at a university. I consider him a programmer as well. He has no formal training in Computer Science or programming, but he learned coding independently because he needed the skills to reach some of his research goals. Lastly, A is another acquaintance who is retired. He also has no formal computer programming education or work background but he took up programming to support his hobby of Model Railroading. I consider all four of these people programmers even though only one has formal programming training and earns a living in that field.
Would you agree that all of these people are "programmers"?
Author, speaker, and programmer Linda Liukas ↗ suggests that "everyone is a programmer." She argues that programming is about solving problems by creating or using algorithms. She reminds us that algorithms are not just used in computing; we use algorithms in everyday life. For example, the steps to tie your shoes are an algorithm (a set of steps). Others include recipes to cook or bake food, the steps you follow to start your car, to order products online, and many other everyday daily tasks. Liukas suggests that because we all encounter tasks and problems that we must complete and solve, we are all programmers.
Would you agree with Linda?
So, can anyone (you) become a programmer? To answer this, I contend that we must first shed the notion that a "programmer" is someone who writes code professionally for their income. Becoming a professional programmer may or may not be your goal, either way, my answer to that question is, yes, anyone (you) can become a programmer. This is analogous to saying anyone can be a musician. That does not necessarily mean everyone who learns to play a musical instrument or sing wants to, or even could, earn their living through music. With the willingness and investment of time practicing, anyone (including you) can be a programmer (or a musician, or anything you choose to pursue).
There are stereotypes surrounding programmers based on myths and misconceptions about the field and those who pursue programming as a profession. Here are a few of them:
- Programmers Are Naturally Good at Math: While math skills can be beneficial, not all programming requires advanced math. Many programming tasks are more about logic and problem-solving skills.
- Programming Is Only for Young People: Programming is an accessible and attainable skill at any age. There is a growing trend of people learning to code later in life.
- Programmers Work Alone: Contrary to the stereotype of the lone coder, most programming today is highly collaborative, involving teamwork and interaction with others.
- Programming Is Just Writing Code: A significant part of a programmer's job involves understanding problems, planning solutions, and collaborating with others, not just writing code.
- You Must Have a Computer Science Degree: While a degree can be helpful, many successful programmers are self-taught or have learned through boot camps and online courses.
- All Programmers Do the Same Thing: There's a wide variety of specializations within programming, from web development to game design to data science.
- Programming Is Boring and Repetitive: Programming can be incredibly creative and diverse, offering the opportunity to work on exciting projects and solve unique problems.
- Programmers Are All Geniuses: While programming requires specific skills, it's more about practice and learning than innate genius. Anyone with dedication can learn to code.
- You Must Be Good at Science: Like math, while science can be beneficial, it's not a prerequisite for becoming a programmer. Many aspects of programming are more about logic and design.
- Programmers Work Excessive Hours: While some jobs may have extended hours, many programming jobs offer flexible schedules and an excellent work-life balance.
I have seen many lists published and posted that suggest specific characteristics a person should (some say "must") have to be a "good" programmer. I hesitate to say or suggest the same. There are characteristics that help succeed in learning programming, which are also attributes that help with day to day life as well. The good news is that any of these can be improved upon as needed.
- Willingness to Continuously Learn: Learning programming is an ongoing endeavor. Technology and coding are ever-evolving fields that lead to continuous opportunities to learn new ideas and expand on one's knowledge and skills.
- Prolem-Solving Skills: Solving problems through logical thinking is the foundation of programming. Like any skill, problem-solving improves with practice. I recommend solving puzzles (like crosswords or Sudoku, for example), playing strategy games, and programming exercises (which are widely available online for free).
- Attention to Detail: Programming involves a high level of accuracy. A small error or oversight in code can lead to failures in one's code and application. To improve attention to detail, take your time with tasks, slow down and pay close attention to details. Rushing through a solution often leads to mistakes. Also, like any form of study, reducing distractions and working in an organized space can help attend to detail as well..
- Persistence: Repetition and frequency are keys to learning any skill. Working through problems and writing code will come more naturally the more you do them. I also recommend adding 10% to everything you do while learning; that is, try adding a bit more to your problem-solving and coding.
- Patience: At some point programming will feel tedious and frustrating. Small mistakes or omissions can prevent your program from working, leading to frustration. Patience is critical in these moments. In these moments, setting the programming aside for a short time and doing something else often helps reduce the frustration and allows me to continue later with reduced stress. Also, like any form of writing, it is often beneficial to seek out someone else to look at it. Fresh eyes often see the problem straight away.
Learning and becoming proficient with any subject is a matter of step-by-step progression. Whether you have some background in the topic, you start with that background (including "none"), and you learn pieces of the subject a bit at a time. As you progress, you approach your proficiency goal one step at a time. As you go, your knowledge of the subject expands. I visualize this progression as a set of lines (you could formalize this and call them intermediate goals). This visualization might look something like this:
Figure 1. indicates that students begin learning a subject at some point, depicted as the first (bold) vertical line. That point is likely different from person to person; one person may have some background or familiarity with the subject, while another may have absolutely none. In either case, each person begins at their starting point, and then, as they study and practice, they move their skill and knowledge forward, crossing lines as they reach milestones in their learning process.
Learning programming fits this model very well. As mentioned previously, programming is about solving problems using a computer, hardware, software, and a programming language to create solutions. This means that the knowledge needed to be a programmer relies on far more than just the syntax of a programming language (another misconception). By the time you have reached this book, you have already acquired some knowledge of computers, hardware and software, the Internet, and possibily some knowledge of programming as well. You have some degree of proficiency with each of those topics ("none" is perfectly acceptable in this case). From that point, as you proceed through this book (combined with the exploration of other materials and practice), you cross lines as you progress.
The rate at which you progress in crossing those lines is personal and individual; it is based on your background knowledge, aptitude, perception of the learning materials, the amount of time you dedicate to studying and practicing, etc. Given this, it is essential to recognize that your progression will differ. The rate you progress and the challenges you face will not be the same as anyone else. For example, a group of students starting a programming course may appear to start at the same point, as depicted in Figure 2.:
Figure 3: Programming Concepts Progress
However, it is more realistic to depict students as seen in Figure 2. Some students may have significant background knowledge in computers, software, programming, etc. (Student 4), while others may have very little background knowledge (Student 2). It is important to realize that both of these students will make progress as they continue to study and practice; they are just starting at a different point. The important factor is that each student makes progress and crosses lines at their own pace.) It's also essential for students not to compare their progress to others.
Figure 2: Students of programming progress at different rates.
I have taught programming to hundreds of people in workshops, corporate training sessions in industry, and college classrooms. I'll let you in on a little secret — the biggest mistake I see students (and employed programmers) make is that they go straight to writing code and focus all their attention on getting the syntax of their code "right" instead of understanding the problem and the concepts to solve the problem first. Unfortunately, a lot of programming instruction supports this mistake by placing the majority of the pedagogical focus on syntax in their assignments. This approach is a mistake because anyone can get perfectly functional code these days simply by searching Google, Stack Overflow, or using AI tools like ChatGPT or CoPilot. But, if you don't understand the problem, you will likely produce code that functions fine but doesn't solve the problem. You can find the code examples (the syntax), copy them, and run them to find something functional. However, if it doesn't solve the problem, then, not only have you not really learned much about solving that particular problem, you're not fulfilling the requirements. This is where Concepts First, Syntax Second comes in.
Let's consider a scenario...
A student, Bob, is in his Python for Beginners class, and the next assignment says the following:
Write a program that performs a binary search on the following list:
["Joe", "Bob", "Sid", "Liz", "Rob", "Eli", "Ben", "Rex", "Jay", "Cal"]This example may seem contrived and unlikely, but it happens frequently in programming classes. The pressure for good grades, limited time, and a dose of procrastination leads to this scenario quite often. Yes, grades are important, but the downside is that Bob really has no actual understanding or concept of how to solve this programming task, how to translate the problem into code, how to produce the code he copied code, how it actually works, how it relates to the real-world, and most importantly, cannot reproduce this solution on an exam or in a job interview without the crutch of a tool like ChatGPT. What is another way of approaching this scenario?
The first piece of advice I would give Bob is to slow down. That may sound counter-intuitive because time is always at a premium, but putting concepts first requires time investment up front, before any code is written (or searched for). How might Bob approach this problem without using an online search or asking a chatbot first? He should relate the problem to something tangible to associate the assignment prompt with something real. The assignment provides a list of names to search. What is this analogous to in the real world? A real-world conceptual example would be looking for a word in a dictionary. Dictionaries are in alphabetical order and when you need to find a word how do we usually find the word we're looking for? The common approach would be to open the dictionary to some arbitrary page approximately in the middle and look at the words on that page. Because we know the alphabet we can determine if the word we are looking for is earlier in the dictionary or later in the dictionary. Then we decide if we need to continue searching in the firat part of the dictionary or the second part. We then repeat these splitting and checking steps until we find the word.
Bob may not have thought of all of these things himself, that's where research (reading, books, blogs, videos, class, etc.) comes in to help him learn and understand the concepts before using a tool to generate code for him. This is not to say that a person learning programming should not use the tools available to help them learn. I am all for using any tool that will help in that endeavor. It is when tools are used in place of actually learning the concepts that will allow a person to find a solution and fully understand it simultaneously.
If you knew nothing about programming before you started this book and read these first few pages, then you have already crossed a line. If you already have some programming background, and have read these first few pages, you have crossed a line too. In both cases, you either know more about programming, or have begun adding to your knowledge, than you did before you started this book. In either case, you decided to venture into this book (class), and there is likely already something you did not know before or had not heard the same way before. This is why I openly deny that this book is the best, the only, or most comprehensive about programming or Python. It's not and I argue that no book can truly claim any of those monikers. Programming itself is too vast a topic for any book to cover everything so I recommend exploring as many books, blogs, videos, etc. about programming and Python you have time for as you learn. All of them will help you cross lines in your progression.