Analysis of common mistakes made by novice programmers, pt. 1

Hello, world! Once you've learned everything you need to know and finally get to work as an intern or junior dev, you can probably relax, right? Nope. Everything is just beginning for you... You're surrounded by a lot that is new and incomprehensible. How do you not screw it up right out of the gate? That's what we're going to talk about today. In this article, I want to analyze common rookie mistakes and give some advice, based on my own experience, about how to avoid them. So, let's start without any further ado:

1. Fear of seeking help from more experienced colleagues

We're all human. We're all afraid of looking stupid, especially in the eyes of our new, more experienced colleagues. When developers take their first job, they are often guided by this fear and, with a heavy heard, withdraw into themselves, trying to figure everything out on their own. Additionally, someone can be surrounded by more experienced colleagues, who, in turn, are able to point him or her in the most promising direction, helping to avoid more mistakes and unnecessary "bumps on the head". So remember: don't be afraid to ask questions. You are a beginner and everyone understands this perfectly well. When you ask, no one is going to beat you with sticks. Perhaps even the opposite will happen: you'll become friends with your colleagues more quickly and begin to enjoy more active communication with them. I'll say even more: the more you ask and discuss various technical issues, the faster you'll be able to shed your green newbie skin and grow into an expert in your field. And one more piece of advice. Don't be a stranger to StackOverflow. I'm specifically talking about asking questions on this resource. On the one hand, it takes some time to get an answer to your question. But on the other hand, you may quickly learn multiple approaches to solving your problem and look at it from a slightly different angle. I also want to note that there are practical benefits to writing comment/answers and writing clarifying questions on StackOverflow questions from other developers: you get a chance to debate and delve deeper into the issues, not to mention a karma boost.

2. Not trying to search for information on your own

This mistake could be considered the flipside of the previous one.Here I mean when you start to pester your colleagues and acquaintances about every problem or hiccup you encounter. Asking is good, but don't go overboard with questions. Otherwise, people may simply find you annoying. If you get confused about something, the first thing to do is to exercise your search skills in the best search engine — Google. Someone else has already encountered the overwhelming majority of incomprehensible errors and other issues. And you will be quite surprised if you google your question and see the number of people who are familiar with a similar problem, and who have already received exhaustive answers that you can apply in your own work. That's why you will often hear your colleagues reply with "Google it". Don't be offended at this answer — your colleague is not your personal teacher who must convey all the subtleties of your field of work. The endless expanses of the Internet will be your mentor. Sometimes programmers are also referred to as people with a black belt in Google search. So if we have a "hiccup", we first google the problem. If a solution can't be found (this is rare, but it happens), only then do we start asking colleagues. Immediate questions are for getting advice about which approach you should choose to solve a problem more than what you would do when you hit a speed bump or an incomprehensible error message. After all, they may be able to see beyond your preferred approach and immediately predict where any given approach will lead in the long run.

3. Blindly copying and pasting

But googling problems and their solutions has its pitfalls. For example, blindly copying and pasting.This usually happens when you find a similar problem (but perhaps not exactly the same one) and an associated solution, for example, on StackOverflow. You grab this solution and copy-and-paste it without further delving into the details. And then you or your coworkers discover some strange bugs or incorrect behavior in your code. And no one can immediately guess where they came from. Eventually, of course, the place with the copied code will be found, and you will definitely not be praised for your solution. Therefore, when you find a ready-made solution on StackOverflow (or anywhere else), you must first thoroughly understand the what, how, and why. Perhaps google the relevant functionality and read the documentation for it. And only after you've done that should you add it to your project.

4. Sticking with the wrong solution

When writing a solution, you will sometimes find that it is constantly becoming more and more complicated, eventually arriving at a dead end. And then you try to make the solution even more elaborate in order to somehow make it work instead of looking for another, more suitable alternative. Maybe you feel like you invested a lot of time and effort and therefore decided that, no matter what, you will not give up and you will solve the problem with your existing approach. This is not quite the right attitude. At least in programming. The sooner you try a different approach, the more time you will save in the end. So don't be afraid to experiment and try other approaches, regardless of the amount of time you have invested in your current one. What's more, by trying multiple approaches and diving more deeply into the subject, you'll be accumulating points in your piggy bank of experience.

