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 2

How many times have you found yourself with fifteen open buffers in your text editor, failing tests all over the suite, your diff size creeping up over 1000 lines, and no idea where to start fixing the stuff you’ve broken just trying to finish a single feature?

In the first part of this article, I wrote about taking time to understand the problem and plan your solution before starting to code. Now, I will discuss how to actually work faster by mastering your code and work environment.

Master your code

Starting too many tasks at the same time exit strategy is a great way to get bogged down. Try to break your work down into independent tasks and complete each task in turn. This is harder to do than it sounds!

Commit early/often

You wouldn’t write a long paper in a word processor without saving often, right? Committing your changes to source control early and often makes it easier to undo mistakes. Giving yourself the safety net of freshly committed work means you can quickly try out ideas and throw them away if they don’t work, just by resetting to your last commit rather than backing out changes. Don’t worry about making each commit make sense. Tools like Git’s interactive rebase make it possible to clean up your work before you upstream the commits.

Don’t divert yourself

When developers do get bogged down, many times it is because they’ve uncovered new dependencies that need to be addressed in order to finish the task at hand. It’s a real challenge to balance solving these newly discovered blockers against finishing the task at hand. The best approach is to only solve the minimum needed to keep moving forward on the original task.

Sometimes it can be just as effective to stub out a solution with a call to an unimplemented method, and make sure you leave a failing test to remind you to go back and fill in the functionality later. Like most of the practices in this article, repetition and refinement of your technique will help you judge how much of a problem to solve at any given time.

Keep your tests passing or skipping

Good test coverage is critical to having the confidence to work quickly because you can easily determine if things still work. When undertaking large efforts, it’s sometimes impossible to keep your whole suite passing at once. If you can keep track of why any failing test is broken, it makes it easier to spot unintentional breakage. Most test frameworks give you a way to skip intentionally broken tests, often including an explanatory message so you can remember why they were skipped in the first place. If you keep your efforts focused and only break what you have to in order to get to your next commit, you can avoid getting lost in your own breakage.

Know your code editor

Whether you use Vim, Emacs, Sublime Text, Rubymine or any other programming editor more sophisticated than TextEdit, there are ways you can customize your editor to help you move faster. The more of your job you can do from within your editor, the less often you need to switch context away from it and lose valuable time. Using plugins and extensions to customize your editor to be more aware of the languages and frameworks you use will smooth out your workflow and give you coding superpowers.

Run focused tests from the editor

Being able to run focused tests from inside your editor is one of the simplest and most effective ways to check your work with minimal interruption. As a rails developer who codes in vim, I use Thoughtbot’s vim-rspec, which gives me keyboard commands to fire off a single test or run the whole file.

Know your testing framework

The deeper your knowledge of your testing framework, the faster you can work. Most common testing needs have been anticipated by mature frameworks. I use and endorse rspec for Ruby programming, but Ruby’s own Minitest (formerly known as Test::Unit) works just as well. Learning the best practices recommended by the designers of your testing framework will keep you operating in alignment with their intention.

Don’t tolerate slow tests

Slow tests kill productivity. If you can validate your work in real time, you can keep your mind on the task at hand. Take time to make sure your tests run as fast as possible by avoiding unnecessary setup and teardown tasks, writes to the filesystem, or operations that use the network. Slow tests can also be a symptom of architectural over-coupling that can prevent you from moving quickly. Keep your your tests small and single-purpose, and delete redundant tests without hesitation.

Read source code

Learning how to read other peoples’ source code is a challenge. No two developers think exactly the same, and learning to figure out what was in the original author’s mind when she wrote the code you’re reading will make you a better programmer. Reading code written by more experienced programmers will also help improve your code. Don’t be afraid to dive into your framework code either. A deeper understanding of the work you build on top of every day can only help you move faster.

Ask for help when you get stuck

Nobody likes to admit that they’re stumped by a problem, and puzzling through a tough spot is one of the best ways to learn. But there comes a time, sometime after about an hour of struggling with a bug or a tricky piece of code, when it’s time to seek help. Two sets of eyes are better than one, and even just explaining a problem you’ve run into to another person will cause you to suddenly see the solution. Pair programming is a very effective way to avoid getting stuck, especially when the two members of the pair have skills that complement each other rather than overlapping.

In Conclusion

A lot of what it takes to work quickly in software development actually starts with moving slower early so you can proceed quickly later. Understanding the problem, getting your team a shared understanding of both the problem and approach to solving it, and skilled use of your tools take time up front but the end result is less rework, productive velocity and an end result that meets the needs of your users sooner.