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

51–60 of 346 posts

Re: The Case for Slow Programming

#51

Post by Retric »

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…

The problem is clean code is only a net gain when it sticks around. So, some teams are toxic to clean code. Let's refactor to use library X, no wait, libarary Y. There is a conflict with foo unless you use bar version 0.37c. Or the classic: "Works on my machine."

Re: The Case for Slow Programming

#52

Post by [deleted] »

wellpast wrote: post #22

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

[deleted]

Re: The Case for Slow Programming

#53

Post by hasenj »

pjmorris wrote: post #43
hasenj wrote: post #35

Earlier quoted context omitted.

I think we can learn from some other (not-so-obviously-related) disciplines. The game of go[0] has a ranking system where players progress from 30kyu (complete beginner) to 1kyu, then 1dan to 9dan (very strong). [0]: http://en.wikipedia.org/wiki/Go_ranks_and_ratings It's mostly statistical and based around comparing your skill level to other players. While a 7kyu level is not necessarily that well defined, and might…

Should you measure the worker, or measure the work? Anyone who can build reliable systems using unreliable parts (like humans) will have an edge. EDIT: If you're going to measure the worker's programming concept knowledge, Alison Tew's work seems to be at the leading edge. [1] 'Developing a Validated Assessment of Fundamental CS1 Concepts', Tew, Guzdial, http://dl.acm.org/citation.cfm?id=1734297

I'm more interested in measuring abilities relevant directly to software as a profession (or craftsmanship), such as: how well can you architecture a system to solve a complex problem?

Re: The Case for Slow Programming

#54

Post by m0nastic »

I hesitate to recommend my process to other people, because I don't think I'm a very good programmer.

But for the past year or so, I find that I program best by actually writing out my program in a notebook (in my case a quad-ruled lab notebook). I don't even start typing until I have it laid out pretty much in it's entirety on paper.

This sounds ridiculous (and I can imagine it's not practical for all types of programming), but I've found that it's been tremendously helpful in getting me to understand what all the code that I'm writing does.

Most of the code I've written this past year has been in Haskell, so that helps somewhat by not having a lot of syntax to write down, but I'm sure I'd be doing the same thing even if I was writing in Java.

Re: The Case for Slow Programming

#55

Post by VLM »

georgemcbay wrote: post #40
pzxc wrote: post #10

I recently disregarded the competence of a coworker (who is in a programmer position) because I took a class with them and saw that they could not type. They were hunting and pecking. (This guy is 50 years old so has had plenty of time to learn) Is that wrong? Does being bad at typing force you to be more thoughtful and actually make you a better programmer? Or does it just mean it takes you longer? My thinking is th…

I type about 105 wpm using four fingers (my index fingers and my thumbs); I don't touch type at all but I also don't look at the keyboard, I just know where the keys are from muscle memory (when switching to a keyboard that is unfamiliar to me it takes me a minute or two to adjust if the keys are particularly different in shape/size from ones I usually use). I'm not sure what that says about me as a programmer. In an…

Things get really weird when you consider the effect of template / tab completion systems like yasnippet in emacs and numerous non-free alternatives.

(template systems are an editor extension where you type "i" "f" "tab" and magically an entire if statement stanza instantly appears all perfectly formatted and ready for the details to be filled out.)

So if I type at 40 wpm, but 4 keystrokes of mine do more than 16 keystrokes from someone who doesn't use a template system, does that mean I'm effectively typing at 160 wpm? I guess so.

I also use an extension that magically aggressively indents so I don't indent, my editor takes care of it for me, so I guess I'm typing at infinite wpm when formatting code, compared to someone who hand indents.

Re: The Case for Slow Programming

#56

Post by sophacles »

wellpast wrote: post #22

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

> I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win.

I like to use the word "deliberate" when I mean "slow", but think that "slow" will be misinterpreted.

Re: The Case for Slow Programming

#57

Post by pekk »

wellpast wrote: post #22

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

It takes a certain amount of time to build a house (that will be durable and to code) no matter how much people want "skill sets".

If it takes a longer time than management wanted for something to be built, that isn't necessarily because "skill sets" are lacking.

If the product is shoddy, that is probably not because the team lacked the magical ability to make sound products instantly, but because the team was rushed (on the theory that they are not professionals and have to be micromanaged)

The odds are that the feature spec was bloated and management was bad at estimation (perhaps because they demanded estimates out of programmers who are also not good at estimation, in a bid to squeeze as much output from them as possible).

Hackers aren't the problem. A pogrom on "hackers" is unlikely to solve anything. "Professional" in the sense of wearing this or that, or following whatever you personally consider to be best practices isn't going to fix scope creep, wrong estimation, fundamental facts about project coordination, or the laws of physics.

Building serious stuff takes time.

It's management's job to handle that without flipping its shit.

Re: The Case for Slow Programming

#58

Post by NateDad »

cesarbs wrote: post #21

> Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code. This resonates so much with me. Sometimes I worry that I'm falling behind on keeping up with technology, but whenever I try to learn something new it seems like I have to install a package manager, then another package manager inside the first one, then pull a million oth…

Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.

Re: The Case for Slow Programming

#59

Post by eru »

hasenj wrote: post #53
pjmorris wrote: post #43

Earlier quoted context omitted.

Should you measure the worker, or measure the work? Anyone who can build reliable systems using unreliable parts (like humans) will have an edge. EDIT: If you're going to measure the worker's programming concept knowledge, Alison Tew's work seems to be at the leading edge. [1] 'Developing a Validated Assessment of Fundamental CS1 Concepts', Tew, Guzdial, http://dl.acm.org/citation.cfm?id=1734297

I'm more interested in measuring abilities relevant directly to software as a profession (or craftsmanship), such as: how well can you architecture a system to solve a complex problem?

If you can shine a new light on the problem to make it simple instead, than you can get away with a simpler architecture.

Re: The Case for Slow Programming

#60

Post by thaumaturgy »

JackFr wrote: post #14

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.

> but this piece is largely a strawman

In what way?

Post reply on HN