Developers always want to know one thing: How can I get this done faster?
Coding can be fairly time consuming depending on the project you’re working on, and it can eat away at your day if your workload is heavy, your deadlines are tight, or your processes are slow.
But just because devs want to get things done quickly doesn’t mean they want to do a rush job. Rushing through projects can lead to buggy or hard-to-maintain software that needs to be updated down the line (at a greater time expenditure).
Thankfully, you don’t have to sacrifice quality to get the job done faster. Here are a few tips for speeding up your performance without dumbing down your work.
Gain More Experience
It may seem counterproductive to spend more time working on projects if you’re looking to save time, but the reality is that the more experience you have, the faster you’ll be able to churn out code that doesn’t require extensive debugging later on.
In the early stages of your dev career, you can gain experience and improve your speed and productivity simply by working on your current projects.
You can also:
- Work on side projects
- Work on open source projects
- Work with other, more experienced developers
- Test out productivity tools and techniques
- Do programming exercises
You can (and should) monitor your improvement based on both objective metrics like defect rate and velocity, and subjective metrics like code quality and fitness.
If you’re worried about quality, don’t assume that slower work will give you better quality code. The more you practice, the more refined your system becomes and the more productive and effective you’ll be.
The book tells the story of a ceramics teacher who asks half of his class to create a large quantity of pots, and then pitted them against the other half of the class who were instructed to produce a single, “perfect” pot.
The teacher found that the students that created a large quantity of pots were producing better quality pots than the students who only had to do one high quality pot.
The takeaway according to Atwood: “When you repeatedly learn from your mistakes, (when you have more experience with a system or method), you will produce better work.”
Aside from sheer experience, you can also greatly improve your speed and productivity by either catching errors as you go through or automating the testing process.
If you can catch an error while you’re typing it, you will save ten times the effort than having to go back and redo it. But catching every single error with the human eye isn’t always possible, and that’s where automation comes in.
The purpose of automation is to provide fast feedback, both of successes and failures. The longer you go without feedback, the more time you will have to spend fixing mistakes later on.
This is also important if you have to spend time fixing someone else’s code, or they have to spend time fixing your code. The person who made the mistake understands the error best, so the sooner feedback can come through, the easier the fix will be.
So, how should you go about creating automation?
Ultimately, the best person to build a test stack is you. While this is another example of “taking more time now to make time later,” developing your own automation stack is important to improve productivity.
But think of it like this: If you were using someone else’s automation stack, you would have to learn the tools and tricks to use it, which would take more time.
You already know most of the processes you need to automate, so spend a little time on the front end of the process to build automation and you’ll save heaps of time later on when it comes time to actually produce.
The same principles apply to things like reusable libraries and templates. If you can find something (or build something) that works for you, you will improve productivity automatically.
You will also get some much needed coding experience, too.
Another area that might be slowing down your process – and one which is often overlooked by developers – is actually something that has nothing to do with you: it could be your managers or team.
If you work for an agency or in the corporate world, the slowness of your project may not be your fault, at least not entirely.
The management team plays an important role in setting expectations, helping developers manage workloads (sometimes devs don’t know how to say no), and measuring productivity.
It could be that you are producing code at a reasonable rate, but it’s only considered slow because you’re not meeting an arbitrary deadline.
Productivity like this can be difficult for management to measure objectively. They don’t always understand how much work goes into the coding process, so they assume you should be working faster.
A few questions you can ask to assess the situation to see if it’s you (or if it’s them) include:
- Am I truly inexperienced or do I feel competent in my tasks?
- How much time am I spending doing things that weren’t requested or required?
- Do I understand when a fix is finished?
- Is my code noticeably lower quality than other developers around me?
- Does management have an objective measure for productivity? If so, what metrics are they going by?
- Can they give me specific examples of slow coding or idleness or is it just a general perception?
- Have they taken into account time spent fixing other’s mistakes?
It may be that the problem is on you, and that you’re simply lacking experience or are being slowed down by your own processes. BUT, it could be that there are other factors at play that are slowing you down without you realizing it.
If so, take some time to talk with management or team members about your concerns and ask for feedback on how you can improve your processes to speed things up.
At the end of the day, a coding-heavy project will probably take you quite a bit of time and there’s not much you can do about that. It’s better to take the time you need to work through the process fully, catching bugs as you go, in order to produce something of quality the first time around.
But if you are under a tight deadline or you’re feeling pressure to speed up your work, remember that practice makes perfect and that automation is your best friend.
You should also take some time to make sure that the setbacks aren’t coming from things outside of your control, like management or team members that are costing you time fixing their errors. Take some time to gauge your situation to determine if it’s really you, or if it’s them.