Do you think you’re coding fast enough?
Your manager may have told you that he was concerned about your ability to code faster. Or you could be comparing yourself to your teammates. In any case, you should not worry too much about it. Here’s why.
How Do You Code Faster?
In the strict sense of typing code, there are two ways to improve how fast you code.
First, you can learn the shortcuts of your IDE or your personal editor. The idea is to use your mouse as little as possible until you can manage to do everything with your keyboard. For example, you can code very efficiently with VIM once you learn the bindings.
I personally never did it. When I worked as a Java software developer, I didn’t know many shortcuts in Eclipse. Too lazy to learn or too stubborn, thinking that I was productive enough with my mouse? Probably a bit of both. I guess I never took the time to learn, because I was afraid of being less efficient for a while. I wasn’t looking at the long-term results.
If I happen to write code for a living again, I will definitely learn all the shortcuts that my IDE — and more generally, my tools — can offer.
You could also be using a pair programming tool such as Kite. In short, it shows you everything you need without having to search for it: documentation, examples… It also offers to fix simple errors. Careful though, as they’re sending everything you’re typing to their cloud servers so it probably doesn’t fit with your company policy. You can find similar local alternatives, especially for documentation: Zeal for Windows and Linux or Dash for Mac OSX and iOS only.
The other way consists of training to type words fast. Remember the first time you were typing on a keyboard?
There are plenty of tools on the web which tell you how many words you can type per minute. There is a difference, though, between typing normal text and code. Typing.io can help you understand how to type code faster and better. Your typing will become faster as you continue working with your keyboard, anyway.
At the end of the day, as a software developer, you probably — well, you should — spend more time thinking about your design rather than typing it.
Practice Makes Perfect
So you’re given a problem that you have no idea how to tackle.
“How the hell am I supposed to code this?”
Building the design of your code is not an easy task, especially for a beginner. Try first to break down the problem into multiple small problems that possibly you know how to resolve. Quite a basic piece of advice, but essential nonetheless. Don’t hesitate to use a pen and piece of paper if necessary. Not all programmers can design everything in their head, and that’s fine.
There’s a very low chance that one of the small problems hasn’t been fixed before. Perhaps this problem is solved in another part of the application you’re working on, in which case you can take the opportunity to factorize the code. Or maybe other developers in the world have tackled the very same problem so you can find, if not the answer, guidance on how to resolve it with a quick web search.
There is no magic though. It ultimately depends on your experience. Your own experience as a developer and also your experience with the source code.
I believe that the best way to become familiar with a source code is to debug it.
As Brian Kernighan put it:
“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”
Chase bugs in the code and debug the hell out of it! You’ll progress slowly in the beginning, as you discover the architecture of the app. After a while, you’ll become a machine. When I started working as a software developer, I made debugging my specialty to make up for my technical gaps. It greatly helped me to design solutions afterwards. Not only does debugging help you to explore the code, but it gives you a quick overview of how things work. This way you slowly link technical stuff to a behavior in the product.
Sometimes, the solution to coding faster relies in coding less. Spending more time to design an elegant solution might save time afterwards. Less code, less maintenance.
In the same vein, coding 10 times quicker but creating one more bug is not profitable in the end. Think about how much time is involved to fix a problem in production. Not to mention the number of people impacted. You might save 15 minutes of your time, yet lose hours of multiple teammates’ time afterwards. Not worth it.
On the other hand, this should not be a reason to overthink a design, and become an “architecture astronaut,” as Joel Spolsky calls them. Stop wondering if you’re building the right thing — just start building it.
It doesn’t matter if you’re making mistakes; you will be able to fix them before the code eventually goes into production. Build, assess, correct and iterate. This is how you improve.
Coding Is Not a Race
There will be people who code faster and others that code slower. It’s useless to compare yourself to other developers. You should code at your own pace. If you want to become a good programmer, you should focus on the stuff that matters.
The quality of the code depends on the quality of your work, which also depends on the quality of your working environment. Your efficiency at coding is greatly affected by how much you can allocate time to think and code without being disturbed.
It’s not a race, nor a competition. You don’t measure the performance of a software developer by the number of lines of code he’s capable of producing in a small amount of time. Working 70 hours a week won’t be useful either. Forget about the myth that you will code better alone at night. Programmers do need to sleep.
The only time when you need to compete is during interviews. You need to show the best of yourself. However, companies are not only looking for the candidates who code fast. They’re also looking for teammates with whom they can work. Companies rely on developers that they can trust. Developers who can continually learn. Those who help their teammates progress and thrive. Finally, companies search for developers who can find the right balance between work and private life.
I bet that’s what you’re looking for in the end. You don’t want to become the fastest coder in the world. You want to feel great at work, as well as outside of work.
If you want to practice and see how fast you can find a solution and code it, you can still try Clash of Code!