October 28, 2015
Focusing On Typing Speed Not Only Misses The Point, But Can Exclude Talented DevelopersAfter harumpty-three years of programming computers, I've long ago abandoned the notion that how fast I can type out code is a limiting factor on how soon I can deliver valuable working software.
Typing, as an activity, is a such a tiny part of what software developers do, that you could be a really slow typist, working in a clunky language full of redundancy and clutter - like Visual Basic - and still get more done than someone who can bash out 100 w.p.m in a tight, streamlined language like Ruby or Haskell.
If you don't believe me, look back at your commits for the last week, count the number of words you typed, and divide that by the number of minutes you worked. I average about two words a minute, which adds up to about 800 LOC a week, or 40 KLOC a year.
Now, my boss - who's sitting with me right now - may mistakenly believe that I must be pressing a key once every thirty seconds. And 40 KLOC doesn't sound like very much at all, until you qualify that with "on legacy code, which most developers spend most of their time working on, in a team, with customers and so on". In other words; real software development, with all the usual obstacles. Starting with a clean slate, working alone, with no customer to seek input and feedback from, I move faster - maybe 100-200 KLOC a year. But, arguably, a lot faster towards solutions of less value. Which opens up a whole debate about what "developer productivity" is anyway...
My actual typing speed - out on the open on a flat surface with the wind behind me - is about 30 w.p.m. What's actually happening here is that I spend very little of my time - less than 5% - typing code.
If I was a 60 w.p.m typist, my productivity - in terms of working software delivered - would not double. It would barely change, because how much I achieve per hour/day/week year is not constrained by the physical act of typing in the code to any appreciable extent. An average of 2 w.p.m. is a reflection of how fast I make decisions about the code. Every line of code contains decisions - names, types, dependencies, formulas and expressions, strategies for solving problems etc. And then there are all the changes: I rarely leave a line of code untouched once it's been written. Refactoring accounts for a lot of the time I spend working on code.
But - and this is backed up by a mountain of evidence - by far the bulk of mine and most developers' time is spend reading code; typically between 50-80%. Which is why my efforts are most focused - after worrying about whether or not it works - on how easy the code is to read.
So, maybe 5% or less of my focus is on write-ability of code, compared to 50% or more on readability. To put it more bluntly, readability matters 10x as much to me.
But our ingénue profession still obsesses mostly over write-ability of code, not on readability. And those of us who can look back on many wasted years servicing this obsession - and it is years, over the lifetime of a career - may sound the warning bells for younger developers still chasing the illusion of productivity. But, it seems, the message "go slow to go fast" still hasn't broken through into the collective Developer Borg consciousness, even within the software craftsmanship community.
But, hey, it's your time and your customer, and who am I to say how you should waste it?
Where I do have a problem, though, is in how this obsession with how fast we type the code can exclude developers with disabilities that make faster typing an impossibility.
I've coached and mentored developers with disabilities, and the first thing I learned is that as much, if not more, can get done. Typing isn't the bottleneck; thinking is the bottleneck; feedback is the bottleneck; cost of change is the bottleneck. Typing is, at worst, a minor irritation to impatient people.
In the UK, and many other developed nations, you're not allowed to discriminate against a software developer on the grounds of disability. But, sadly, I've seen teams do exactly this, entirely on the basis that they are too slow at typing. "They wouldn't be able to keep up. Nobody would want to pair with them. They'll hold the team back."
It's bullshit. And dangerous bullshit, because it restricts opportunities to some very talented developers, which is bad news for them and bad news for you and bad news for the world who could have benefitted from the fruits of their labours.
Just as we need to get past the face-time culture of many development organisations to open the doors to talented programmers with other commitments, like parenting, we need to get past this obsession with typing speed because:
a. It really doesn't make much difference, and
b. It focuses us on an relatively unimportant skill that can exclude some really great developers from joining the party
10 w.p.m. is plenty. It's 5x what you need. It's not they who need to speed up. It's we who need to slow down. Take a deep breath, and focus on the stuff that makes a difference. Hey, maybe think about the problem a bit more? (I know - kerrrrazy!)
Posted 13 hours, 5 minutes ago on October 28, 2015