Innovation rarely happens in a vacuum. It usually starts with an individual brave enough to contribute an idea and a team inspired enough to make it great. This blog provides a forum for all Centrons to contribute ideas, make suggestions, ask questions and inspire others. There are no boundaries. To participate, all you need is the desire to build great products.

How to be the Fastest Developer on Your Team, Part 1

Working fast is good, right? It’s obvious that getting more work done in a shorter amount of time is better than taking longer to get less done, but what does that mean? Is the fabled “10× developer” just somebody who types ten times faster?

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.

The Yak ChipperThe Yak Chipper, by Nick Nieman
We have all been caught up in the thankless chore of “yak-shaving.”

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.

Draw pictures

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.

Stay Tuned…

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.