Becoming a faster developer
(NOTE: Becoming a faster developer isn’t necessarily the same as becoming a more productive developer. Becoming a more productive developer is better. Speed isn’t everything!)
Following up on my post about typing speed, QWERTY/Dvorak/alternate layouts, and the idea that your keyboard layout probably has little to do with your performance (although it might have a little to do with your happiness), I wanted to think about what makes a fast programmer. People tell me I’m fast. I know people who can pull programs together even faster. We touch-type, for sure, but that’s the least of it.
A huge part of development speed is experience. If you’re familiar with a programming platform, the error messages, the structure, the way things work and the way things are named, you can learn new concepts and write correct code much faster than a newbie can.
What if you’re faced with a new framework? You’ll still get a speed boost if you can relate the concepts to other things you’ve learned. If you can figure out the control structures you need and the debugging techniques you can use, then it’s mostly a matter of translating to the new framework and picking up any quirks or local idioms.
So let’s break it down further. What are small, specific skills that can help a developer get really fast?
- Touch-typing: Still practically a given. You need to be able to think about your code, not about typing code. If you aren’t yet a touch-typist, sit down and work on that.
- Speed-reading: This comes in handy everywhere. Much of programming is reading: reading requirements, reading other people’s code, reading documentation, reading logs and debugging output. This is probably more useful than typing at a gazillion wpm. You need to be able to quickly spot the significant parts. Learn how to skim.
- Working with complex structures: The better you get at understanding complex structures or logic, the faster you can come up with more effective solutions, and the less time you spend going back and forth. You don’t have to do it all in your head. Find systems that work well for you (notes? mindmaps? diagrams?) and use them.
- Problem decomposition: Breaking big problems down into smaller testable steps can help you make quick progress and keep things manageable. This is also one of those skills that can give you lots of leverage on time. If you can get really good at spotting the core of the problem and figuring out the key parts of the solution, you can get something into place much faster. It’s also a useful skill for testing code thoroughly.
- Good development practices: Source code control, testing, and all sorts of other development hygiene practices means less time spent fixing avoidable mistakes.
- Collaboration: If you can get someone else to do the things you’re really slow at so that you can focus on the things you’re really fast at, the team can get much faster. This also includes documenting your work so that people don’t have to reinvent the wheel.
What would you add to this list?
Short URL: http://sachachua.com/blog/p/22178
I would personally add this:
* Think: it’s not enough that you’re writing code fast, it’s also important to be able to think through a lot of situations quickly and have a good understanding of the concepts/problem that you’re solving.
Measuring your “fastness” is also important to get a better idea if you’re doing the right things to keep being fast or if you need to be improving your “fastness”.
HTH!
As one of the best programmers I know likes to say, “10 hours of coding can save an hour of planning!” The ability to resist jumping in and starting to code before you’ve thought through what you need to do is a skill that can speed you up by an order of magnitude.
Dean, Andrew: Totally! Planning should be way up there on the list of high-leverage things you can do to become a better programmer. Also, there’s a lot to be said for the skill of being able to reuse or modify existing work (avoiding the Not Invented Here syndrome), and also being able to quickly evaluate if existing work won’t lead you down a dead end. =)
Communication’s also a key skill. Gotta make sure you can ask the right questions and understand the answers!
Use languages with simple syntax. CoffeeScript instead of JavaScript, Sass/Less/CleverCSS/HSS/Stylus instead of CSS, Haml/Jade/Slim/CoffeeKup/Markaby instead of HTML, Markdown instead of (a different case of using) HTML…
If you need to build a web app that’s basically just a neat interface to a database, skip the “backend” layer (Sinatra/Rails/Django/Express/whatever) and make a CouchApp.
Use TextExpander or something similar on your platform.
Use Vim. Seriously, I’ve been using Emacs for years and switched now. You also can use viper-mode for emacs :)
Grigory: Absolutely! Use faster tools, know your tools inside out, and figure out how to automate things.
I use vim for quick edits, but I do most of my main development in Emacs. I love the keyboard macros, the hyperlinking of grep, the snippet support, the kill ring, the ease of managing multiple buffers, the version control support…
Yep, vim buffers kinda suck, but there’s version control, snippets, macros and other stuff available on github 8)
Grigory: <grin> Vim is cool, no worries. Glad to hear people are building all sorts of extensions for it!
As a software developer I sould add:
- Environment customization: Put the tools that you use always in the same place, so that you don’t need to look for them when you need them. The default set up of a tool is not always the best one.
- Use shortcuts: The less you use the mouse the better. I’m not a very fast typer but in my job I don’t have to write for long. Usually, the tools that I use have all sort of autocompletion.
Cheers