Illustration by Randy Kaplan and MidJourney. All rights reserved. Do not copy or distribute.
Recently, I read a post on the Internet that said, "You don't need to learn a programming language to write computer programs." This statement stopped me in my tracks. Really? Perhaps this approach worked for the author of the quote but that's hard to believe. After 50+ years of programming and teaching programming, I have my doubts, so I am very skeptical about advice like this.
The title of this story is "Find a Career for a Lifetime." It is my story and therefore it represents my experience with learning and becoming a computer programmer or if you prefer a "software developer." There are many reasons why a career as a programmer can be fulfilling, rewarding, and exciting for as long as you wish. That's the way it is for me. There are also many reasons why this may not be the career for you or maybe you made a good career selection. It is important to reevaluate this decision from time to time.
My purpose is not to "sell" or convince you to select this career as your own. It is about this statement by someone on the Internet who advised that you do not have to learn a programming language to learn to write programs for computers. Based on my perception of the person offering this advice, I would not consider it a justified recommendation. Read on and you will learn why.
Over 4000 programming languages currently exist.
You may not believe this, but several years ago I found a list of 4000+ programming languages. Unfortunately, the site where I found that list doesn't exist now but the very fact that there was such a list shows that there was and still is a lot of interest in developing new programming languages. There are other lists today. (https://en.wikipedia.org/wiki/Lists_of_programming_languages).
From Wikipedia: https://en.wikipedia.org/wiki/Lists_of_programming_languages
With 4000 programming languages, you could spend at least ten lifetimes spending only 90 days learning each of these 4000 languages. By the way, learning a single programming language requires more time than ninety days. I challenge you to try to understand every programming language that exists today.
The idea that 4000 programming languages (4000 at least) could be learned is impressive. Tremendous effort has been put into creating programming languages. When someone says you don't need to know a programming language to program computers, I wonder why so many people would make so many programming languages to create computer programs if it weren’t essential to use a programming language to write computer programs.
If programming languages were not necessary to write programs we could all have gotten along with COBOL or FORTRAN, right? Why bother inventing and developing new languages? Why even bother with Python?
I think there are three or maybe more reasons for more programming languages.
A new programming language is created when someone or some team has a better idea of the way a programming language should be designed.
A new programming is written when a new programming paradigm is discovered or formulated.
A new programming language is designed when someone or some team believes they have a cool idea (as opposed to a better idea).
Advances are made in programming language theory or technology.
Programming languages are so essential to creating software that since the birth of the computer age, the use of languages to create programs has not changed. We still use artificial languages (not to be confused with artificial intelligence) to give instructions to our computers.
If you are the curious type, it might be interesting for you to investigate some of the many programming languages. Doesn't that make you curious about the field of programming? Why could there possibly be 4000 different programming languages?
Choosing programming as a career offers a tremendous opportunity for investigation, exploration, and learning.
What attracted me to computers and programming in the first place was a simple idea. The idea was that by writing a program I could get the computer to do almost anything I wanted it to do.
If I wanted the computer to calculate all the powers of two through 8,000,000 digits, I could do that.
If I wanted to create a simulation of an airport with planes that landed and took off randomly, I could do that.
If I wanted to write a program that would translate English into French and then French into English, I could do that. The possibilities were endless.
I became passionate about learning to program because of the very possibility of what could be done with a computer excited me.
My life as a programmer began when I was thirteen years old. I could write programs for the computer but it remained to be seen if I was now a programmer. There was still a lot I had to learn. When I gained access to one of the behemoth computers, I would spend as much time as I could writing programs, running those programs, correcting (debugging) those programs, and eventually enhancing those programs.
Few "regular" folk knew what it meant to program a computer. It was a very new skill. Computers were quite different in the 1960s. At that time, the typical computer would cost millions of dollars and occupy large building spaces. "The regular folk" did not have access to these machines then. I was lucky to have access to a computer at that time.
The people who programmed computers were considered unique. At one of the big three computer manufacturers at that time, programmers and computer technicians wore laboratory coats.
These people were considered to be magicians. Back then, they were special. Today, not so much.
Sad Emoji because things have changed
Illustration by Randy Kaplan and MidJourney. All rights reserved. Please do not copy or distribute.
Only the people who learned how to write computer programs could access the computers. In middle school, there was only one math teacher who knew anything about computers, and his knowledge was limited. I counted on him to be able to explain things I could not understand. Don't get me wrong; he was helpful, but I had to do most of the learning independently because he was unable to answer all of my questions. When I finally got to high school, I taught my teachers how to write programs in the BASIC programming language.
It was hard for a thirteen-year-old to explain what it meant to write a computer program. Over the years, I became better at explaining. I could distill a set of thoughts into instructions for the computer, I could do the same thing for people. I began to think of myself as a good explainer. What is an explainer?
A great explainer can be a great teacher.
A great explainer is a person who easily connects with people.
Being a teacher does not mean you will be a great explainer.
Great explainers are few and far between. I can count on my fingers the number of teachers I had that were great explainers.
A great explainer is a person who can embed stories and anecdotes into what they are explaining.
A great explainer can make something complex into something simple.
A great explainer can make learning fun and interesting.
Most people who try to explain cannot.
Even those who think they can explain something fail to do so.
You know you explain well when someone who is listening to you smiles or nods. It is not the smile of "Isn't that nice?" It is an internal smile when someone gets it. It is a sign that understanding has awoken in another person's mind.
If you are a programmer, when a program you wrote makes the computer produce the result you want, you have explained a task well.
When a computer does not follow your directions, then you have not explained what you wanted the computer to do very well.
A computer displays displeasure (I am anthropomorphizing a bit here) at your explanations by producing errors, and indicating that some instructions you gave it were incorrectly written.
At other times, when you provide an incorrect explanation in a program, the computer will display an unexpected result or just stop. It is the responsibility of the programmer (YOU) to figure out what is wrong in the program. Debugging is the process of determining what is wrong in a computer program.
In the case of human beings, when you have not explained something well, people will often display boredom, lose attention, or get frustrated or angry. They might frown or show displeasure. People have very expressive faces and body language. Sometimes, people walk away when they don't like something you are saying. A computer reacts differently. A computer cannot disagree per se; it simply can't follow instructions.
A computer can't walk away and doesn't (at least presently) show displeasure or boredom. That's because a computer's response to inadequate explanations can only be expressed in limited ways. We humans are fortunate to have a limited response. Imagine if a computer could show frustration at the people who wrote programs.
When I was young, one of the reasons I became passionate about programming was that a computer could always express the problems it had with my programs. Remember that a program is an explanation of something we wish the computer to do. After a time, the programmer will become familiar with the way that the computer communicates information about what it did not understand. Sometimes a programmer can have intuitions about what might have gone wrong with a program.
After writing more programs, it becomes easier to determine what went wrong in a program.
It is the same thing that a carpenter will learn when a particular project is incorrect.
The computer would display the same error again and again and again until a problem was fixed.
A computer can recognize errors in the instructions written in a program.
When a problem is not corrected in a program the computer will display the same error repeatedly until the problem is fixed.
A colleague and I once wrote a very large program consisting of many parts. The program consisted of thousands of lines of instructions. At times the program would crash. This means that the computer would stop running the program. The stoppage of the program would happen randomly. It was difficult to determine the cause of the crash. Most programs when they fail, will do so in the same exact location among its instructions (at the same instruction in the program).
My colleague and I worked for many days to locate the error in the program. We could not find the place in the program where the program stopped.
Finally, I decided to slowly remove lines of code, a bit at a time. By doing this we could determine what was causing the program to crash because if we removed the program instruction that was causing the problem, the problem should stop occurring. If we replace the instruction that was removed, the problem should reappear.
I kept removing instructions until there were about ten lines of code left in the program. All other instructions in the program were removed. Even when there were ten lines of code left, the program behaved in the same way it had been. It would crash sometimes and not other times. We hadn't found the code that was causing the problem.
The next thing to do was to remove one instruction at a time from the ten remaining instructions.
As before we kept on doing this until the problem stopped occurring. After several tries, we found the instruction causing the problem.
The problem stopped occurring when we removed the particular instruction. We checked to make sure it was the instruction we identified so we replaced the line to see what would happen, and the problem recurred. Once more we removed the instruction and the problem went away. We found the instruction causing the problem. Of course, we couldn't stop there, we had to examine the instructions to determine what was wrong with it.
After examining the instruction, we determined that the instruction was missing an asterisk.
The original instruction was:
FILE f;
The correct instruction was:
FILE *f;
If you know the C programming language then you might understand why this problem occurred and also why the problem kept moving around making it difficult to locate.
The reason that it took so long to identify the problem was that sometimes small errors are not easily found. It is very easy to miss an error like this one. This is especially true if the programmer did not understand the implications of a missing asterisk
If I could figure out why the computer was complaining about what we had done, then eventually, I could fix the problem. Knowing what to do to fix a problem was always a satisfying experience.
Imagine trying to do the same thing with a person. If you do try, I would stand far away from the person you are frustrating. I would stand very far away.
Today, things are different.
Recounting the motivation for writing this article: I saw something written recently that said you did not have to learn a programming language to write computer programs.
My response to this claim is, If we are not familiar with the programming language we used to create a program, I doubt we would have ever located the problem. Therefore the more we know and understand a programming language the better equipped we will be to recognize and correct problems caused by incorrect instructions.
Learning a programming language is a prerequisite to learning how to write programs for a computer. If a person did not learn a programming language then it would be extremely difficult to identify problems in the written instructions.
In my career, I have learned 35 different programming languages. Learning multiple programming languages allows a person to have insights into why some things do and some things don't work when writing program instructions.
Many aspects of programming make it a difficult skill to learn. For example, a programmer must be able to break down any problem into manageable pieces.
People usually think differently than this, although people can learn to break down tasks this way.
Interestingly, breaking down a problem into small, manageable tasks is a life skill. If you are good at breaking down tasks and problems into smaller pieces, you may also be good at programming.
Likewise, if you can break a problem into small, manageable pieces to write a computer program, you can use the same skill to solve real-world problems.
Here's an example of some of the insights that can be learned when programming.
Programmers Mind Brain Illustration by the Author
When I first learned to write computer programs, I was not familiar with most of these important insights. These kinds of rules were never explained to me when I was beginning to learn how to write computer programs. Insights such as these simplify the programming task. I worked with some very experienced programmers in my career. Few of these experts explained any of these important insights. Later, I learned that it is often difficult for people to articulate or explain the things they learn from experience. Today, many of the advances in programming have come from a better understanding and articulation of the programming process. Newerww programming languages are designed all of the time based on new insights into programming.
To explain to a person how to write computer programs, a mentor must understand the tools used for this purpose and be able to explain how these tools are used. An extremely important tool is the programming language used to specify instructions to a computer. If someone has not learned how to use a programming language, they will not easily be able to determine problems that can occur.
Consider for a moment that you wanted to learn French. Would you select a person to teach you French who did not know anything about the French language? Probably not.
While learning a programming language it is extremely useful to learn the idiosyncrasies of the language. Every programming language has idiosyncrasies. Not understanding these idiosyncrasies will make the programming task difficult for the programmer.
The moral of this story is that if someone tells you that you don't need to learn a programming language to write computer programs, don't believe them and find another teacher right away.
You might be tempted to believe the current "hype" that you don't have to learn to program because an AI will write programs for you. You should be aware that an AI's answers to prompts are ONLY based on data that the AI already has. The current state of AIs is solely based on knowledge that was captured from the Internet. Therefore, if there is no data available about a topic, the AI will not be able to answer the prompt. Worse yet, the AI may invent an incorrect or faulty answer. Ask an AI writer to write a program to implement an ERP system. If the AI writer can’t accomplish this task it will tell you or even better give an excuse like “it is too difficult to accomplish that task.”
See if you can find a detailed design document for an ERP-type system on the Internet. Finding such as document will be difficult and perhaps even impossible. For an AI to write the code for something like an ERP such a document must exist and I would guess that more than one of these documents would be necessary.
Key Points
A programming career would be interesting and challenging.
There are many interesting things to learn as a programmer.
It could require a lifetime or several to learn everything that can be learned as a programmer.
If you can imagine a world, then you can write a program to create that world.
IT IS NECESSARY TO KNOW AND UNDERSTAND A PROGRAMMING LANGUAGE TO WRITE PROGRAMS.
Illustration by Randy Kaplan in The Programmer’s Mind Workbook. All rights reserved. Do not copy or reproduce.
Illustration by Randy Kaplan and MidJourney. All rights reserved. Please do not copy or distribute.
Closing Comments
I hope you enjoyed reading this article. I enjoyed writing it. If you did like it please leave a comment. If you can clap for it, please do so. Even better please subscribe to this newsletter. I now am publishing on Substack, Vocal, and Medium. I am in the process of moving all of my articles to these platforms. If you have friends, please pass this article on to them. Have a great day and thanks again for reading.
You can reach me at therenguy@gmail.com. You don't have to join anything or pay anything (right now - maybe eventually).