9 Habits That Will Improve Your Programming Skills

Software development isn’t easy. Computer science and software engineering are fields that require deep knowledge in a large number of topics. You can always learn a programming language by understanding the syntax and looking at examples, but can you learn how to properly structure large amounts of code into readable and flexible blocks? Do you know how to optimize your code for performance? Is your code maintainable by other developers?

These are skills that you can only learn by practicing writing code, getting feedback, and figuring out how to do it better. This process of improving your programming skills can take years of hard work and dedication. But if you truly want to improve, this is the way. Saying you can get good at writing code by learning a programming language is like saying you can learn how to drive a car by watching other drivers, or learning how to surf by reading a book. It’s just not possible.

So, to help you improve faster, I want to share with you nine things that helped me along the way, and I’m sure they can help you become a better developer too.

1. Adopt a Well-Defined Coding Standard

A coding standard, sometimes called a coding convention or style, is a set of guidelines on how to write code so it stays clean, consistent, readable, and maintainable, not just for you, but for other developers as well. Coding standards cover things like how to format your code, how to name variables, where to put comments, how to handle errors, and much more.

I know it sounds like something for teams of developers, but it actually really helps when working on a large project on your own as well. Imagine you have to look at code you wrote a month ago. There is a high chance you won’t remember every detail of the code you wrote. If you followed a coding convention, you’ll find it much easier to understand the code you wrote a while back.

Some popular examples of coding standards are PEP 8, which is a style guide for Python code, or the Google Java Style Guide – a set of guidelines and conventions, which as the name suggests, was created by Google for writing Java code. But the code convention is not defined just by the language.

Sometimes it’s adopted by a whole industry, like the Motor Industry Software Reliability Association, in short MISRA, developed for safety-critical software in the C and C++ programming languages. These guidelines are widely adopted in industries such as automotive, aerospace, and medical devices, where software reliability and safety are critical.

So pick a coding standard that suits your programming language and project needs, and stick with it.

2. Cultivate a Habit of Refactoring the Code Upon Reaching a Milestone

The next thing that will help you is cultivating a habit of refactoring the code once you reach a milestone. When you first write your code, you’re probably just focused on getting it to work. Quality might not be your top priority at that moment. But later on, it’s important to take another look at your code and clean it up.

When I write new code, I am very focused on getting some functionality to work. That’s because I want to check if my idea works first, before I build the correct architecture and make the code pretty. So I usually hard-code numbers, write lots of comments, duplicate code to experiment with different variations, and name variables with generic names like “temp” or “s,” and so on.

So when I get to a point where my code does what it’s supposed to do, I go back and see if I can improve it. If an architectural change is needed, like creating new files and moving some functions, or creating child classes to make my code more generic, I do it.

But I never forget to fix the small issues like converting all hard-coded numbers and strings to constants, naming variables correctly, removing duplicate or commented code, writing comments only when necessary, and checking that I didn’t miss any cases when handling errors.

Regularly going back and fixing your code will give it a good architecture, make it easier to read, and generally make your code better over time. However, doing this while you’re still working on your code is not recommended because it can really slow you down.

It really depends on you and your project. I suggest waiting until you finish writing and testing a big chunk of code and you’ve reached some sort of milestone. At that point, you’ll have a better sense of the whole picture and can go back and clean up your code.

3. Read Other Developers’ Code

The third thing that will improve your programming skills is reading someone else’s code. It might sound boring or pointless, but I personally benefited from reading other people’s code and then talking to them about it. Reading other developers’ code does two things:

  1. It helps you learn proper code structure, design patterns, data structures, and other techniques to implement well-written software code.
  2. It allows you to identify mistakes made by other developers. We often miss errors in our code that are obvious to someone else. Viewing code from an outside perspective makes it easier to spot these issues and then avoid them when writing our own code.

If you don’t have anyone you can reach out to, another option is to explore freely available source code online. For instance, I once read the source code of old video games recreated in C++. Having played these games for many years, I found it really interesting to see how they work under the hood. Discover your own area of interest and search for source code in the depths of the internet.

4. Strive to Write Simple and Straightforward Code

Number four is to use the “Keep It Simple, Stupid” (KISS) principle. Keep the code as simple and straightforward as possible. Avoid over-engineering and use the most straightforward and intuitive approach to solve a problem. It is the best solution to a problem, most of the time.

Sometimes, people have the notion that code should be complex to be good. Have you ever heard someone brag about the “millions of lines of code that went into this piece of software”? Well, there’s nothing to brag about there. Why do you need that many lines of code? Are you working on the Mars Rover software or something? You should aim to have as few lines of code as possible without sacrificing functionality.

Another concern is performance. Some people think that the code should run at peak efficiency, even though they’ve never used a profiler to check if there’s actually a performance problem. Then they proceed to ruin their code by introducing some incredibly complex algorithm instead of using the straightforward solution to their problem.

And when they realize that no other developer would ever understand this algorithm, they immediately write a long comment about what this algorithm does and how it works. If only they had measured the performance of their initial, simple code, they would have probably realized there was nothing wrong with it in the first place.

5. Ask Other Developers to Review Your Code

