Five rookie mistakes by developers and how to avoid them

Over the years, I have had a chance to mentor a few and lead a team of a few other out-of-campus freshers. I have observed common mistakes that most of us do at the very beginning of our career and then correct these mistakes over time. Only if there was a book to guide us at the very beginning, we would have saved ourselves that time. Nevertheless, I am sharing some of the most common mistakes below one does straight out of college to help at least some of you improve yourselves.

1. Improper naming conventions
   We have all worked our way up to the industry investing a lot of our time in competitive programming. In competitive programming, the speed of coding matters and hence we all develop the attitude of having precise names for variables like i, j, k, etc. We tend to carry the same attitude when we begin with coding in industry. But the key rule in an industry is “code should be readable” as a story. Given the fact that any industry-level solution will grow over a period of time and will have multiple people work on it as it progresses, it is very important to use meaningful variable names, method names, class names and package names. It will only reduce your effort of explaining stuff to any newbie going further.

2. Methods with long lines of code
   Modularity starts here. Understand that every unit of functionality can be a method. Methods with more than 25 lines of code are not just difficult to read, but also can be misinterpreted. The longer a method is, the more prone to error is its functionality. It is easier to write and test small units of methods, than lengthy ones.

3. Design of classes
   Do I have one single class with all the functionality or have multiple small classes? This skill comes with experience and understanding. Understand that every problem needs to be transformed into a real-world problem and if we had real entities solving this problem, then each such entity would be a class. Simply put every class is a noun and a method is a verb, though vice-versa may not hold always.

4. Test negative test scenarios/cases
   Negative test scenarios are very important to test the robustness of any solution. We are always in a world of cyber attack and in an industry, one needs to be even more cautious of dealing with attacks as it may directly or indirectly affect the revenue generation of the organization. It is not just the responsibility of a QA to test the negative cases but also a developer’s responsibility in doing the creative job of coming up with the negative test scenarios and solutions to them. That gives you the edge over other programmers out there.

5. Enhancement vs Change in requirement
   We are in an ever-changing world - Change is constant, embrace it. One needs to learn to distinguish between enhancement and change in requirements. Start with solving today’s problem with an eye on tomorrow’s expectations. Provide a quick solution for today’s problem and then work for a solution which is better in near future’s operating conditions (traffic, customers, competition in the industry, etc). Simply said, software development is this vicious cycle of improving the solutions to an old problem.