Does typing speed matter for programmers?

Posted 09 July 2013 by Gary Willoughby in category Opinion, Rant with 0 comments

A few months ago Jeff Atwood blogged again about the need for programmers to be good typists. In fact he has espoused sheer disdain over the years for all programmers if they were anything less than certified touch-typists. In November 2008 he wrote

We are typists first, and programmers second. It’s very difficult for me to take another programmer seriously when I see them using the hunt and peck typing techniques.

Again, in October 2010 he continues

I can’t take slow typists seriously as programmers. When was the last time you saw a hunt-and-peck pianist?

Strong words indeed. Personally, i think he’s missing the bigger issue. The whole reason we write code is to solve a problem in software. And in order to solve such problems there has to be a certain amount of thought expended on the problem in hand. If you look a little further down the page in the comments section of the 2010 entry he states

I can type 150wpm+ on a keyboard…

Somehow, i doubt his claims because if this was the case he would be one of the fastest typists in the world.

As of 2005, writer Barbara Blackburn was the fastest English language typist in the world, according to The Guinness Book of World Records. Using the Dvorak Simplified Keyboard, she has maintained 150 words per minute (wpm) for 50 minutes

http://en.wikipedia.org/wiki/Typing#Words_per_minute

But, honestly is this really relevant? …err… No!

A simple test

I’ve just taken a few typing tests on the internet to see how fast i type. The results were that i type at about 40-45 words per minute with a minimum amount of errors, so what does this mean? Well, using Jeff’s premise the following is true

1. Typing speed equates to being a good programmer.
2. I can solve software problems at the same rate as i type.

So, my performance should be able to be graphed thus

1 2 3 4 5 6 7 8 9 10

HoursWorkedPerDay = 8; MinutesPerHour = 60; TypingSpeed = 40; //words per minute. AverageWordsPerLine = 20; LinesOfCode = HoursWorkedPerDay * MinutesPerHour * TypingSpeed / AverageWordsPerLine; print(LinesOfCode); //960 lines of code.

If you work out Jeff’s performance using the same formula you get about 3,500 lines of code a day!

But’s there only one problem with this approach, It is nonsense! No programmer will ever be able to tell you how many lines of code he will be expected to write in a day because he has no idea what is going to be encountered, so why does Jeff insist that fast is good?

With creative endeavors, such as programming, there has to be time for contemplation for creativity to emerge, there has to be thought in what you are doing. No programmer has all the answers before starting to write code and problems tend to bloom as code is written as unforeseeable issues are dealt with.

Such is the case with sculpting any masterpiece as the image on the left hints at. David by Michelangelo took roughly 3 years to complete and no one measures Michelangelo’s worth as a sculptor in ‘stones chipped per day’. No one measures an architect’s worth by the speed with which he draws a building plan. No one looks at a programmers code and measures the quality in the amount of code present or how fast it was typed.

So, when Jeff Atwood asks ‘when was the last time you saw a hunt-and-peck pianist?’ Well, never, because a pianist’s job is to interpret static instructions and to play it at the correct speed, not necessarily to think about it. The composer, however, probably worked extremely hard creating and composing that piece and the quality of music produced was not measured on how fast the composer played the piano. I can pretty much guarantee that the composer worked on that piece far in excess of the time the piece of music plays for.

As long as you can type faster than you can solve software problems, you will be fine as a programmer. 40+ words per minute is adequate to make sure typing doesn’t hinder your thoughts. Any programmer demanding that you are not as good as them because you can’t type as fast is probably showing signs of elitism.

In one study of average computer users, the average rate for transcription was 33 words per minute, and only 19 words per minute for composition. In the same study, when the group was divided into ‘fast’, ‘moderate’ and ‘slow’ groups, the average speeds were 40wpm, 35wpm, and 23wpm respectively. ‘Hunt and Peck’ typists can reach speeds of about 37wpm for memorized text, and 27wpm when copying text. An average professional typist reaches 50 to 70wpm

http://en.wikipedia.org/wiki/Typing#Alphanumeric_entry

Peer Dependencies

by Domenic Denicola, 2013-02-08

Reposted from Domenic's blog with permission. Thanks!

npm is awesome as a package manager. In particular, it handles sub-dependencies very well: if my package depends on request version 2 and some-other-library , but some-other-library depends on request version 1, the resulting dependency graph looks like:

├── request@2.12.0
└─┬ some-other-library@1.2.3
  └── request@1.9.9

     

This is, generally, great: now some-other-library has its own copy of request v1 that it can use, while not interfering with my package's v2 copy. Everyone's code works!

The Problem: Plugins

There's one use case where this falls down, however: plugins. A plugin package is meant to be used with another "host" package, even though it does not always directly use the host package. There are many examples of this pattern in the Node.js package ecosystem already:

• Grunt plugins
• Chai plugins
• LevelUP plugins
• Express middleware
• Winston transports

Even if you're not familiar with any of those use cases, surely you recall "jQuery plugins" from back when you were a client-side developer: little <script> s you would drop into your page that would attach things to jQuery.prototype for your later convenience.

