How to write faster code: understanding the theory
Where we go beyond practical tips and delve into the deeper concepts and approaches that will let you speed up the rate at which you code
In our previous article, we shared some quick fixes to write code more quickly without compromising its quality. Here, we will expand on that concept and go over the theoretical groundwork that leads to quicker coding — or, in other words, the ways to understand and approach problems in programming with a view to solving them more efficiently.
Before starting, 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 him/herself 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 his/her 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.