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

The Case for Slow Programming

ventrellathing.wordpress.com

Post reply on HN
Print view View original

11–20 of 346 posts

Re: The Case for Slow Programming

#11

Post by elwell »

> "I’m Glad I’m not a Touch-Typist."

Yes, typing speed, when looked at in isolation, does not cause the production of high-quality code. But there is an argument to be made for reducing the friction between one's mind and the code on the screen. Insofar as we can ignore that transference of data from biology to technology, we can think more fully and clearly. So, emacs commands that are fully ingrained in one's subconscious may be good, but probably not the C-u 12 C-x TAB; at least for somebody simple like me.

Re: The Case for Slow Programming

#12

Post by swalsh »

Adam89 wrote: post #5

How does typing speed affect the design of software? Thinking about your design has not got a lot to do with the speed you type at. Secondly as programmers we should be able to work on the same code base.

As women we should be able to birth the same babies?

After the baby is born anyone can raise the child, some better than others, but its easy. We call that adoption. Until its born though, the baby, and it's mother are symbiotically connected to each other.

I think this is similar to the process of programming. Break down an interface, and work on a team at that level. Behind the interface though, keep it small. one or two people max if possible, and those people have to be on exactly the same brain wave as each other. Even well planned code takes some time to stabilize, and it's hard to even find that if other people are actively changing interfaces etc.

Re: The Case for Slow Programming

#13

Post by tiglionabbit »

BhavdeepSethi wrote: post #8

And yet, most coding rounds in interviews are rigorously timed. Almost always, the importance is given to code completeness rather than code design/elegance. I'm sure a lot of talented engineers lose out here.

Most interviews I've done have expected me to write code on a whiteboard. This is pretty unnatural for me. I'm a very fast typist, so it's frustratingly slow to have to draw letters manually on the whiteboard.

Re: The Case for Slow Programming

#14

Post by JackFr »

He makes a reasonable point, but this piece is largely a strawman. And

> For the same reason that many neuroscientists now believe that the fluid-like flow of neuronal firing throughout the brain has a temporal reverberation which has everything to do with thought and consciousness, good design takes time.

is just pure nonsense.

Re: The Case for Slow Programming

#15

Post by leeber »

I probably spend just as much or more time sitting, thinking, and staring at partially written code, than I do actually writing the code. It's frustrating when you have superiors who don't understand that time spent thinking is just as productive as time spent typing.

That's just my personal style, although I've never worked in "large" teams on a single codebase so can't comment on what styles work best in those situations.

Re: The Case for Slow Programming

#16

Post by Swizec »

BhavdeepSethi wrote: post #8

And yet, most coding rounds in interviews are rigorously timed. Almost always, the importance is given to code completeness rather than code design/elegance. I'm sure a lot of talented engineers lose out here.

> most coding rounds in interviews are rigorously timed

In the real world you will have to work against a deadline. As much as code gardening is fun and does produce better software, in the real world shipped software always wins over well designed software.

Can you get it done, is a more important question to answer than can you make it beautiful.

Re: The Case for Slow Programming

#17

Post by Swizec »

elwell wrote: post #11

> "I’m Glad I’m not a Touch-Typist." Yes, typing speed, when looked at in isolation, does not cause the production of high-quality code. But there is an argument to be made for reducing the friction between one's mind and the code on the screen. Insofar as we can ignore that transference of data from biology to technology, we can think more fully and clearly. So, emacs commands that are fully ingrained in one's subco…

The less brain cycles you have to spend on your tools, the more you can spend on your product.

:)

(I believe in fast typing, usually I'm at some 120wpm, but it does help more with writing than it does with coding)

Re: The Case for Slow Programming

#18

Post by jerf »

serve_yay wrote: post #7

> The casualty of my being a slow programmer among fast programmers was a form of dysrhythmia – whereby my coding rhythm got aliased out of existence by the pummeling of other coders’ machine gun iterations. My programming style is defined by organic arcs of different sizes and timescales... Boy oh boy. Look, I'm all for coding slow, taking time and understanding what you're doing. But there is something to be said f…

"Everyone around you is building this bridge in clay.... what are you doing fooling around with this 'steel' crap for?"

Of course you can spin it the other way too, which just goes to show this isn't a useful comment. Don't do what everybody else is doing just because they're doing it, do the right thing. If that does happen to be clay, great, but there's a great deal more people using inappropriately sloppy engineering than people using inappropriately careful engineering, so I'd expect to hear a lot more about the former.

The only people in real life that I've met that I would consider saying were being inappropriately careful were really just masking fundamental incompetence under a veneer of concern about process. I'm not sure I've ever seen anybody correctly apply massive overengineering to a programming task in real life. I'm absolutely sure it has happened, but it is not common enough to be worth talking about.

Re: The Case for Slow Programming

#19

Post by baddox »

swalsh wrote: post #12
Adam89 wrote: post #5

How does typing speed affect the design of software? Thinking about your design has not got a lot to do with the speed you type at. Secondly as programmers we should be able to work on the same code base.

As women we should be able to birth the same babies? After the baby is born anyone can raise the child, some better than others, but its easy. We call that adoption. Until its born though, the baby, and it's mother are symbiotically connected to each other. I think this is similar to the process of programming. Break down an interface, and work on a team at that level. Behind the interface though, keep it small. one…

That analogy only seems to work well if the software you're developing can autonomously interact with other software, like how humans can interact with other humans.

Re: The Case for Slow Programming

#20

Post by kstenerud »

elwell wrote: post #11

> "I’m Glad I’m not a Touch-Typist." Yes, typing speed, when looked at in isolation, does not cause the production of high-quality code. But there is an argument to be made for reducing the friction between one's mind and the code on the screen. Insofar as we can ignore that transference of data from biology to technology, we can think more fully and clearly. So, emacs commands that are fully ingrained in one's subco…

Actually, I've found that the act of moving what's in my mind to a source file is in itself an act of revision for my ideas. I don't need to type fast for it to happen, because I'm not going to write anything at all until I have a solid idea or path in my head. The actual act of typing consumes less than 10% of my programming time, and is for the most part a mere formalization of my thoughts. Would a 50% increase in typing speed make me finish the feature in 4 days instead of 5? Nope.
Post reply on HN