5. Fear of asking questions about your current assignment

Working on a software development project usually boils down to performing specific tasks. For example, in Jira. These tasks are not always outlined clearly and in detail. Task descriptions are usually written by team leaders, who are also mere mortals. They may forget to add something or fail to account for the fact that you are not familiar with this or that functionality. Or perhaps you don't have any access to the project (for example, access to the database, the log server, and so on). And now, you've received the task, studied it for more than a couple of hours, but you are still sitting there, staring at the screen in bewilderment. Instead of continuing to unsuccessfully try to understand this, you should start to ask for clarification or guidance from whoever created the task. For example, in the app that your team uses for communication (for example, Microsoft Teams), you might ask questions or make a direct comment regarding the task. On the one hand, if you write your question in a personal message, you will probably get an answer faster, since the person will see your question immediately. On the other hand, by asking a question in Jira, you establish proof that you are doing something, namely, analyzing the problem. There is a way to accelerate this process: ask your question in a comment in Jira and then in a DM, drop a link to your comment and ask to take a look.

6. Placing unrealistically high expectations on the team lead

Again, this is the flip side of the previous point. The team lead is the head of a development team. As a rule, your team lead spends most of his or her time on various kinds of communication. Yet, he or she also writes code in order to not forget everything about programming. As you can understand, the life of a team lead is very busy. Tugging on your team lead's sleeve every time you need to sneeze will obviously not be pleasing. Imagine every member of the team bombarding the lead with a bunch of questions. That could drive anyone crazy, right?And if you pile on lots of questions, then your team lead will have to spend a lot of time answering you. What can be done to reduce the number of questions directed at the team lead:

• Explore the project documentation in more depth to reduce the number of blind spots.
• Direct your questions to your other team members. They may be as familiar with this functionality as the lead is, or possibly even more, since the functionality was most likely written by one of them.

Alternatively, you can look at the annotations in the IDE to who and when the code in a specific line was last changed. That precisely how you can find out who is the most appropriate person to ask your question. As you probably already realize, when it comes to questions to the team lead, just as with questions to colleagues, you need to try to find a happy medium — don't be afraid to ask questions, but also don't ask too many of them.

7. Fear of code reviews

A code review is such a stage that happens before you submit your code to a common application (to a shared branch, for example, master or dev). This check is performed by a developer who is not involved in the task, whose fresh eyes can detect errors, inaccuracies, or flaws in your code style that went unnoticed when you initially wrote your code. If there are criticisms, they are left as comments on certain parts of the code. In this case, the developer who wrote the code must correct the errors identified in the review (or discuss his decisions with the reviewer, possibly convincing him or her that they are correct). Then the code is submitted for review again and again until the reviewer has no more comments. The reviewer acts as a "gateway" before the code is committed. The challenge is that many novice programmers perceive code review as criticism and condemnation. They don't appreciate code reviews and are afraid of them. They shouldn't. Code reviews are exactly what let us improve our code. After all, we receive important information about what we're doing wrong and what is worth paying attention to. You should consider each code review as part of the learning curve, something that can help you get better. When someone comments on your code, he or she is sharing experience and best practices with you. I personally don't believe you can become a good programmer without getting code reviews. Because you aren't even aware of the quality of your code and whether an experienced outsider would point at mistakes.

8. Propensity for arcane decisions

Various tasks/problems can often have several different solutions. And out of all the available solutions, beginners tend to use the most complex and arcane ones. And that makes sense: novice programmers just yesterday learned a lot of different algorithms, patterns, and data structures, so their hands are itching to implement some of them. Trust me, I was like that, so I know what I'm talking about :) I had a situation where I was implementing some functionality for a long time. It turned out to be very, very complicated. Then senior developer rewrote my code. Of course, I was very interested to see what and how he changed it. I looked at his implementation and was amazed at how much simpler it was. And there was three times less code. And also amazingly, the automated tests for this functionality weren't removed or altered! In other words, the general logic remained the same. From this, I arrived at the conclusion that the most ingenious solutions are always simple. After this realization, coding became much easier, and my code quality jumped to a significantly higher level. Then when is it worthwhile to apply design patterns and fancy algorithms, you ask? When applying them will be the simplest and most compact solution.