In essence, plugins are designed to be used with host packages. But more importantly, they're designed to be used with particular versions of host packages. For example, versions 1.x and 2.x of my chai-as-promised plugin work with chai version 0.5, whereas versions 3.x work with chai 1.x. Or, in the faster-paced and less-semver–friendly world of Grunt plugins, version 0.3.1 of grunt-contrib-stylus works with grunt 0.4.0rc4, but breaks when used with grunt 0.4.0rc5 due to removed APIs.

As a package manager, a large part of npm's job when installing your dependencies is managing their versions. But its usual model, with a "dependencies" hash in package.json , clearly falls down for plugins. Most plugins never actually depend on their host package, i.e. grunt plugins never do require("grunt") , so even if plugins did put down their host package as a dependency, the downloaded copy would never be used. So we'd be back to square one, with your application possibly plugging in the plugin to a host package that it's incompatible with.

Even for plugins that do have such direct dependencies, probably due to the host package supplying utility APIs, specifying the dependency in the plugin's package.json would result in a dependency tree with multiple copies of the host package—not what you want. For example, let's pretend that winston-mail 0.2.3 specified "winston": "0.5.x" in its "dependencies" hash, since that's the latest version it was tested against. As an app developer, you want the latest and greatest stuff, so you look up the latest versions of winston and of winston-mail , putting them in your package.json as:

{
  "dependencies": {
    "winston": "0.6.2",
    "winston-mail": "0.2.3"
  }
}
                          

But now, running npm install results in the unexpected dependency graph of

├── winston@0.6.2
└─┬ winston-mail@0.2.3
  └── winston@0.5.11
                            

I'll leave the subtle failures that come from the plugin using a different Winston API than the main application to your imagination.

The Solution: Peer Dependencies

What we need is a way of expressing these "dependencies" between plugins and their host package. Some way of saying, "I only work when plugged in to version 1.2.x of my host package, so if you install me, be sure that it's alongside a compatible host." We call this relationship a peer dependency.

The peer dependency idea has been kicked around for literally years. After volunteering to get this done "over the weekend" nine months ago, I finally found a free weekend, and now peer dependencies are in npm!

Specifically, they were introduced in a rudimentary form in npm 1.2.0, and refined over the next few releases into something I'm actually happy with. Today Isaac packaged up npm 1.2.10 into Node.js 0.8.19, so if you've installed the latest version of Node, you should be ready to use peer dependencies!

As proof, I present you the results of trying to install jitsu 0.11.6 with npm 1.2.10:

npm ERR! peerinvalid The package flatiron does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer flatiron-cli-config@0.1.3 wants flatiron@~0.1.9
npm ERR! peerinvalid Peer flatiron-cli-users@0.1.4 wants flatiron@~0.3.0

                              

As you can see, jitsu depends on two Flatiron-related packages, which themselves peer-depend on conflicting versions of Flatiron. Good thing npm was around to help us figure out this conflict, so it could be fixed in version 0.11.7!

Using Peer Dependencies

Peer dependencies are pretty simple to use. When writing a plugin, figure out what version of the host package you peer-depend on, and add it to your package.json:

{
  "name": "chai-as-promised",
  "peerDependencies": {
    "chai": "1.x"
  }
}
                                 

Now, when installing chai-as-promised , the chai package will come along with it. And if later you try to install another Chai plugin that only works with 0.x versions of Chai, you'll get an error. Nice!

One piece of advice: peer dependency requirements, unlike those for regular dependencies, should be lenient. You should not lock your peer dependencies down to specific patch versions. It would be really annoying if one Chai plugin peer-depended on Chai 1.4.1, while another depended on Chai 1.5.0, simply because the authors were lazy and didn't spend the time figuring out the actual minimum version of Chai they are compatible with.

The best way to determine what your peer dependency requirements should be is to actually follow semver. Assume that only changes in the host package's major version will break your plugin. Thus, if you've worked with every 1.x version of the host package, use "~1.0" or "1.x" to express this. If you depend on features introduced in 1.5.2, use ">= 1.5.2 < 2" .

Now go forth, and peer depend!

The final feature set of ECMAScript 2016 (ES7)

The final feature set of ECMAScript 2016 (ES7)

Source: http://www.2ality.com/2016/01/ecmascript-2016.html

We always knew that ECMAScript 2016 (ES2016) would be a small release. It turns out that it will be very small. Read on for a list of its features and an explanation why that is not a problem.

The features of ES2016

Any proposals that were at stage 4 on Thursday, 28 January 2016, will be in ES2016 (source: ECMAScript standard editor Brian Terlson). That means that ES2016 will contain just two new features (in addition to bug fixes and smaller improvements):

• Array.prototype.includes (Domenic Denicola, Rick Waldron)
• Exponentiation Operator (Rick Waldron)

The draft of ECMAScript 2016 is online and will be ratified in 2016, probably in June.

The new release process works

ES2016 being so small demonstrates that the new release process works:

• New features are only included after they are completely ready and after there were at least two implementations that were sufficiently field-tested.
• Releases happen much more frequently (once a year) and can be more incremental.

If you are disappointed that your favorite stage 3 feature did not make it into ES2016 – don’t worry: With the new release process, it’s more about the stage a proposal is in than what release it is a part of. As soon as a proposal reaches stage 4, it is done and safe to use. You’ll still have to check whether the JavaScript engines that are relevant to you support the feature, but you have to do that with ES6 features, too.