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

41–50 of 346 posts

Re: The Case for Slow Programming

#41

Post by serve_yay »

jerf wrote: post #18
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 engineer…

Don't do what everyone else does if you can do something better that leads to better results. The last part matters -- otherwise you're just crapping on everyone who can go faster than you and attributing the difference to "quality" (conveniently left nebulously defined).

Put another way, how do you know what you're working with is steel, and others clay? What if your "steel" is really just clay that is slower to produce and more brittle? How do you reassure yourself that this isn't the case? The answer is, make a big deal about going slower and drink tea and stroke your beard and say "hmmmm." and lots of other things that connote wisdom but do not actually bring it to bear.

I am extremely skeptical of all this, not because I am unsympathetic but rather the contrary. We can get extremely wrapped up in our signifiers of skill and wisdom, to the point that we mistake the map for the territory. Instead of cursing the punk kids, try to learn from them and beat them at their own game.

Re: The Case for Slow Programming

#42

Post by pc86 »

jerf wrote: post #18
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 engineer…

If everyone in the business is using clay, you should either be using clay yourself, or you should convince everyone to use steel.

Re: The Case for Slow Programming

#43

Post by pjmorris »

hasenj wrote: post #35
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 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

Re: The Case for Slow Programming

#44

Post by mVChr »

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.

Re: The Case for Slow Programming

#45

Post by Argorak »

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.

German has a very nice word for that: "zügig". It means "speedy" as well, but goes a bit towards "stable", "steady" and "friction-free". It's the good kind of fast, which sometimes needs a step back and a look at things.

So, if I came to work "zügig", I didn't speed, but there was no traffic jam, I didn't stop for a coffee somewhere, etc.

Re: The Case for Slow Programming

#46

Post by kaichanvong »

mVChr wrote: post #37
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 think of it more like "deep" and "shallow".

Mindful and considerate to your future self and others.

Re: The Case for Slow Programming

#47

Post by thoughtsimple »

akbiggs wrote: post #31
tiglionabbit wrote: post #13

Earlier quoted context omitted.

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.

At least in my experience, the main point of coding interviews has always been to expose and analyze the way that you approach and solve problems, not to see how fast you write code. It's usually better to take a step back and re-evaluate the design of your solution rather than dive into the first solution you create, since you'll usually find a better way to express the solution that is short enough to write down on…

Why shouldn't a programmer be reliant on their tools? What a bizarre idea.

I like to measure a carpenter's skill based on whether they can build a nice looking bookshelf with just a pocket knife said no one ever.

Re: The Case for Slow Programming

#49

Post by paul7986 »

To all the web agencies who expect jobs (design, code it & WordPress it with custom post types) a mid-size website; 20 to 40 pages) that take 60 hours to be completed in two to three days (pay you for 24 hours of work only) you can go take a flying leap.

This industry especially in the web agency world has me burnt out. The agencies all are in competition with each other .. lowering costs and thus expect their people to get things done in manner where their employees have no life but getting their work done. It's exhausting and the work is not very fulfilling.

Now I have done the same work at Fortune 500 companies and for someone with a family and who wants a balance work & family/social life that is where you want to be!

Re: The Case for Slow Programming

#50

Post by meesterdude »

wow, this is great! I definitely have always fallen into the "slow" camp. Though I've always considered it more a matter of being careful and with purpose, and not being haphazard.

Quality over quantity. Painting a wall is easy, painting a painting takes much more precision and care, especially when you have to exercise your design skills as a developer.

Though often, a lot of the time goes into understanding what it's supposed to be doing in the first place, and from there it's a matter of making it more resilient, isolated and friendlier to work with.

I'm the slowest dev on my team, but I squash the bugs that nobody could figure out, or knew were there. Taking things apart takes time and patience, but when you're done you know how it all works and can refactor it to be clearer/simpler, and appropriately comment on what it does and how.

Post reply on HN