9. Reinventing the wheel

The wheel is a durable solution that was invented a long time ago. In this anti-pattern, the developer implements his or her own proprietary solution for a problem that has already been solved. Sometimes these existing solutions are better than what the programmer comes up with. As a rule, reinventing the wheel will lead to lost time and decreased productivity, because the solution you find may be far from the best, or, well, you might not find one at all. That said, we can't rule out the possibility of creating our own independent solution: if we did, then all that would be left is copy-and-paste programming. The programmer should be properly guided by the specific programming tasks that arise in order to solve them competently and promptly, whether by using ready-made solutions or by creating custom solutions. On the one hand, at universities and in online courses, we are bombarded with various kinds of tasks that seem designed to help us reinvent wheels. But only at first glance: The real purpose here is develop algorithmic thinking and a deeper mastery of the language syntax. Such tasks also help you to better understand algorithms and data structures, and give you skills to implement more sophisticated counterparts, if necessary (this is sometimes necessary, but it is exceedingly rare). In real life, you do not need to invent your own wheel in the overwhelming majority of cases, since wheels that meet your needs have been around for a long time. Perhaps your inexperience prevents you from knowing about the existence of implementations of the functionality you need. This is where you need to take the advice given in the first point of this article, namely, ask more experienced colleagues for help. They will be able to guide you (for example, point you in the right direction in your Google search) or suggest a specific implementation (for example, some library).

10. Failure to write tests

All newbies dislike writing tests. But why should we single out newbies, here? More seasoned developers also do not like to write tests, but they better understand why tests are needed. When you are completely green, you wonder why you should write them. Everything works, so there can't be any mistakes. But how do you ensure that your changes won't break something elsewhere in the system? Your colleagues won't appreciate it if you push in changes that cause more harm than good. This is where tests come to our rescue. The more an application's code is covered by tests, the better (this is called code coverage or test coverage). If the application has good test coverage, then you can run all the tests to find places that will be broken by your code. And as I said in the example above, when the senior developer refactored the code, the tests did not fail. This was because the general logic did not change. We use tests to demonstrate whether the logic of certain functionality has changed or not. So even if you don't like writing tests, they are definitely useful and well worth the time spent on them.

11. Excessive comments

Many developers suffer from perfectionism, and newbies are no exception. They sometimes manifest just one facet of this propensity when they begin to comment on everyone and everything. Even making comments that are unnecessary, because the code is so obvious:

Cat cat = new Cat(); // Cat object

Not all novice programmers immediately realize that commenting code is not always good, because the superfluous comments clutter the code and make it difficult to read. And what if the code changes, but the old comments are not updated? Then they will only mislead and confuse us. Then why make such a comment at all? Usually, well-written code does not need to be commented, since everything in it is already obvious and readable. If you need to write a comment, then you've already spoiled the code's readability and are trying to somehow remedy the situation. The best approach is to write readable code from the outset, i.e. code that doesn't need comments. I also can't help but mention the need to follow correct naming conventions for methods, variables, and classes. Here's my rule: The best comment is either no comment or correct naming that clearly describes the functionality in your application.

12. Bad naming

Newbies are play fast and loose in their naming of classes, variables, methods, etc. For example, by creating a class whose name does not at all describe its purpose. Or they declare a variable with a short name, something like x. They when two more variables named n and y are created, remembering what x is responsible for becomes very difficult. Faced with this situation, you have to think carefully about the code, analyzing it under a microscope (perhaps using a debugger), studying the functionality in order to simply understand what is happening. This is where the correct naming conventions that I mentioned above come to our aid. Correct names improve code readability, thus reducing the time required to familiarize yourself with the code, because using a method is far easier when its name approximately describes its functionality. Everything in code consists of names (variables, methods, classes, objects, files, etc.), so this point becomes very important when creating correct, clean code. You should remember that the name should convey meaning, for example, why the variable exists, what it does, and how it is used. I will note more than once that the best comment for a variable is to give it a good name. For a deeper study of comments and correct naming, I recommend reading the timeless classics: "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert Martin. On that note, the first part of this article (my reflections) has come to an end. To be continued...