Unsurprisingly, working quickly means more than typing as fast as you can. It means investing time up front to understand the problems you are trying to solve, and crafting a solution that will be able to evolve over time. At some point, every developer has wasted time and effort by abandoning work due to a fundamental misunderstanding of the problem discovered late in the development cycle, or because a feature of a language or framework didn’t work the way they thought.
Working fast is also about staying focused on the task you are trying to accomplish instead of being pulled sideways by distractions. And every developer has been caught up in the thankless chore of “yak-shaving”, solving extraneous problems preventing them from completing their actual goals.
Being able to write software quickly and effectively often requires you to delay the gratification of starting now while you make sure what you build will do the right thing and the tasks can be completed smoothly. Planning ahead, mastering your work environment, and executing your work in discrete steps are keys to working fast.
What’s the point, anyway? Why not just work for as long as it takes to get it done? There are lots of reasons. If you collaborate on a shared codebase with your team, you want to work fast to avoid overlapping with the work of others.
Businesses always need work done as quickly as possible to keep costs down. But the best reason is the personal satisfaction of finishing a task before it starts to get boring. The dopamine rush of knocking work out and moving on to a fresh new task is what makes work fun. So now that we’ve talked about why, let’s talk about how.
Know what you’re building, and why
Wasted effort is one of the biggest drags in software. Spending days building something only to find that it doesn’t match what the user actually needs means you’ve wasted time, money and you’ve probably taken a big hit to your morale in the process.
How do you avoid this? Take the time to understand exactly what you are building and why. Knowing this is every bit as important as knowing how to write the code to build it. When working with a team, it’s even more important since the work of many people working in parallel needs to fit together in the end.
Think like your user
Keep the motivation of your user in mind as you work through your problems before coding. It’s very easy to get caught up in the details of low-level implementation, or fall in love with a technical solution that slips out of alignment with the needs of the people who will be using your software. Your end user doesn’t care how your software works, they only care that it does the thing they want it to do without wasting their time or energy. Trying to remember what’s most important to them while you plan will help you understand what to spend your limited time on.
Talk through the problem
Discuss the problem with your peers to weed out inconsistencies in understanding of the problem between team members. If everyone has a shared understanding of the problem from the outset, you will avoid having to restate the problem to members with an incomplete or incorrect interpretation, or worse—throw away and re-do an incorrect implementation.
Know how you’re going to build it
So you’ve figured out the problem you’re solving, and now it’s time to bust out your editor and start coding, right? Well, no. Not so fast. Did you think about how all the parts will fit together? Did you think about how it might need to grow in the next iteration? How might it break? If there are external dependencies?
Sometimes if you want to go fast it’s important to start slow, and make sure you’ve got a clear path to your goal. It might help to have other members of your team to help knock around your ideas. Many times you will find that your peers have considered an aspect that you have not, or vice versa. Your work will benefit from being scrutinized early and often, and you will save time by turning up issues before you even start coding.
Drawing up a visual representation of a solution on a whiteboard while discussing it with your team crystalizes a shared understanding of both the problem and its solution, and exposes flaws in your design much faster than writing and testing code. With just a little practice you’ll find that you can iterate on an idea much faster on a whiteboard than you can in code.
Don’t overthink it
While thinking about architecture and solving problems on the whiteboard can be useful and in some cases even fun, start building sooner rather than later. You will miss details while planning at a high level, and the only way to catch some of those oversights is to run into them while the big picture is fresh in your mind.
In this post I talked about taking time to understand the problem and plan your work before you even begin coding. In the second installment, I’ll give you some good advice about how to actually code faster by mastering your code and tuning your work environment for speed.