If I were to compile a list of things I believe have the potential to make you a better coder, typing speed would very likely not even make it. Getting any sort of benefit from your amazingly high WPM output assumes you actually have something to type, which is – at least for me – most of the time not the case when programming. I spend much more time thinking about what to write and where to write it than I do actually typing. Does it then matter that I can, after an hour of investigation, write that 1 line fix in n seconds as opposed to n + 1?
n + 1
If you feel like your typing speed is holding you back, then by all means invest time in getting better at it. But if not, there are so many other areas you can focus on – like reading and understanding other people’s code – that have a much higher chance of making a better (and more efficient) coder out of you.
I remember reading that 80 percent of our time on a project is reading instead of writing code.
.. and thinking about the solution. that is also why i don’t get the “using the mouse makes me slow” argument. especially when some things are faster using the mouse, given the right tools :)
When is using a mouse faster?
The mouse is a very fast way to make a precise selection from fuzzy data.
For instance, I’m often looking at outliers on a heatmap graph. Selecting a group of outliers to investigate with the keyboard would be slow and error-prone; mouse selection is near-instant.
Over in radiology, a mouse is a popular way to adjust the windowing function used to render a scan (by adjusting the window size on one mouse axis, and the midpoint on the other). This would also be slower and more error-prone with a keyboard.
I find using mouse easier for switching between multiple files. Looping over dozens of windows is a nightmare with keyboard. Don’t suggest using a shortcut to focus window by its title, usually I don’t remember them.
Also, sometimes touchpad is faster, e.g. with Force Touch on MacBooks you can instantly look up the definition/translation of the word.
And so are touch screens. Using keyboard/mouse/touchpad is so inefficient after arranging windows with your fingers! Tiling window managers are not panacea.
And, ahem, how would you play DOOM on 9front without mouse?
If I have too many windows open, I close some, or otherwise put them on different monitors or virtual desktops for instant navigation with shortcuts. Each to their own, of course. The main things I can’t not use a mouse for are FPS games and DAWs.
I first played the PSX version of DOOM, and a little later, a keyboard-only version. Vertical aiming isn’t necessary at all, and it’s perfectly serviceable without a mouse!
navigating in text is done faster using the mouse when jumping more than a few lines/words, even when displaying relative line numbers in vim.
acmes mouse chording is really nice to use and required only a short time to become used to. i still wish copy/cut/paste would work like this everywhere. maybe modified a bit for the current mice, clicking with the wheel isn’t that great.
If I were to compile a list of things I believe have the potential to make you a better musician, your ability at sight reading would very likely not even make it. Getting any sort of benefit from your amazing sight reading skills assumes you actually have something to play, which is—at least for me—most of the time not the case when playing music. I spend much more time thinking about what to play and when to play it than I do actually playing. Does it matter that I can, after a week of studying, play this piece 120bpm as opposed to merely 100bpm?
If you feel that your musical reading ability is holding you back, then by all means invest time in learning solfège. But if not, there are so many other areas of musicianship you can focus on—like listening and understanding other people’s music—that have much higher chance of making a better (and more virtuosic) musician out of you.
This is a very emotional, but not very useful article.
At close inspection, the article falls down to:
That’s it. It doesn’t go into details in how much of the main skill “coding” typing makes up and it doesn’t go into details whether improving in this area is easy or hard.
There’s a classic exercise in business to analyse scale situations: given a number of interconnected metrics, how much does the overall performance change if an individual metric changes by 1% up and down? But without even having a rough gauge what makes up the skillset of coding, we can’t even have these discussion properly.
I would say that improving your typing speed should be fairly easy if you are on the low end of the spectrum, it’s certainly a case of significantly diminishing returns as you get higher in the spectrum.
Fair points, though.
Sure, but that’s the start of a much more subtle argument.
I know some people that argue for typing competence because it reduces mental strain. So they are not about the speed, but about being able to do it as a background task. Now, that’s something I buy in.
Reducing mental strain and being able to type as a background process is a great way to put forth this argument.
I’ll definitely do some thinking on that in order to improve. Appreciate the discussions here, can always count on lobsters to contribute good points!
Even if this argument is reasonable, which the other comments here convincingly refute, this is also concerningly close to “between two otherwise equal candidates, always hire the more physically able-bodied.”
If you want results, then you probably need to hire the more physically able bodied. With that said, hiring less physically able bodied people is an important part of any system so that we try to be as inclusive as possible to everyone.
My only point being that you could claim “able bodied” in almost every aspect, including ability to code mentally.
Good software is accessible, and accessibility is a result. Who better to judge and craft the accessibility of software than a physically diverse group of engineers?
Oh absolutely, wasn’t debating that it wasn’t important.
As a programmer, the author ought to know better than to micro-optimize. Typing speed is not the bottleneck in programmer efficiency. I spend most of my time thinking and type only occasionally, and I can type at 130+ WPM. Some of my most talented and productive colleagues don’t even break 50 WPM.
What nonsense. As if the speed of hammering code into an editor says anything about the abilities to program…
In the post I’m very clear that it relates to all aspects of coding, not just writing the code. That is to say, writing commit messages, writing commands, communicating with remote team mates, searching online for answers, etc. There are a lot of aspects to the daily code cycle other than just typing code itself which still involve typing.
But I appreciate the comment.
You mix up a personal metric of “productivity” (producing certain amounts of text by a keyboard in a certain time) as an indicator of quality and I can tell you from personal experience that this is utterly wrong. What makes you a better programmer is reducing the amount of typing through automation and thus making superfluous typing unnecessary.
I mean, I could also tell you the opposite from “personal experience”. It’s difficult to make arguments based on that.
What kind of automation are you talking about in this regard?
People are all very quick to point out how great reducing friction is when they’re using a faster compiler, faster tests, when they’ve achieved fluency in vim or emacs or whatever, but everyone always jumps to tell you to just think harder if you say typing fast matters. I don’t get it.
I would like to hear an “it doesn’t matter” post from someone who went from slow typing to fast.
But all the ones you mention above are challenged! The Rust community has tons of people that hold the opinion that compiler speed doesn’t hold them back!
And the point is also not “slow to fast”, the point is “if you are already mediocre at this, should you invest more time”?
The Rust community has tons of people that hold the opinion that compiler speed doesn’t hold them back!
The Rust community has tons of people that hold the opinion that compiler speed doesn’t hold them back!
I’m surprised to hear that, it’s been my experience that the slow compile times are very frustrating for rapid iteration because running the tests takes so long. I’m talking specifically about cargo test and similar, things that cargo check doesn’t help with because it only detects compile time errors.
I mentioned this a while back when cargo -Z timings came out, a surprising amount of the compile time after the first initial build comes from link times: https://internals.rust-lang.org/t/exploring-crate-graph-build-times-with-cargo-build-ztimings/10975/7
cargo -Z timings
Yep link time is non-trivial. lld can help here if you’re on a supported platform. E.g. here’s a 50% reduction in debug build time on a game. Here’s an example by the Embark game studio for how they speed up compile times with lld on Windows.
Some people just don’t care about rapid iteration that much. If you do, yes, it’s a problem.
This is an excellent point that I wish I had detailed more clearly in the post. It certainly feels odd that people will optimize so many of these other areas of friction, but then say that improving typing is not valuable.
I’d rewrite it with those things in mind. There’s tangible benefits to improving typing and it is a valuable skill, but giving some guidance on what should trigger you to improve on typing would be great!
[…] the infamous Jeff Atwood […] on his controversial blog
[…] the infamous Jeff Atwood […] on his controversial blog
This is the first time I’ve heard Atwood described as “infamous” and his blog “controversial”. Apart from daring to run StackOverflow on a MS stack, he’s as milquetoast as they come.
I’m not sure which cycles are in, but Jeff Atwood is generally considered very poor when it comes to writing in mine. He has an opinion on everything, rarely had insight that can’t be had elsewhere (especially on social topics) and does not fact-check very well. That’s not the bad part, his blog is to a part entertainment and he’s rally good at that. But he very dismissive when criticised and facts he got wrong are pointed out, and that’s where the air comes from.
This is certainly what I meant when I wrote that. Jeff definitely seems like a very divisive and controversial writer. I’m a fan of his content; but it’s clear to me from my circles of other programmers that other people are not fans at all.
So I would certainly say he’s pretty controversial.
I think typing speed matters. Not a whole lot, but it matters. Not in finding a bug, not in reading code, but when you, occasionally, just need to bash out some boilerplate. It also works for writing prose which I believe many programmers should do (even if it’s just documentation or comments).
When I ask some of my more experienced coworkers something, they talk while they type something like
and before the end of the first line of their answer they can point at the relevant line of code and answer my question. Gary Bernhardt types pretty fast, and I think it really helps in how fluent his screencasts are. See https://www.destroyallsoftware.com/screencasts (there is a free screencast – I don’t think they are regularly updated so I wouldn’t go for a subscription but there’s great content there so it might be worth it to subscribe once and download everything).
That being said, chances are there are much more efficient ways to get better at programming.
Good points. I think the point I was trying to nail home here was that, when you are starting to learn programming, in my opinion the best way to learn is by doing. You should be coding as much as possible and learning from your mistakes and iterating, while studying how to write better code.
If we take that as realistic, then say, if you type 40 WPM and it’d take 5 days to increase your typing speed to 70 WPM, then that’d be a worthwhile investment long term because you’d get more of that learning by doing done.
If however, it’d take 6 months to increase your typing speed that much, perhaps that’s not a worthwhile investment anymore.
Certainly, every individuals situation is different and people have different bottlenecks.
This conclusion is reversing causality - when you know exactly what you are doing you gain confidence and start typing faster. What actually matters is having low friction in managing your windows into the codebase and being able to reconfigure your perspective freely and effectively. Being fast at executing such commands means they have become second nature to you which means faster ‘typing’ but more importantly it means lower perceived effort for conducting experiments.
There is something to this the author did not point out. Typing faster is less frustrating than slow typing when you feel the flow. Faster typing enables faster use of tools, even if the mouse were occasionally involved.
Depending on your programming language and tools, faster typing allows you to “think out loud” in code and tests. It may even drive you to make the dev cycle faster.
Pair programming is more fun and efficient when you don’t spend time on slow typing, and eventually you may even talk while writing out the code, like a singing instrumentalist.
And in a lot of work, any task really isn’t that unique. Doodle some diagrams and start prototyping by typing fast.
Contemplate old code and fix it by typing fast.
Even if the seconds saved never amount to much real time, there’s an energy to it that should not be discounted.
I agree with all your points – there is a certain energy that abounds when someone masters their tools and can operate with fluency in the physical world. I personally don’t think it should be a subject of controversy that proficient use of the primary computer input device makes one a more proficient user of the computer – it’s easier to get into a flow state, it’s easier to use tooling, and it’s easier to communicate with others.
If you’re a faster typist, you might find it easier to spare a couple seconds writing that email to a remote colleague that might just flip their day from bad to good. You might spare a couple seconds to comment that tricky bit of code before moving on. You might spare a couple seconds typing out repetitive test cases instead of DRYing them prematurely and making others cry when they have to add functionality. If typing feels like a slog, you’re going to be more stingy with written communication in general.
But, I also have a meta-comment about topics like this. People who aren’t fast typists will be the ones piping up in the comments about how typing speed doesn’t matter, and those who type well will say that it does matter. Confirmation bias is a thing, and ultimately I think it comes down to aesthetics. I know a couple of programmers who are atrocious typists—to the point that watching them type is painful—but are excellent at programming and ultimately very productive. Maybe they just don’t feel they need the ‘energy’ that comes with mastery of physical movement?
These are some great additions to the discussion. Having less of that barrier as you said may also result in you being more likely to communicate when you otherwise wouldn’t have because it’d have been such a slow and tedious response as a slower typist. Stuff like this is very difficult to measure because essentially it all happens in the mind and perhaps unconsciously for many.
I also agree with the point about confirmation bias. Of course I say you should type faster because I do type relatively quick. My colleagues who type quick also say this. My colleagues who don’t type quite so fast tend towards finding it less important. Either way it could be post ad hoc rationalization.
This is a great point and highlights how I feel, and I didn’t include it in the article!
For example; I find it very difficult to even get into a flow state when typing on my phone, where I probably get something like 50 WPM, simply because it feels so frustrating. Even talking to people on my phone via typing feels so frustrating I often can’t be bothered.
Whereas on a real keyboard, I’m far more likely to take the time to reply to people or write more complicated responses because that barrier is so much less existent.
I find that my single most useful skill as a programmer, excluding any and all social aspects of software being a community endeavor, is my ability to read, understand, and navigate code that is not mine. I put those three together because to trace a program, you need to be able to understand what file to jump to next. Also to know what to change in the program such that it can do what you mean it to, without looking like the Potato Jesus restoration project.
For those to whom “Potato Jesus Restoration” is not obvious, it’s a reference to a botched restoration of a painting. https://en.wikipedia.org/wiki/Ecce_Homo_(Mart%C3%ADnez_and_Gim%C3%A9nez,_Borja)#Failed_restoration_attempt_and_internet_phenomenon
Being efficient in an editor helps as well. I can put the desired code on screen faster using vim than with other editors, while keeping the same WPM.
This is a great point too and is part of the greater argument of “reducing friction”.
I took me 5 hours one day to find and fix a bug that ended up being a one line change. Typing faster would not have helped me in this case, or many like it.
That can be a useful attitude if you need to run a lot of experiments to understand how a program is working.
From what I know, the only thing that really cares about your typing speed, is competitive programming. And you have to be good at it to get any real benefits. There you probably already know the solution, you just need to write it down, and sometimes those few seconds saved by quick typing can matter. But anywhere else - I haven’t seen any difference.
The faster you can type the more time you can spend thinking and not typing?
I don’t think the extra couple of seconds of thinking are the relevant part. Personally, if I have to use a slow input method I quickly feel frustrated, which makes it harder to stay engaged with what I’m doing.
OTOH I know at least one developer who is completely unbothered when her keyboard latency is 200ms (which… I can’t imagine doing for more than a few minutes voluntarily).
Would you rather think 5% faster or type 5% faster?
Well, are you able to actually think 5% faster? Is that something you can improve? I’m not so sure about that.
Assuming you’re already at a high level of coding comprehension, I’d say being able to improve your thinking speed in relation to this might be a very difficult task.
I think it’s way more important to know how to touch type  than to type fast. If you have to hunt-and-peck to type, that will certainly slow you down in trying to type in your ideas. But as long as you can type without having to think about where the keys are, the better.
 And I’m not talking about typing “correctly” either. One of the fastest typists I know uses a weird three-finger method that isn’t proper “touch typing” as taught.
If you are on a team that communicates through slack, email, irc, or docs, or wiki, etc. typing faster can help you communicate faster.