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

91–100 of 346 posts

Re: The Case for Slow Programming

#91

Post by tobyc »

I definitely see the value in taking the time to design things correctly and making sure you're evaluating all angles — I'm not sure if it's 100% necessary to say that to do that you always need to be slow though.

I think the difference between a fast programmer and a slow programmer often isn't that the slow one is methodically designing and making everything perfect, it's that the slow one has so many more inefficiencies in their workflow.

A good and fast programmer generally knows their tools inside and out, and they're willing to learn new tools when they need to (and not dismiss them because their current setup works good enough and it's what they know).

Speed isn't an indicator of good or bad quality. I would say that both mastery and improvement of tool is more of an indicator.

Re: The Case for Slow Programming

#92

Post by AgentIcarus »

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…

This seems similar to michaelochurch's thinking about 'guilds' - which I guess is a precursor to formalised 'engineers' or master craftsmen, which is something Software 'Engineering' seems to be in dire need of.

Re: The Case for Slow Programming

#93

Post by larrys »

"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's extremely easy for the average person to learn to touch type (I learned from a book and was proficient after about 3 week).

I really can't think of a good reason (other than taking the time to learn which as mentioned is easy enough) to not learn to touch type. I think it's one of the least talked about productivity boosts out there.

Re: The Case for Slow Programming

#94

Post by cesarbs »

balls187 wrote: post #84
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…

Curious which languages you use that don't have this problem? Usually the point of package managers is to allow you to leverage the work of others, so you don't have continually reinvent the wheel. I've yet to run into a programming environment that did not have it's shares of headaches and nuances.

> Curious which languages you use that don't have this problem?

None. It's why I'm burnt out and want to so something different. Not something different from my current job. Something different from developing software.

I've lost count of how many times I've spent entire work days battling against the environment which is supposed to help me write the code I need to, to make a customer happy. Entire days of trying to figure out why IIS is acting crazy, or why Visual Studio is crashing, or why is Windows so damn slow all of a sudden. Entire days of trying to align the planets so that service A can talk to service B, because for some reason there's a cryptic SSL error that's not giving me any helpful information as to what's happening. Or entire days just pulling things from a dozen different sources and figuring out where to place each other so they can work together.

I've recently been to the Living Computer Museum in Seattle. You can play around with old computers there. I was fascinated by the old machines where you'd boot into a REPL. The shell was a REPL to the language you programmed the system in. I think despite all the advances we've made in the past decades and all the great performing technology we have nowadays, we've lost that essence of simplicity along the way.

Re: The Case for Slow Programming

#95

Post by innguest »

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…

I feel the same way you do about everything you said, including considering a career change for this same reason.

I'm now fiddling with Tcl/Tk as a way to quickly throw some visual ideas around. I'm using it to build an idea for a tabular programming language that is more visual and allows for letting go of incidental details like syntax, argument order, etc.

Re: The Case for Slow Programming

#96

Post by saidajigumi »

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…

> I wonder if some standardized tests can be, in principle, constructed to measure programming abilities.

This absolutely misses the point of the article. It is definitively not about programming abilities, or speed of these abilities.

Many authors have hit TFA's points from different angles. For example, Tom Demarco's excellent Slack[1] introduces uses of "efficiency" (what speed is the organization moving at?) versus "effectiveness" (is the organization moving in the right direction?). DeMarco uses these to illustrate that many organizations optimize for the wrong parameters: they want to move at breakneck speed ("efficiency", "butts in seats", etc.), but in doing so trade off their vital strategic ability to think, design, to steer the ship!

In an organization without slack (briefly, the ability of knowledge workers in an organization to engage in vital reflective tasks, a key part of TFA's design process), everyone's so focused on Getting There that no one remains to decide if There is the right place to be going. This can and does result in everything from classic technical debt to strategic business failure. DeMarco describes a pile of organizational anti-patterns that stem from this philosophical damage.

I like that TFA's author connects these concepts explicitly to more recent thinking on the importance of design process.

[1] http://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficie...

Re: The Case for Slow Programming

#97

Post by donatj »

I was once a "fast" developer, like thousands of lines a day. I could knock things out at an amazing pace but they always had problems and were rarely testable. That actually worked out OK where I was where we basically built things and ideally never touched them again.

Now, 8 years later I write maybe 50-100 lines a day. I can see all the vectors of things that would go wrong and take the time to mitigate them. I work with "hotshot" young developers who write my old maybe a thousand+ a day. I'm the grumbly old man in code reviews who forces them to break them into multiple smaller pull requests. The difference is my 100 lines will stay in the codebase for years, whereas their thousand will likely be rewritten several times over in the lifetime of my code. There's tradeoffs here, to be certain.

I see so many younger devs thinking just because their code is tested that its "good". This is certainly not the case. There is so often so little consideration of how their code fits into the "big picture". We end up with 5+ "widgets" where one general widget would have sufficed if they'd thought things out ahead of time. Sigh. Shakes Fist. Get off my lawn. Old man grumbles... I'm 28.

Re: The Case for Slow Programming

#98

Post by cesarbs »

n3t wrote: post #27

Speaking of touch typing, there's a must-read [1] which made me learn and practice this skill. [1] http://steve-yegge.blogspot.com/2008/09/programmings-dirties...

I usually really enjoy reading Steve's posts, but I have a hard time with this one. Many great programmers admit to being clumsy typers (IIRC Joe Armstrong mentions he's a poor typer in his interview in Coders At Work).

Re: The Case for Slow Programming

#99

Post by badubu »

AgentIcarus wrote: post #92
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…

This seems similar to michaelochurch's thinking about 'guilds' - which I guess is a precursor to formalised 'engineers' or master craftsmen, which is something Software 'Engineering' seems to be in dire need of.

When was the last time you engaged a journeyman carpenter? This problem runs much deeper than just software. Any skilled craft is always at odds with a manager/employer/clients view that you are a fungible asset.

Re: The Case for Slow Programming

#100

Post by barking »

Argorak wrote: post #45
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…

Zügig is just so..Germanic! It's exactly how I imagine the stereotype of German efficiency. In the anglo-saxon world we pride ourselves on how many hours we work. In Germany they work fewer hours and produce more and of better quality. At least that's my impression.
Post reply on HN