The fifth thing you can do to improve your skills is to ask others to review your code. Code reviews are incredibly valuable because they offer a different perspective of your code. As I have said before, it’s often easier for someone else to spot mistakes or issues that you might have missed.

While it might not always be possible to find someone to review your code, it’s still worth seeking out feedback. If you’re part of a team, use their expertise by asking for reviews. Code reviews are a chance to connect with others who share your goal of improving code quality.

That said, code reviews aren’t always pleasant. You have to be open to feedback and be prepared to defend your choices. I’ve been in code reviews that turned into heated arguments. Remember not to take it personally; instead, see it as an opportunity to learn and develop your skills.

6. Learn the S.O.L.I.D Principles

Next, I recommend learning The SOLID principles. These ideas are the golden rules of object-oriented software design. Developers use them to make their code easier to understand, tweak, expand, and maintain. Since they were published, they have become bedrock concepts in object-oriented programming.

The SOLID principles include five rules: the Single Responsibility Principle, the Open/Closed Principle, the Liskov Substitution Principle, the Interface Segregation Principle, and the Dependency Inversion Principle. I know these names probably don’t mean much to you, and I won’t go into detail on each one. So if you want to learn how to use these ideas, you’ll have to research and practice them.

Now, I am not saying you should blindly follow these rules and apply them everywhere in your code. What I am saying is that you need to be aware of them, practice using some of them, and over time, you will find how to incorporate them into your own code, at least partially.

7. Practice Using Common Software Design Patterns

In 1994, a group of computer scientists published the famous book “Design Patterns: Elements of Reusable Object-Oriented Software“. This book kickstarted the idea of design patterns in software projects. Since then, the patterns they described have been improved and extended, and many other patterns have been documented. The authors of the book are now famously known as the “Gang of Four.”

Design patterns are templates for solving common problems in software development. They’re tried-and-tested solutions that you can use to address specific issues when designing and building software. By following these patterns, you can make your code more organized, flexible, easier to understand, and less prone to errors.

But don’t mistake them for template code snippets you can just plug and play. Design patterns aren’t cookie-cutter solutions; they’re more like guiding principles that help you navigate tricky design challenges. You take the essence of a pattern and modify it to fit the unique structure of your own code.

It’s easy to confuse design patterns with algorithms, but they’re not quite the same thing. An algorithm is like a step-by-step instruction manual for building a specific type of house, such as a single-story cottage with a sloped roof. It tells you exactly what materials to use and how to put them together in a precise order.

A design pattern is more like a style or theme for building houses, such as modern, traditional, or minimalist. Each style has its own basic rules and ideas for making a house look good and work well. Similarly, design patterns offer general ideas and tips for solving common problems in building software, so developers can adapt them to different projects.

8. Write Unit Tests

This is one of the best ways to improve your programming skills. The more of them you write, the better. In software development, unit testing is a process in which the smallest testable piece of source code, called a unit, is tested individually and independently to see if it works as expected.

Think of a single function that you can test to see if it works correctly. You give the function some inputs, for which you know the expected result, and then compare your expected output with the function’s output. If the results are the same, you know that your function works correctly, at least for this particular case. If not, there is a bug in that function and you need to debug it.

This will help you discover failures in your algorithms and/or logic before you release your code. Because unit testing requires your code to be structured appropriately, the code must be split into smaller, more focused functions. Each is responsible for a single type of operation, rather than large functions that perform several different operations. This is one of the core ideas of the SOLID principles.

The second benefit of writing well-tested code is that you can avoid breaking code when making changes to existing functionality, or refactoring large chunks of code. When the unit tests fail, they will tell you that something was written incorrectly. At first glance, the development time spent writing unit tests looks like an extra cost. But, over the long run, unit tests will save you much more time on debugging.

9. Use External Tools to Improve Code Quality

And finally, number nine – use external tools to improve code quality. There is no developer who has never made a mistake. Typically, the compiler catches syntax and arithmetic problems and displays the stack trace. But some problems may still surface that the compiler doesn’t catch. For example, code style violations, high code complexity, code duplication, security vulnerabilities, or even potential bugs that can appear at runtime. This is why some developers use a static code analysis tool.

A static analysis tool can find these types of issues by analyzing the code without running it. The result is a list of different kinds of issues, from the smallest warnings to the most critical bugs. You can use these tools to see the issues in your code and learn from them. Using a static analysis tool will dramatically reduce the chance of bugs in your code.

Some examples of these tools include ReSharper for Microsoft .NET applications, SonarQube, which is an open-source platform supporting multiple programming languages, PMD for Java, JavaScript, XML, and other languages, and Parasoft Static Analysis for C and C++ languages. There are many more tools like these, and you should choose the one that fits best for your language and needs.

Can You Apply Everything You Read in This Article?

So, can you take all of these nine points and apply them in your code? Well, of course not. It is unrealistic for you to try and incorporate all the things I talked about into your code. What you can do is pick one or two points that resonated the most with you and make them a part of your programming skills. When you feel like you’ve learned and practiced what you chose, come back to this list and pick another thing or two.

If the information in this article was helpful to you, you might benefit from reading other articles about game development and software engineering in the Night Quest Games Blog. see you there!

Leave a Comment

Your email address will not be published. Required fields are marked *