Top 5 Mistakes I Made When I Was a Newbie in Programming
Time flies so fast. My first line of code was written in 2013 when I started my college life. You probably guessed it, I printed “Hello, world” by the C programming language and felt so excited when the code worked. 😄
Now, I’m working as a professional software engineer and have implemented several projects already. Many younger friends asked me about how to learn programming fast or how to write high-quality code.
To be honest, I think I’m not successful and qualified enough to give suggestions to them. Because programming is a life-long journey and there are always lots of things I haven’t learned or even known yet. In addition, learning to program is like learning to ride a bike, it requires a lot of practice. Nobody can become a great developer only by reading textbooks or suggestions. We should practise, make mistakes, learn from them and move on again and again.
Therefore, instead of giving suggestions, I think it will make more sense to share the mistakes I made when I was a newbie in the programming world. Because when I look back, every mistake I made was a great opportunity to learn something new.
1. There Are No Comments at All in My Code
As mentioned, I was very excited when I saw my first program worked well. I fell in love with programming immediately. I read many materials recommended by our lecturer of the C programming language course.
When the midterm exam came, I was full of confidence. There were a few problems designed for us and we needed to solve it by code. I wrote my program confidently and submitted it.
After that, I thought that I probably could rank first in this exam. Because I solved all the problems with my excellent code.
However, I only got a “pass” for this exam. What happened? 😱
Reviews from the lecturer told me the truth:
You solved the problems, but your code has no comments at all. It’s very hard to understand how your code works.
I was confused about why he said that and why the boring comments were needed. I went through my code again and something very embarrassing happened:
I couldn’t understand the code I wrote by myself!
What would the function named “f1” do? How about the function named “f5”?
Because I named every function by an “f” following a number and no comments about what it would do, no one, including myself, was able to understand the code easily.
I learned an important lesson from this exam:
It is not enough to just make sure my code can work. Good programmers must ensure the readability of their code.
After that, comments are my friends and the names of variables or functions are carefully designed to be clear and understandable. No functions like “f1” or “f5” appeared again in my programs.
2. Use One Function To Implement All Things
At least in my first two months of learning programming, I didn’t know why I need to define many functions. Why not implement everything just in the
When the complexity of my program became higher and higher, I knew I was too naive. Even though I wrote some comments in my code, I was still very hard to read my own code again. Because there were too many things written together all in one function, I even felt hard to clarify which part would do which job. It would be a nightmare if I need to modify parts of it.
Therefore, good code should be both readable and maintainable. It would be much easier to modify my program if I defined different actions to different functions. At least I will seldom need to waste lots of time to find which part should be changed.
3. Never Check the Received Values of A Function
I still remember the scene now.
My manager, who just reviewed my code, said to me, “Hey Yang, come here!”
Something in my code might be wrong, I guessed with a little nervous.
The manager was pointing at one function, which was used to handle a database table, and said, “ I told you, it’s absolutely unsafe here! But you still don’t check these values! Don’t you know a simple invalid value may crash the entire software?”
“Oh, sorry about that…”, I sincerely admitted my mistake. In the function, I forgot to check the received values of parameters were valid or not before handling them. After a more detailed explanation by my manager, I have understood the importance of it.
For example, we have a function receiving an integer argument:
#include <stdio.h>int divide(int a,int b)
result = a/b;
The above code works well. But if we try
divide(9, 0), it won’t be fine again.
So, we must check the value of parameter
b before handling it. If it is equal to zero, the division operation should be avoided.
It looks intuitive that we should do it. Not to mention lots of textbooks will tell us to check the denominator before dividing. However, the real scenario is much more complex than it, this checking step could be forgotten.
As to my code, I didn’t check the string parameter which would be used to query our database tables. If it was not a valid string, the program would crash. Not to mention the code may be attacked by the SQL injection technique.
Now, checking the parameters’ values first before doing something with them is my normal habit. It makes my program safer.
4. Too Much Magical Numbers in My Code
Fortunately, this mistake didn’t make my teacher or manager become angry. But I think it’s still worth to mention.
My first job was in a game company. When I developed my first game, there are a few constant numbers, such as how many sides of a dice, how many blocks in a map and so on. I just wrote the numbers at anywhere they were needed in my program.
A colleague gave me a friendly reminder about this. He said it could be better to define constants that represent these numbers and use them instead of the magical numbers.
It made sense! After changed my code, everyone said it was more readable. In addition, it made my life easier when I need to modify one constant number, since I just needed to change the constant value rather than finding and modifying the same number in many places of my program.
5. Don’t Care Which Environment I Was In
This could be the most dangerous mistake I’ve ever made. When I did some interesting personal mini projects during my college time, I didn’t care too much about the concept of environments. I knew that I should have at least two environments for my software: testing environment and production environment. But it didn’t make much sense for my small projects that the developer and user are the same guy — myself.
However, life is not always that easy.
When I was an intern in a company, I submitted my new code to the production environment without testing it. You probably already guessed the result — the software was broken and every one couldn’t use it.
Thank god, that was just a small internal tool and I fixed it immediately. My mentor reminded me not to make the same mistake again.
Many companies have strict access control of their code. A new employee can’t touch the code in a production environment until he or she totally understands the project and knows how to test code in the testing environment. I think it’s a good idea.
Now, even my personal side projects will have two environments. New updates will never be pushed to the production environment if they can’t work well in the testing environment.
Making mistakes is inevitable in the process of programming. The most significant and effective way to improve our programming skills is learning from our mistakes.
If we want to write readable, maintainable and safe code for commercial software, we need enough patience to practice, make mistakes, learn from them and try it again and again.
Thanks for reading. If you like it, don’t forget to follow me to get more great articles about programming and technologies!