Live data from Hacker News

Programming's Dirtiest Little Secret

steve-yegge.blogspot.com

41–50 of 106 posts

Re: Programming's Dirtiest Little Secret

#41
post #32

I started hunt and peck typing at 5 (Apple //c represent!), and had evolved to a four finger lazy-look typing method by 7th grade typing class. I didn't start actually typing without looking at the keyboard until I purchased a factory defect keyboard from a computer fair when I was in 9th grade. This keyboard had no lettering ink on any of the keys. I remember my mom being in disbelief that I could look at her and ty…

I also have a 'modified style' when I use qwerty... via legacy of learning it on my own before being taught.

When I switched dvorak I figured I might as well do it right. As a side effect, my hands no longer hurt like they did with qwerty...

Re: Programming's Dirtiest Little Secret

#42
If you need to type that much, to where whether or not you can touch type matters . . . you are doing something wrong. Saying touch typing matters amounts to stating that programming is actually carried out ON THE SCREEN YOU ARE TYPING ON and I could not disagree with that more . . . programming takes place in the mind of the programmer, typing on the screen is a byproduct.

I can't wait to see how his argument holds up once we have brain to computer interfaces that allow us to skip typing altogether.

Re: Programming's Dirtiest Little Secret

#43
post #9

Three-word summary: learn to type.

Thank you Edit: why is learning to type a dirty little secret?

I think the secret is that those who type slow are picking up speed by being hasty in their code decisions.

I'm skeptical, since far more development time is spent thinking about what to do than in banging out text to implement it.

And maybe some faster typists just emit more bad, buggy code.

Re: Programming's Dirtiest Little Secret

#44
post #17

Earlier quoted context omitted.

"SQL, Lisp, and Haskell are the only programming languages that I've seen where one spends more time thinking than typing." —Philip Greenspun, http://blogs.law.harvard.edu/philg/2005/03/07/how-long-is-th...

While I'd agree with Lisp and Haskell, I not sure how SQL could be considered that dense. I often find myself frustrated that a split second thought takes so long to express as a query, and I type a decent 80wpm or so.

I always assumed he was referring to complicated ad-hoc queries that involve all kinds of joins and so forth.

If I understand you correctly, yes, typing "select ... from ... where id = ..." would get old very fast.

Re: Programming's Dirtiest Little Secret

#45
post #42

If you need to type that much, to where whether or not you can touch type matters . . . you are doing something wrong. Saying touch typing matters amounts to stating that programming is actually carried out ON THE SCREEN YOU ARE TYPING ON and I could not disagree with that more . . . programming takes place in the mind of the programmer, typing on the screen is a byproduct. I can't wait to see how his argument holds…

programming takes place in the mind of the programmer, typing on the screen is a byproduct

As he says in the article, the actual programming is not what requires much typing. It's communicating with others on IRC (or e-mail, whatever you kids use these days), typing documentation, writing blog posts, etc. that require typing skills.

I will agree with him on this. I don't type much when actually programming, but I do type a lot when talking with people on IRC (including co-workers, since we all work from home) and writing documentation. And writing HN comments :)

Re: Programming's Dirtiest Little Secret

#46
I learned something from this article; I can't touch-type numbers. After reading that part, I moved over to a friendly unused xterm and tried to type 65536. My head immediately began to bend down to gape at the keys. I tried not to look, but I couldn't do it.

Interestingly, I can type the symbols on the numbers just fine. (hello "world"). $here @are &some #sigils!

Re: Programming's Dirtiest Little Secret

#47

"... Yeev noticed that one of the electives, surely placed there by mistake, was Typing. Like, on a typewriter ..." What an elective? Mine was compulsory complete with manual typewriters and battle-axe teacher. One thing I do miss about those old clunkers was the solid feel the keys had. You had to learn to position your index fingers at 'F' and 'J' remember where each key was positioned and hit hard. So letters like…

The Happy Hacking Lite keyboard is nice and compact with a solid feel:

http://pfuca-store.stores.yahoo.net/haphackeylit1.html

Previously they also carried a "professional" model which featured blank keys. Not only was it "l33t", but it was supposed to improve your speed by forcing you to learn to touch type which of course is required for late night hacking sessions in the dark.

Finally, there is the classic carpal tunnel inducing IBM keyboard:

http://pckeyboards.stores.yahoo.net/customizer.html

Re: Programming's Dirtiest Little Secret

#48
post #31

It frankly never occurred to me that any programmers wouldn't know how to touch-type. How does that happen?

Remember that the set of "any programmer" is pretty big. It probably happens by not spending much time programming. Or by not noticing your bad habits.

I think most "kids" today can type pretty well because it's essential for IM-ing. I know that's how I learned to type quickly. Older people might not do much real-time communication, so they might not know how slow their ad-hoc typing is.

Re: Programming's Dirtiest Little Secret

#50
Incidentally, Steve brought up an interesting topic. Musicians practice by playing fast, then slow, then medium. Fast, slow, medium. Over and over. That seems like a good way to write software.

You first try to implement your idea as quickly as possible, stopping to think only when necessary. The goal is to not spend too much time overthinking the implementation -- you want to find out if your idea is worth executing on.

If you decide that your idea isn't worth it, then you move on to your next one. Otherwise you take it slow, going back over your code and refactoring it. (I personally don't believe in "make one to throw away", but rather that it's possible to refactor an ugly design into a succinct one.) At this stage, you should meditate on the best way to accomplish your engineering goals. It will pay off in the long run to spend extra time here.

Then comes the final stage in your project's lifecycle: medium. The core structure of the design has solidified, and you need to add the flourishes that make software truly great. But you have to take your time to ensure that the codebase stays clean. At this point, the design of the various smaller subsystems should flow naturally from the architecture you decided on in the "slow" phase.

Repeat for each core feature.

Post reply on HN