In 1988, I went to school at Technisch Lyceum Eindhoven. I studied electrical engineering and there was one thing I particularly loved: Drawing electrical schemes. Armed with my Rotring ink pen, I usually got good grades for my drawings.
But one day I got a 5 minus, which is below average in the Netherlands. Why? The drawing was perfect!
You are looking at an electrical scheme for a doorbell. And yes, it was drawn very elegantly. It only had one problem. This bell always rings, until you press the button. It turns out, the drawing was not perfect. I was so occupied with drawing perfect lines and symbols, I overlooked this fundamental problem. I was much better at drawing than I was at checking my work.
I thought the bad grade was unfair but it taught me the first lesson that became very important later on in my career:
Your work can be a piece of art, but if it does not work, nobody will ever use it.
After my first year, I switched to computer science and at first, when things went wrong, there was always a teacher around to fix our buggy code. But one day one teacher said: "Soon, you students will start to create bigger programs. From that moment, I cannot help you anymore when things go wrong. I don’t have the time to check many lines of code to find your problems."
Back then, in the eighties, your main source of information were books and magazines. Books were usually very dry and magazines offered more fun projects.
Both would provide example code or even complete programs, that were printed on paper. That means you had to type them over.
It depends. If you are the author of the code, you are also the only one who understands the thought process of it. When things don't work you only have a few options. Inspect your code line-by-line and if you don't find the problem, take out elements of the program until you are back at a point where things do what you expect them to do.
If you copied it from example or tutorial code, you have no other choice but to compare to your code line-by-line, character-by-character!
Both exercises require you to be in a mode of absolute concentration. Creativity does not belong here. In fact, I would argue that in our profession, you have to love working like this. And this is very uncommon for people because usually, good is good enough. But that is not the case with computer science! Software works. Or not.
First of all, there was no internet as we know it today. That means no distraction but also no problem searching online. There was no email. There was only the library and if you were lucky you would have a friend that was a nerd just like yourself.
But the lack of distractions like the internet and social media, allowed us to be alone with the code and we got quite good at typing exact code. That means copy it from an example on paper and typing it in line-by-line, character-by-character.
These days, where code can be copied from Stackoverflow or even let AI type it for you, this seems unbelievable. And yet, it was exactly this, that brought us the two skills we use everyday.
First of all, the code works, or not. There is not much in between. It is much like my electrical scheme. You can write beautiful, creative code but if it does not work, nobody will use it. Second of all, when things go wrong, we had to search for the solution ourselves.
So we had to get used to work meticulously. And if working like this is in your nature, you have a huge advantage as a developer. Of course you can adopt a few strategies to make working like this easier.
Execute your code often. Really often! And here is a tip especially for absolute beginners. After writing or changing a line of code, save and test the program! Do not wait until the program is finished. If a problem occurs, it is much easier to solve it, if you know that the problem must be in the last line of code you wrote!
Do not mix working code with other code. Remove commented-out code, half finished scripts with errors in it and other stuff that does not belong in your project folder. Feel free to set it aside in a separate folder but do not mix it with the final code!
But nothing is as important for a beginner as the last tip. So, what is the skill every beginner programmer should have?
If you are following a tutorial but things don’t work and you don’t know how to fix it, first do a line-by-line comparison. If you still can’t find the problem, start over. This might seem counter-productive at first. Throw away code?
Start over? Yes! Once you get more experienced, you will be able to take a sad song, and make it better. But beginners have to follow a recipe. Just park your non-working code in a separate folder and start over.
And here I am sometimes surprised. Some students don’t seem to particularly like writing code. They rather copy it from an example. But here is a secret: You will only get better at programming by writing code. Yes, it is great you can lookup code online and even let AI type it for you. But the real learning happens by doing it.
I think that the skill of keeping at it, being willing to compare line-by-line and rewrite the code if necessary, is the most important skill for beginners.
Is the goal to throw away code? That much of the work is for the trash can? No! Regard every line of written code, every checked line of code as a chance to get more routine and prevent making some mistakes in the future because with each line of code, you got better at programming.
The young me (and even the old me) had to check and improve many of my work. My electrical doorbell scheme went straight to the trash can. I had to create a new one that produced a good, working doorbell. After that, I never made that mistake again!
If your program does not reach the goal, it is unfortunately a useless program. Redo your work and in the process, develop your coding skills!