If any of us lived forever, we could always write code refined to perfection. Unfortunately the constraints of time and mortality – and, less metaphysically, those of our employers – mean that those of us wishing to learn how to code must also learn how to code relatively quickly.
Coding fast is a wholly other skill than coding well. In fact, it is arguably less a skill in its own right than the aggregate of an entire constellation of apparently minor skills. It is important and complex enough a topic that we intend to split this article into two parts, so that we may cover faster coding both in practice and in theory.
Our article will be organized as follows:
PRACTICAL TIPS
GENERAL THEORY
Let’s start us off with the practical side of coding quicker – strictly without compromising quality, of course!
PRACTICAL TIPS
#1. Know your editor
Many programmers only learn the basic functionality of code editors like Visual Studio Code, PhpStorm, or Pycharm, perhaps because they feel that studying them in greater depth would steal time from whatever coding project they’re working on. Don’t fall for that trap! You may think that learning keyboard shortcuts, or how to quickly find and open files, will only gain a second or two for every paragraph of code you write – but once you’re doing that instinctively, it can shave off up to 10% of the time you spend in front of the monitor.
Set aside one day and dedicate it entirely to learning and exercising yourself in the more advanced functions of your editor, particularly if you are assigned a project that requires you to switch to a new one. It’s one of the most direct and universally efficient ways to speed up the coding process.
#2. Do copy, don’t paste.
As most professional developers will tell you, copying code that works is not ‘cheating’ – it’s sparing yourself the futility of reinventing the wheel. Thus, we wholeheartedly recommend using Google to look for solutions to programming problems which have been made publicly available, particularly if your aim is to code more quickly. That said, here’s a helpful little trick not many have tried out: don’t paste the above-mentioned solutions into your code, but take the time to manually type them out yourself.
You may think this will rather slow you down – and for the first few weeks, granted, it probably will. But it will also brand the solutions you’re copying into your brain and automate them into your fingertips. Also, and crucially, you will gain a more intimate conceptual understanding of what you’re working with. Eventually you’ll find yourself writing these solutions without copying them from anywhere, possibly without even thinking about them, and you’ll be whooshing through code that would have previously taken multiple stops and starts.
#3. Unit tests
It’s actually surprising how many excellent developers have never been taught the value of unit tests. If you’re unfamiliar with the term, these simply consist in testing small or smaller units of code by themselves, as distinct from integrated tests, which run a program (or a large part of a program) in its entirety.
Running regular unit tests doesn’t mean that your code will be free of bugs, but it does mean that you will find them in a fraction of the time it would take you to reexamine your entire code. Resist the illusion of speed you get from blazing through your entire project in one go, particularly if you’re relatively inexperienced. Instead, keep your units of code short and test each of them methodically. It may feel slower while you’re doing it, but in reality you are preemptively sweeping aside what could be hours of work.
#4. Mnemonics
We all retain and process memories differently, meaning that different learning methods will work best for different people. That said, not many are aware of some of the simple tricks you can use to train your memory and make sure you retain information for long stretches of time.
This is important for programmers because methodically committing to memory ways to cut down loops or to more efficiently exploit dataframes is perhaps the most powerful cognitive exercise to become a faster coder, albeit not the easiest to master. Practice mnemonic methods, and then use them whenever you come across a clever few lines of somebody else’s code (you can find a ton on Kaggle, if you’re not sure where to start). Naturally, you should also make sure you are using what you’ve memorized in your own projects, further ingraining it in your mind. This can take some effort to pull off, but done consistently, it’ll likely push you forward and permanently speed you up more than any other tip on this list.
#5. Start with what you know
You always want to make sure you have a plan before you start a project, but once you do start, go for the easy bits first. Many of us have an instinct to ‘get the hard bit out of the way’ when working, and while this is helpful in many fields, it can actually be counter-productive in programming.
If there is a part of your project that you already understand very well, start there. Write whatever code is the least troublesome first, especially for the projects that are most complicated and ambitious. The reason we give this advice is that problems in programming are frequently sequential – solving the first part makes it easier to solve the next, which makes it easier to solve the next, and so on. Naturally, this isn’t just going to magically solve all of the remaining intellectual or creative challenges, but at the very least it should get you thinking in the right direction. And sometimes that can make all the difference in the world.
This was the last of our practical tips on writing faster code. Now let’s look at the general theory and the outlook that will complement these tips!
GENERAL THEORY
Before starting on the theory of writing faster code, it’s worth emphasizing that the precondition for efficient coding is a healthy, balanced approach to the work of programming in general. You’re not going to code more quickly if you’re not getting enough sleep or managing your workload reasonably, and if that’s the case, you might want to take a look at our article on programming and lifestyle.
If you have that bit down pat, then great – let’s dive into our suggestions!
#1. Keep code simple
In general, this is one of the golden rules of programming, and for good reason. Among its many advantages, there’s the fact that simple code is less likely to lead to mistakes, and even when it does lead to mistakes, it is so much easier to fix them. Thus, simple code is not just faster to write because it’s shorter, it also saves you a ton of time in the process of debugging and/or redesigning.
If your code is overly complex (and assuming you’re not overly experienced and deliberately trying to outsmart everyone – not a good idea!), that typically comes down to a.) insufficient familiarity with your programming language of choice and the tools it offers, or b.) a relatively fuzzy understanding of an important concept in coding, like objects or recursion. Identify the area where your knowledge is wobbly and study to fix that. If you need to go back to basics, do it. This is about your core competence as a programmer, and there is no way to write quicker code than to improve that!
#2. Write code you can recycle
Many of the tasks you’ll be presented with over your career will overlap with each other. You may need to build UI structures for different websites which do more or less the same thing, or games that belong to the same genre. For this reason, you should try to build code that is easy to reuse whenever this is a possibility.
As an indication – though by no means an unbreakable rule – make sure you’re writing code which you will be able to implant into a different project without too much effort, rather than patterns inextricably embedded into the program in its entirety. This will help you cut down the amount of time you dedicate to each problem by having some of its components resolved in advance and ready to be integrated.
#3. Question your managers
This one becomes essential if you’re working for someone who is not themselves a programmer. Any time you are assigned a project, before you write a single line of code, you should always critically examine the task you are being given: what problem are you being asked to solve, and why do they want you to do it this way in particular?
As the person who is actually building the code, you are the one who is best placed to see what the optimal solution is and what’s the best way to get there. Take a moment to think about it, see if you can come up with a better way of doing things than what your managers assigned, even at the cost of turning the whole project upside down, and if so, raise the issue. If your superiors are asking you to do something in a way that will take you twice as much time as is necessary, and you simply go along without question, then you have only yourself to blame for the waste of time.
#4. Don’t just use the language, understand it
Programming may be an intellectual activity, but that doesn’t mean the response to every problem will involve locking yourself in your mind palace. Sometimes you have to look at the material you are working with – for instance, some variable you did not fully understand, or a symbol you did not take the time to properly investigate.
Can you explain what ‘%’ really means in your programming language, or are you just using it because it sort of seems to work the way it did in another language you’re more familiar with? You may think you can wing it without fully looking into these matters – and granted, sometimes you can – but there is hardly a more common cause for simple tasks taking unreasonably long times than a programmer not properly understanding their language.
#5. Plan by drawing
There are very many ways to plan a project, and every programmer will have his or her favorite approach. In general, though, putting pen on paper before you put fingers on keyboard, and making a drawing of your project, is something almost everyone finds helpful.
Going into a project with a well thought-out plan is key to saving time in implementation. Laying said plan down on paper so that you can see it with your own eyes, rather than attempting to hold six complicated concepts in your mind simultaneously, will let you spot potential problems and breaking points much more easily. You can then work around them in advance, instead of spending hours past your deadline trying to figure out what went wrong. That’s well worth investing a little longer at the drawing board, as it’s a classic case of using time to save time.
…And with that, we have covered both the practice and the theory of writing faster code! If this article was helpful to you, take a look also at our guide on efficient debugging – and soon you’ll be unstoppable!
