Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming's Dirtiest Little Secret

steve-yegge.blogspot.com

Post reply on HN
Print view View original

101–106 of 106 posts

Re: Programming's Dirtiest Little Secret

#101

Post by geebee »

I'm always a little surprised to find a programmer who can't type while looking at the screen. I never actually sat down and learned to touch type, it was a by-product of coding.

But this isn't just about programmers, you can see it in the movements of any expert.

Systems administrators know how to move around directories with minimal keystrokes - the characters seem to just fly by the screen. I know I'm in the presence of a good one when this happens.

A former colleague of mine proved that he'd spent many years in the trenches as a consultant through his mind-blowing ability to do excel. Any shortcut, he knew. He could set up a pivot table, create a LUT, denormalize data, simulate a query, set up scrolling, and automate charts in, like, 4 minutes. I could do this, but I'd have to hunt around the help, and it would take me a long time.

Good tennis racket stringers chat with you while they instinctively weave the crosses through the mains with a slight waving pattern that reduces friction and extends the life of the string job. They use the clamps and tensioner without really looking at it. I have my own machine and I can string a racket fine, but it takes me an hour and requires my full, fumbling focus - I certainly can't multi-task.

When a Judo expert falls backwards he/she just sort of rolls through it. No thought is necessary.

It goes on and on. Programmers type fast without thinking about it. It's one of the things they are simply able to do as the result of programming. I'm not saying it's critical, but it would be really odd to get good at programming without making this skill inate.

Re: Programming's Dirtiest Little Secret

#102

Post by Xichekolas »

henning wrote: post #44
Xichekolas wrote: post #40

Earlier quoted context omitted.

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.

Well I was actually talking about writing queries that involve a join or two. Thinking to myself "I can get this by grabbing all these via joining on that where x = y" doesn't take very long, but typing that out can be annoying if you do it often enough.

Of course, if you are constantly writing 8-way joins with fun things like group_concat in the select clause, I guess it would require a little more thought than typing. Also, I'd imagine the people that spend their days writing stored procedures, triggers, and the like spend more time thinking than typing, but I can't claim to be one of those people.

Re: Programming's Dirtiest Little Secret

#103

Post by MaysonL »

axod wrote: post #52
jamesbritt wrote: post #43

Earlier quoted context omitted.

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.

I agree with you. If your bottleneck in development is typing speed you're doing something terribly wrong. If it's a "lines of code" contest, then sure, learn to type fast, but if it's about producing good concise code I don't think typing speed makes much difference. If you want to program enough, you'll naturally become fast enough.

If your bottleneck in development is typing speed you're doing something terribly wrong.

No, you just think faster than you can type - but liberal use of macros, snippets, syntax-directed editing, code completion, etc. can help.

Re: Programming's Dirtiest Little Secret

#104

Post by MaysonL »

ibsulon wrote: post #90
andreyf wrote: post #76

Earlier quoted context omitted.

That's exactly where I thought he was going... I just recently started writing software >40 hours a week, and have been constantly torn between "getting things done" and "doing things right". The best way to program well might very well be a variation between the two modes.

The mantra from eXtreme Programming: 1. Make it work. 2. Make it right. 3. Make it fast. 4. Make it small. #1 first, then if you have the need, #2. If you have a need, #3. If you have the need, #4. It's a lot easier to make it right once you've made it work.

Actually, it's a lot easier to make it work if you've made it right to begin with. (That said, I've always found the best way to develop is to add functionality to a working program, no matter how small it starts out).

Re: Programming's Dirtiest Little Secret

#105

Post by ibsulon »

MaysonL wrote: post #104
ibsulon wrote: post #90

Earlier quoted context omitted.

The mantra from eXtreme Programming: 1. Make it work. 2. Make it right. 3. Make it fast. 4. Make it small. #1 first, then if you have the need, #2. If you have a need, #3. If you have the need, #4. It's a lot easier to make it right once you've made it work.

Actually, it's a lot easier to make it work if you've made it right to begin with. (That said, I've always found the best way to develop is to add functionality to a working program, no matter how small it starts out).

There are a few problems with this:

1. Sometimes, making it work is enough. (one time code and such) There's no reason, other than for practice, to waste time designing such cases.

2. You may find out that you're solving the wrong problem, and it's much easier to justify throwing out code that you didn't labor over an extensible design, etc. It's much harder to throw away wrong code that you've put work into the internal design.

3. This doesn't mean that you don't design the outward facing interfaces correctly. Thus, you have a good set of unit tests already set up, and you can quickly tell if something is working as you refactor. You have a good baseline with which to compare.

Re: Programming's Dirtiest Little Secret

#106

Post by yters »

a-priori wrote: post #62
yters wrote: post #10

Earlier quoted context omitted.

I think he means looking at the keyboard as he types. I can see how that can help a person type faster, makes sense to me.

Forgive the neuroscience buff here, but I disagree. By looking at the keyboard, you're relying on vision to direct motor actions and detect errors (fingers in wrong positions, etc.). This requires the involvement of association cortex in, I believe, the parietal lobe, to integrate vision, somatosensory (i.e, touch), proprioception (i.e, body position) stimuli. The end result is that typing speed is limited by the pro…

Looking at the keyboard doesn't mean all typing is mediated by vision.
Post reply on HN