Non-blocking Programmers(codingrelic.geekhold.com)
codingrelic.geekhold.com
Non-blocking Programmers
http://codingrelic.geekhold.com/2011/03/non-blocking-programmers.html
26 comments
Agreed, and let me add typing speed is important to 90% of a programmer's activity outside a source code editor. The changeset commit message, the bug tracker description, the status report email, commenting on Hacker News... ;)
Anyone who believes typing source code faster increases productivity by any worthwhile amount is solving an inane problem. If the bottleneck is on your fingers, then 10 outsourced developers or a Visual Studio drag-and-dropper will replace you.
Anyone who believes typing source code faster increases productivity by any worthwhile amount is solving an inane problem. If the bottleneck is on your fingers, then 10 outsourced developers or a Visual Studio drag-and-dropper will replace you.
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.
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.
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.
I agree: many developers not only refuse to leverage their tools, but even aggressively defend this lack of automation. (Ironic, since the game of the game is automation.) Take for example copy/pasting from an Excel document (or worse yet, eyeballing and 'copying' by hand) — when it's frequent enough to justify automating.
Often these inefficiencies come from a lack of critical thinking: What are your tools' deficiences? What's better than "How everyone's always done it"?
Often these inefficiencies come from a lack of critical thinking: What are your tools' deficiences? What's better than "How everyone's always done it"?
> 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?
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?
I've found that pairing with interviewees on real(ish) problems usually helps to detect useful traits (I am not advocating pair-programing here FYI; rather working with them in front of a machine during the interview). Your mileage may vary.
Some of the things I look for are (in no particular order):
1. Knowing where to look for help when stuck
2. Systematically looking up the man pages/docs/API when stuck as opposed to making multiple wild guesses
3. Indenting code and saving files with proper names (you would be surprised how many people don't intend code even when it spills over 15-20 lines)
4. Instinctive eye for usability - for e.g. parsing command line arguments when appropriate rather than doing it blindly (`if sys.argv[n]: foo elif sys.argv[n-1]: bar`)
5. Inclination to iterate, even during an interview. Many people are happy to produce a working answer and leave it at that. Some iterate and tidy up without being asked to.
Some of the things I look for are (in no particular order):
1. Knowing where to look for help when stuck
2. Systematically looking up the man pages/docs/API when stuck as opposed to making multiple wild guesses
3. Indenting code and saving files with proper names (you would be surprised how many people don't intend code even when it spills over 15-20 lines)
4. Instinctive eye for usability - for e.g. parsing command line arguments when appropriate rather than doing it blindly (`if sys.argv[n]: foo elif sys.argv[n-1]: bar`)
5. Inclination to iterate, even during an interview. Many people are happy to produce a working answer and leave it at that. Some iterate and tidy up without being asked to.
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.
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.
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.
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.
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).
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).
And the other question is: how do you sustain and nourish this curiosity and gaining of knowledge in regular project work cycles in typical IT departments under already more-than-pressing deadlines?
Often there are very real issues, however sad and true, why there are so many hacks and "duct type programming" and more often than not, programmers and immediate superiors do not have the luxury of being able to deal with them and instead have to "suck it up".
Once you are in "crunch mode" in a death march project curiosity, elegance and sanity are the first casualties right after all of your free time.
And apart from that, we as humans are not exactly outstandingly great at betting on the "later benefit" instead of immediate gratification.
Often there are very real issues, however sad and true, why there are so many hacks and "duct type programming" and more often than not, programmers and immediate superiors do not have the luxury of being able to deal with them and instead have to "suck it up".
Once you are in "crunch mode" in a death march project curiosity, elegance and sanity are the first casualties right after all of your free time.
And apart from that, we as humans are not exactly outstandingly great at betting on the "later benefit" instead of immediate gratification.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
160wpm? Really? You're into world record territory there: http://www.owled.com/typing.html
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!
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!
The Guiness world records are with numbers only because they are consistent from language to language. I suspect someone can type much faster with a non-accented language.
blocking: answering customer phone calls
Anyone else in a small company and get constantly interrupted?
Anyone else in a small company and get constantly interrupted?
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.
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.
[deleted]
Typing is not the bottleneck: http://sebastianlab.com/post/140303165/typing-is-not-the-bot...
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.
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.
blocking: writing blog posts
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.