This sort of optimization is a pretty foundational concept for software engineers. These are things that have helped my career as a software engineer and made me more effective in my job (not exactly the same thing, but related!):
Basics
Touch typing. This should go without saying, but I’ve worked with people who hunt and peck and it’s painful to watch. But you don’t have to type really fast to get most of the benefit, since other bottlenecks will start to dominate. In my experience a pokey 50 WPM is more than sufficient.
More Advanced Mechanics
Gain fluency in a powerful shell, a good text editor, and an expressive “scripting” language
Learn a modern version control system such as git
Set up an environment that works for you and keep improving it – this is very much along the lines of Nick5a1′s systems mindset. Keep your dotfiles in version control.
Looking back at this, I’m realizing that a lot of these suggestions are more plain old advice rather than force multipliers. The true force multipliers are proficiency with tools, continually investing in improving your workflow, and probably certain people skills like delegation and team-building.
Touch typing. This should go without saying, but I’ve worked with people who hunt and peck and it’s painful to watch. But you don’t have to type really fast to get most of the benefit, since other bottlenecks will start to dominate. In my experience a pokey 50 WPM is more than sufficient.
I don’t touch type, and my typing speed is about 65 wpm. Do you think learning how to touch type will result in a significant increase in speed, enough to be worth the effort?
I’m an academic, so typing speed is probably not as important for me as it is for a software designer, but I do a lot of writing, so it is a potentially significant productivity boost.
Yes. Speeds of 100wpm are not particularly hard to reach with deliberate practice. The benefit is not the time savings of typing less, it’s the cognitive savings of spending your attention on your topic rather than the mechanics of entering text and correcting errors.
As pushcx said it’s not about speed as much as not having to pay attention to what your fingers are doing (and crucially, being able to look elsewhere while you type). The bottleneck isn’t bandwidth but the size of your L1 cache.
This sort of optimization is a pretty foundational concept for software engineers. These are things that have helped my career as a software engineer and made me more effective in my job (not exactly the same thing, but related!):
Basics
Touch typing. This should go without saying, but I’ve worked with people who hunt and peck and it’s painful to watch. But you don’t have to type really fast to get most of the benefit, since other bottlenecks will start to dominate. In my experience a pokey 50 WPM is more than sufficient.
More Advanced Mechanics
Gain fluency in a powerful shell, a good text editor, and an expressive “scripting” language
Learn a modern version control system such as git
Set up an environment that works for you and keep improving it – this is very much along the lines of Nick5a1′s systems mindset. Keep your dotfiles in version control.
Don’t repeat yourself. Learn to refactor code to remove unnecessary duplication.
Keep configuration decisions out of code
Understand dependencies among different pieces of code and know a few strategies for simplifying them (the pub/sub or event bus pattern, dependency injection, etc.)
Know how to deal with asynchronous operations using both callbacks and promises – NodeSchool has a great tutorial for server-side JavaScript.
Soft Skills
Keep a todo list (I keep my own, or you can get really good with your issue tracker)
Keep a log of things you’ve done (bonus if you can generate the log automatically from your todo list)
Keep notes on how you solved tricky problems
Understand your role (you’re not a designer or product manager, but you need to know what they care about to work with them effectively)
prioritize the product, then others’ goals, then your own (this is usually the most effective way of furthering your goals)
insist on regular one-on-one meetings with your manager
before answering a question find out why the question was asked
Looking back at this, I’m realizing that a lot of these suggestions are more plain old advice rather than force multipliers. The true force multipliers are proficiency with tools, continually investing in improving your workflow, and probably certain people skills like delegation and team-building.
I don’t touch type, and my typing speed is about 65 wpm. Do you think learning how to touch type will result in a significant increase in speed, enough to be worth the effort?
I’m an academic, so typing speed is probably not as important for me as it is for a software designer, but I do a lot of writing, so it is a potentially significant productivity boost.
Yes. Speeds of 100wpm are not particularly hard to reach with deliberate practice. The benefit is not the time savings of typing less, it’s the cognitive savings of spending your attention on your topic rather than the mechanics of entering text and correcting errors.
As pushcx said it’s not about speed as much as not having to pay attention to what your fingers are doing (and crucially, being able to look elsewhere while you type). The bottleneck isn’t bandwidth but the size of your L1 cache.