Original work by Paul Isaris, licensed translation by New Frontend.

The preface

Many people believe that the transition from an effective junior programmer to an intermediate programmer is just a matter of time and experience, but in reality the distinction between the two types of programmers is less clear-cut and subjective. I’m not writing this article to argue with anyone about what defines an intermediate programmer.

I think the things that fundamentally change a person’s habit of thinking and move them from an entry-level programmer to an intermediate programmer or even an advanced programmer are “habits” :

Habit is the process of moving something from unfamiliar to natural by systematically starting to do it.

Forming work-related coding habits is critical to professional development and personal growth.

Let’s take a look at some habits that, once established, will help you become a better programmer and continue to improve:

1. Keep it short

Ideally, each method should contain no more than 20 to 30 lines of code (LoC). This habit is important because it will not only keep you committed to writing compact code, but it will also keep you analytical when modularized programs are needed. Writing code with multiple layers of nesting (like lots of if statements and for loops) is a nightmare, because while it makes writing easier, when you look back at your code later, you may never remember what it did.

In addition, methods with complex structures generally have low reusability. They often serve a single purpose within a project and are difficult to use elsewhere.

2. Choose names that make sense

Both methods and variables. An intermediate programmer can’t name a variable “X,” “XYZ,” or even “Object.” The whole point of using English words as variable names is to give them real meaning.

Conveying information in the code itself is more important than documentation and comments.

The purpose of annotations is to explain why, not how.

Using meaningful variable names not only helps you better communicate information to those who read your code, but also prevents you from using a lot of comments. This applies to both “variables” and “methods.” Also, if you really can’t come up with a good name, consider refactoring your code to simplify each method. It is much easier to name simple methods than complex ones.

When you can’t think of a name, see if your method is too complex and needs refactoring.

3. Don’t let methods have too many parameters

If you find yourself writing a method that has a lot of parameters, you should consider refactoring it, because such methods often violate SRP (single function principle), which means that it does too much work. An efficient, concise approach should focus on “doing one thing well.” Uncle Bob once said that a method should take up to three arguments. This is not required, but it gives you an idea of the number of arguments that are most appropriate for a method.

Refactoring code is not about changing method parameters to class variables, but about reducing the work of each method or splitting it into two methods.

Here’s a quote from Robert C. Martin:

“A method should have as few arguments as possible. None is best, followed by one, two, three. More than three is problematic and should be avoided.”

4. Don’t have too many methods in one class

Just like the number of arguments a method has, the number of methods in a class is important. If a class is too large and contains many methods, it usually means that the class “stores too much information or does too many functions.” These classes are often referred to as God objects to describe them as the antithesis of highly coupled code.

If you have a class that contains many methods, think about whether you need to come back and modify the class as the program evolves. If so, you may be violating the open-closed principle, which states that “objects in software (classes, modules, functions, etc.) should be open for extension but closed for modification.”

5. Use only long-run/stable third-party libraries

Your code should be designed for programmers who will use it to recompile the entire project. The LTS (long Term support) version of the libraries, plug-ins, and frameworks may lack some fresh features, but they make it easier for others to recompile a project.

Don’t always think about using the latest version of the tool, but use the most secure and stable version. Both you and your coworkers will thank you!

Learn to recognize common design patterns

You read that right, many large projects use one or more design patterns to establish design descriptions, relationships, and levels of abstraction. You don’t need to know all the design patterns, just a few of the key ones, which will not only help you conceive and design your own programs, but also help you recognize them when you read code written by others.

If you can recognize design patterns in someone else’s code, you can easily find where the various classes and objects are, so you can extend and add the functionality you want.

A good design pattern enables all participants in a project to use a common design language and communicate effectively through code.

7. Think about future programmers

Future you, your co-workers, new programmers, or even programmers from other companies may need to extend or add new features based on the code you’ve written. A lot of junior programmers don’t understand this because they’re used to writing code that only they can understand for solo projects in college.

But the demands of the workplace are different from those of college. You may need to write code for projects that have been running for a few years, and your code needs to take into account programmers who will come in a few years from now. If you implement a feature in some weird way, or add steps to the builder that aren’t documented, or don’t refactor where you should, you create technical liabilities that later people will have to deal with sooner or later.

It is recommended to review your work every few hours, such as adding necessary notes to your README file or deleting code and files you wrote temporarily but no longer need. In addition, when you are not sure if you have made the right architectural or programming decision, you can consult some of the more experienced people around you. By doing this, you’ll not only write more elegant code at work, but you’ll also improve your ability to deal with similar problems in the future, while adjusting to bruised egos. (This is an experience that middle and advanced programmers face every day :D)

conclusion

Moving from beginner to intermediate programmer is not an overnight feat, and you need to develop good habits to move up and become more professional. In this article, I’ve listed the most important habits a programmer needs to make such changes and have an impact.

  • 14 Habits of Being an Effective Programmer (Part 2)