
Non-blocking Programmers - srikar
http://codingrelic.geekhold.com/2011/03/non-blocking-programmers.html
======
keyist
_"Ability to type quickly and accurately maximizes the effectiveness of time
spent in the flow of programming. Hunting and pecking means you only capture a
fraction of what could have been done."_

I submit that typing speed matters, but only as a component of what I'll be
unoriginal and call actions per minute ( _significant_ APM, to be precise).
More important components of SAPM would be pushing blobs of text around
(editor knowledge) and manipulating/filtering blobs of text efficiently (Unix
toolchain).

A 60wpm developer who uses rectangle commands and pipes a portion of buffer to
shell to transform it may have higher SAPM than a 150wpm developer ignorant of
the various shortcuts available.

To further flog the RTS analogy: typing speed and keyboard shortcuts that
operate on one line are micro. Regex replace, sed/awk-fu, multiple buffer
usage, etc are macro. To be an efficient dev both are necessary but not
sufficient -- all the micro and macro in the world can't save you from brain-
dead decisions.

~~~
lucisferre
I not sure the author disagrees with you here, however he doesn't specifically
come out and say it and I can't really read his mind. So let me attempt to
reword it anyways.

Being _proficient_ with the editing tool(s) of choice is of significant
importance to productivity and keeps the natural flow and rhythm of the
thought process while working. Hunt-and-peck is absolute crap, however,
likewise anything over say 50wpm in concert with solid knowledge of the
shortcuts and meta commands available is going to be sufficient to achieve a
good working rhythm.

The premise the author made that I completely agree with is that touch-typing
(i.e., not searching for the keys) is not an optional requirement for a
productive programmer. I am mildly shocked that there are people on HN (not
yourself obviously, but I've read through some of the comments here, and in
other posts) who get worked up about this and actually get up-voted for
defending it.

~~~
GrooveStomp
I was astounded when I noticed a coworker using hunt-and-peck typing. I simply
don't understand how a professional who is passionate about their work can not
spend the time to master their tools - especially one as fundamental as a
keyboard for someone who uses the keyboard 8+ hours a day.

------
dexen
_> Developers with a curiosity about their craft grow into better developers.
This takes time away from the immediate work of pounding out code (point 1),
but makes one more effective over the long run. _

This is something I wholeheartedly agree with. On the surface it seems to be
an opposite of a `The Duct Tape Programmer' (whow gets the job done quickly
when it matters most) -- but probably that's matter of self-discipline and
having the goals set straight.

Now the question is, how do I pick such programmers in an interview? The ones
that are curious about our craft, yet self-disciplined?

~~~
Two9A
This gets said a lot, by many people, but: by checking their open-source /
publically available work.

If someone's managed to complete a significant task, and the code looks
readable and reasonable, they're probably fair decent programmers. Even better
if they've got code Out There in multiple languages; that shows a broad base
of both knowledge and experience, in my opinion.

~~~
dexen
That's half the answer, I'm afraid. Anybody with a bunch of time on their
hands can churn out quality code. The other half -- self discipline to ``duct-
tape your way through'' when in crunch mode -- is not covered by reading
sources.

Now that I think of it, another angle comes to my mind: once you're done with
the crunch mode, you need to get back to the duct-taped mess and mop it up. If
working in an organization, it's mostly communication problem -- you need to
explain to your boss why you absolutely must rewrite what works now. Not only
taking time, but also risking introducing new bugs.

~~~
arethuza
You'd be surprised.

For the least few years the place I'm currently working has used a remote
development exercise as the first filter for applicants - send a simple
programming task that should only take an hour or two and look at the results
that come back.

50% of applications get rejected based on a quick skim of the code submitted -
not for subtle reasons either, with the most common problem being solution
complexity that is wildly disproportionate to the complexity of the problem
(especially when the notes on the task explicitly warn against this).

------
Swizec
The real question to ask is this: By reading this article, how much time have
I wasted?

Sure, it took a few seconds to jump through my RSS reader, yep, it took a bit
of time to read it because it's an interesting article, and obviously, I am
now here, writing this comment and thinking whether I should inflict the link
on my twitter followers, perhaps even on facebook.

And then the coup de grâce at the end of the article itself

 _> There are other factors relating to flow which can be optimized. For
example one can block off chunks of time_

Well oops?

In general, the internet _sucks_ for productivity, but at the same time it's
really really hard to code without it.

~~~
dexen
The internet itself is neutral, only gives high leverage to your actions.
Feeling like procrastinating? It'll get multiplied 100-fold. Searching for
something useful? It'll get multiplied as well.

~~~
Swizec
The problem lies more in this sequence of events

1\. Searching for something useful

2\. Page takes a while to load

3\. Better use this opportunity to check HackerNews (or whatever)

4\. Waste 10 minutes

5\. Oh yeah, that site already loaded.

~~~
danohuiginn
good point on the page-load thing. I wonder if some small technical tweaks
could substantially change our behaviour here. Something like automatically
flipping back to whatever page you were waiting for, as soon as it's finished
loading.

~~~
dexen
To a degree, that can be fixed behaviorally. I tend to open outgoing links in
background and continue reading the current document. Once I'm done with
current document, I'll close tab and a fresh tab with (hopefully) already
loaded content will slide in.

For example, a quick glance over HN's main page, followed by opening
interesting stuff in background, followed by closing the main page.

Doesn't work too well with footnotes, thou.

------
jerhewet
Typing speed is completely irrelevant.

When I'm keyboarding in "stream-of-consciousness" mode (IM session, taking
notes, etc.) my typing speed is well north of 160WPM. But when I'm writing
code I type in fits and bursts -- a blur of fingers for a while, then blurs
with small gaps of silence, then blur-peck-peck-pause-peck-peck-blur. Lather,
rinse, repeat.

I'd bet most programmers exhibit this behaviour, but are (for the most part)
unaware of it.

~~~
danohuiginn
160wpm? Really? You're into world record territory there:
<http://www.owled.com/typing.html>

~~~
jerhewet
I spent close to 8 hours a day for almost two years in front of one of these
when I was first starting out:

<http://www.columbia.edu/acis/history/univac1710.html>

Which is why I emphasized "stream-of-consciousness". When you're doing that
much data entry (U.S. Navy, destroyer tender, circa 1975, btw) you quickly
learn to let muscle memory take over while your mind is elsewhere. Hell, I was
one of the _slower_ typists in the shop -- there were guys around me that
could consistently cruise through work orders at 200WPM or more!

------
83457
blocking: answering customer phone calls

Anyone else in a small company and get constantly interrupted?

~~~
dpritchett
I wrote a sweet python tool (log parser/highlighter with a web interface) last
week that lets my users answer many of the questions they were previously
calling to have me look up for them.

Net result: daily time savings for both parties and more time in the zone for
me!

That and I now know a lot more about Python than I did two weeks ago.

------
ChrisAnn
Typing is not the bottleneck: [http://sebastianlab.com/post/140303165/typing-
is-not-the-bot...](http://sebastianlab.com/post/140303165/typing-is-not-the-
bottleneck)

~~~
lucisferre
He isn't saying typing is a bottleneck, read the actual paragraph under the
poorly written header. He is saying hunt-and-peck is terrible for productive
flow and thinking and that touch-typing is important and valuable.

Even when pairing and taking time to think, obtusely slow typing from a
partner is frustrating and distracting for me. If someone can't be bothered to
learn how to use their tools well, they should find something to do they
actually _want_ to be good at.

------
naner
blocking: writing blog posts

