Becoming a great programmer takes lots of time, but there are a few things you can improve right now

Building a formidable portfolio of programming skills takes years of trial and error. Fortunately, there are always some things you can do right now to become a better programmer and a better member of the team at the same time. Let’s do this!

Try to Break Your Code

You are responsible for testing your code. Always. It doesn’t matter if your company has a great QA team. You’re accountable for your code.

The goal of everyone working in the company — be it a software developer or a tester — should be shipping quality software as fast as possible. Building great products requires cooperation from the whole team.

If you don’t test your code, the tester is almost sure to find a bug. So they create a ticket for you. You fix the feature and send it back. But there’s another issue, and there’s another ticket for you.

This bug loop can be endless, draining time and patience from both sides. You can spare everyone the pain if you test your code carefully. And you should always do it. You may think it’s a trivial change that can’t break anything. Still, test it. Programming is complex, and the chances are you missed something.

You may think you’re a superstar programmer who doesn’t make mistakes. Well, you’re wrong. We all make mistakes. Just devote a few minutes to testing and save everyone’s time.

Whatever you think, test your code. And if you find a bug, write a unit test to avoid this bug in the future.

So swallow your pride and try to break the code you wrote. Test for all different scenarios you can imagine. Look for edge cases. You know what your code should do and what it does, so you’re the perfect person to test it.

Devote some time to testing code before pushing it to QA. It will save everyone’s time. And who knows, maybe you’ll make some new friends by being a good colleague.

Make Small Commits and Pull Requests

Commits to the version control repository represent the history of the code. Each should have a meaningful message explaining why you made the commit. It’s a bit of a stretch to claim that you should be able to read the commit history like a book, but it should be readable for someone trying to understand what happened.

To make good commits, you have to make them small. It allows you to focus each commit on a tiny change — be it a feature, bugfix, or refactoring. If your commit is too big, you can’t describe it in a short commit message, so the code history becomes harder to read.

Small commits also have other advantages. They are easier to test, and if the tests fail, they facilitate debugging because there is less code that could cause the bug. Small commits also expedite reverting to the earlier commits easier because they mean you lose less code on the reversion.

You should follow this same rule when you’re making pull requests. Making them small allows the person who will review the code to do it more thoroughly and with more certainty. A pull request that is a few thousand lines long and changes dozens of files won’t be checked carefully. And when pull requests are not checked, you end up with worse software. What’s more, if someone won’t review your code, you won’t get any feedback, which will hinder your growth.

Photo by Dan Burton on Unsplash.

Build Fast, Then Refactor

Programming is a complex process. To be an effective software developer, you need to approach problems in an organized way. Before writing any code, you should consider some critical aspects of your task.

What are you trying to accomplish? Are you sure you understand the requirements exactly? Devoting a few minutes to reflect on requirements can save you lots of time along the way. You should also make sure this problem wasn’t already solved in the project (or maybe in another project you were working on). Many features are similar, so perhaps you’ve got a proven code you can use. Lastly, you have to come up with some approaches to solve the problem.

Thinking is crucial, but it’s easy to fall into the trap of overthinking. So when you have some idea about possible solutions, pick the most promising one and start coding. Don’t try to make your code impeccable or deal with every edge case. Just complete the crucial parts of your code. Details are not important. The same goes for useful programming rules like Don’t Repeat Yourself (DRY). It’s OK to repeat anything you need to as long as you’re working on the first draft of the code. Now we should have something that more or less works. That’s great!

The first version of code can’t be the last one. Even if you tried to do your best, you have to assume your solution is flawed. Maybe it’s slow, hard to read, or relies on too many external libraries. Whatever it is, you have to refactor.

Remove the repetitive parts, look for better abstractions, and add comments if necessary. Create some unit tests to be able to refactor with confidence that the essential features still work. Consider if your code may break something in other parts of the application. Change the variable names to be readable for other humans. Make every effort to create code that is as good as possible. That’s all anyone can ask from you.