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

111–120 of 346 posts

Re: The Case for Slow Programming

#111

Post by popee »

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…

Yeah, absolutely wrong nomenclature and it would be better to call it:

http://en.wikipedia.org/wiki/Wu_wei

> Wu wei is an important concept in Taoism that literally means non-action or non-doing ie. "effortless doing"

Set goal, think and explore a little, rest a lot and wait until you get clear picture. Then and only then start coding.

Pros: No burnouts, less stress, etc, and constantly moving forward (in contrast to 2 steps forward 1 step back cycle) what results in overall faster progress.

Cons: Personally it's sometimes pain in the ass to wait, but it's important to understand -> not to be obsessed with job. Get a hobby, do something else and let unconscious part of your brain deal with what needs to be done -> mind blowing discovery for me that actually works, but still have to get used to this concept :-)

Re: The Case for Slow Programming

#112

Post by tomphoolery »

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.

Agreed. The ideas in this article are sound, but I'm not sold on this "slow programming" term. It's more like "careful" programming, or how about "care-full" programming, in which you put your full amount of care into every character you write.

The reason we've been able to speed things up is because of these tools, like CI systems and test frameworks. Faster iteration means getting results back faster and that means you can spend more time thinking about the problem and less time implementing it. That is the major benefit of what the author calls "fast programming" and it's something he glossed over completely. Just because you move fast doesn't mean you can't be careful along the way. You just need tools that extend your own visibility in order to catch problems faster and more accurately solve them.

Re: The Case for Slow Programming

#113

Post by EdSharkey »

angersock wrote: post #67

I'll disagree with a few points here. First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the one pushing for smarter, smaller, better-designed solutions to our problems. It seems that a lot of people, especially those with an academic background, forget one of the three qualities of a good programmer: extreme laziness. Developers (often younger ones) t…

But NextSTEP didn't fail. It succeeded, in the biggest, most spectacular way I can imagine an operating system would. So, design does matter. Design seems to matter a great deal at Apple, so that backs up your other point that most other businesses could care less about their software's design and that NextSTEP at Apple is an exception.

Re: The Case for Slow Programming

#114

Post by georgemcbay »

owtM wrote: post #72
georgemcbay wrote: post #40

Earlier quoted context omitted.

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…

> I type about 105 wpm using four fingers > I also don't look at the keyboard > I just know where the keys are from muscle memory You are touch typing though. You may have an unconventional style, but that is irrelevant.

I guess it is touch typing if you define touch typing as any kind of typing without looking, but it isn't what most people think of touch typing, I don't have any sort of "rest" or "home" position.

Re: The Case for Slow Programming

#115

Post by KedarMhaswade »

larrys wrote: post #93

"I’m Glad I’m not a Touch-Typist." Have to disagree with this 100%. A touch typist can always hunt and peck if they want to or need to for some reason (would love to have a reason for this being a benefit though). Being able to touch type helps greatly with just about everything when you are using a keyboard. Sending emails, writing letters, filling out forms, coding, the command line and so on. Not only that but it'…

+1. I am a bit sad that the author chose to downplay the (usefulness of) touch typing.

Re: The Case for Slow Programming

#117

Post by overgard »

I kind of disagree with the premise here, from my own experience, it's much better to work fast but ruthlessly refactor and never be afraid to delete your own code. I find I rarely nail things on my first attempt, but by being quick and failing fast, I learn more about the problem domain and I end up with a nicer end result than the person that agonized about their decisions rather than trying things out. (Of course, the corollary is that I usually do these things on a branch so I'm not inflicting it on my coworkers)

The problem with doing a big design up front is that you're generally going to run into something that's surprising, that you didn't account for (unless what you're doing isn't novel -- but then, why are you writing code rather than reusing it?) I think when people get all ponderous about these things, they're not really learning about the problem, they're just procrastinating. We're not building bridges here, if your first attempt isn't brilliant you're not out a million dollars of concrete.

Re: The Case for Slow Programming

#118

Post by GFK_of_xmaspast »

mVChr wrote: post #44
leeber wrote: post #15

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 situ…

The best analogy I heard for communicating this to superiors is that programming is like doing a crossword puzzle. 95% of the time you're doing a crossword you're not writing but that doesn't mean you're not intensely working on solving the puzzle.

You need to get better at crosswords.

Re: The Case for Slow Programming

#119

Post by cgearhart »

overgard wrote: post #117

I kind of disagree with the premise here, from my own experience, it's much better to work fast but ruthlessly refactor and never be afraid to delete your own code. I find I rarely nail things on my first attempt, but by being quick and failing fast, I learn more about the problem domain and I end up with a nicer end result than the person that agonized about their decisions rather than trying things out. (Of course,…

It depends a lot on the problem domain. Sometimes rapid prototyping is a useful tool, but the benefits rapidly diminish in the face of complexity. In my experience with moderately complicated scientific and mathematical software, there isn't anything to prototype - either it works, or it doesn't. If you aren't deliberate about design choices, the bugs can be really devious to find and squash.

Re: The Case for Slow Programming

#120

Post by jchrisa »

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…

There's also the question of what you work on, not just the quality of your work. You can do a barely-works version of something that it turns out people really want and it's better than if no-one had built it...

Maybe slow programming means finding important things to work on.

Post reply on HN