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

81–90 of 346 posts

Re: The Case for Slow Programming

#81

Post by Arzh »

> And the latest clever development tools, no matter how clever, cannot replace the best practices and real-life collaboration that built cathedrals, railroads, and feature-length films

There is really one design process with all of the great cathedrals, railroads and films. One person is designing and running the show. It really just reads like this guys doesn't like to work with people who like to work by committing a lot. I work with a programmer that is in his late 50s and he likes to work as the writer does. I can get his same level of results with my method, which is much 'faster.' It's not that I am much smarter than him we just have different ways of doing it and we get the same success rate.

Re: The Case for Slow Programming

#82

Post by eric_h »

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 "well considered" is a better adjective than slow.

Re: The Case for Slow Programming

#83

Post by andy_wrote »

m0nastic wrote: post #54

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

I think most people would agree that writing things on paper first is a total necessity if you are writing mathematical code (I mean, are you going to do the equations in your head and type them out?), and I think the benefits to paper increase in proportion with the mathiness.

On the non-mathy side, I find it useful to take the concept of "rubber duck" debugging (which is totally applicable to original design and creation, and not just debugging) but write a "duck" document rather than talk out loud. Aside from not looking crazy, I find writing easier for thought organization.

Sometimes preparing slides can also be a nice way to really force your thoughts into simplest and clearest form. And hey, when you're done, you can present it to your co-workers.

Re: The Case for Slow Programming

#84

Post by balls187 »

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.

Re: The Case for Slow Programming

#85

Post by sytelus »

It's not about being fast or slow but being in a flow. You don't want to go faster than you can or intently slow down. Unnecessarily long design cycles inhibits experimentation and may cause you to loose touch with reality. Artificial push for speed up is probably even more harmful. So I would vote for "flow movement".

Re: The Case for Slow Programming

#86

Post by wellpast »

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?

This is important: you can separate handling complexity from the profession of building architecturally sound systems.

We can teach people how to do math correctly. That doesn't guarantee that they will be able to solve arbitrarily complex problems. But to solve math problems, you MUST at least have the skill sets.

So there is a test to measure do you have the skill sets. How much one is willing and/or able to handle complexity is a separate thing to consider.

Re: The Case for Slow Programming

#87

Post by pnathan »

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…

> 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.

Yes, this is extremely problematic. The hacky junk built by hacky developers is frustrating and a direct contributor to my burn-out quotient.

Re: The Case for Slow Programming

#88

Post by benekastah »

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.

Re the quote, I agree. Perhaps if I read the study on temporal reverberation I would understand the point, but it just felt like showing off.

Re: The Case for Slow Programming

#89

Post by wellpast »

eric_h wrote: post #82
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 "well considered" is a better adjective than slow.

"Well considered" is too subjective, I think. There are specific, concrete skill sets that lead to systems with specific, well-defined properties (i.e., architectural soundness).

Your system may be well-considered but if it's not architecturally sound it's going to increasingly tumble over time.

Re: The Case for Slow Programming

#90

Post by discreteevent »

Retric wrote: post #51
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."

I used to think it had to stick around for some time. In practice you start paying for bad code after about a month and you pay back many times over. If a bunch of people are throwing poor code in, the payback becomes exponential before you know it.
Post reply on HN