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

131–140 of 346 posts

Re: The Case for Slow Programming

#131

Post by superuser2 »

vertex-four wrote: post #66
thoughtsimple wrote: post #47

Earlier quoted context omitted.

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.

If you're asking them to design something rather than build something off a pre-existing design, you might like to know that they actually understand the principles of design, and aren't relying on a tool to pretend they do.

It is completely reasonable to rely on a text editor and the language interpreter. Hell, even the language documentation.

This could be an issue with really fancy IDE features, but there's a world of difference between a whiteboard and an IDE - namely, a text editor and an interpreter/compiler.

Re: The Case for Slow Programming

#132

Post by curiousHacker »

wellpast wrote: post #76
pekk wrote: post #57

Earlier quoted context omitted.

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…

I'm not saying that it doesn't take time to build software and I'm not making a case for how to do management. In my decade of experience on different teams and products, the main impedance to productivity has by far been to do with bad code and architectural choices. The justification is always "speed" but my point is that is wrong. It's not speed that is at fault, it's that most software engineers don't know how to…

Describe good architectural choices?

Re: The Case for Slow Programming

#133

Post by briantakita »

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…

Instead of slow, continuously evolving the domain abstractions is key. Faster & more effective is better. If slow creates effective judgement instead of prejudice, then go slow.

There are two systems in the brain at play. "Fast thinking" involves gut reactions & intuition. "Slow thinking" involves logical analysis & formations of models. Both contribute to effective solutions.

Recognizing iteration as the cycle of evolution & growth creates working systems in congruence with natural law.

Re: The Case for Slow Programming

#134

Post by lavamantis »

barking wrote: post #100
Argorak wrote: post #45

Earlier quoted context omitted.

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

Germany has a few other words going for it to promote worker productivity, such as Mitbestimmung ("Industrial Democracy": https://en.wikipedia.org/wiki/Industrial_democracy)

Re: The Case for Slow Programming

#135

Post by jakejake »

EdSharkey wrote: post #106

Lack of design in software nowadays was cited as a problem in the post. I agree, and I think there's a lot of not-classically educated hands out there that wouldn't know a good design document from bad. Nor would they have any practical knowledge of a combination of: how to structure code in large code bases, test their code, converse about/apply software patterns, document their API's for public consumption, RAII, S…

I have to agree that age alone doesn't necessarily mean anything. I know plenty of lazy, mediocre old programmers. But in order to run a project it does help to have gone through many project launches using different methodologies. That usually takes a few years of professional development, seeing fads come and go, learning to work with different personalities and, honestly, even screwing up a few times.

Re: The Case for Slow Programming

#136

Post by MichaelGG »

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…

Paper is awesome. I find I rarely visit my notes afterwards. I just need a medium to spit out my thoughts, or I end up going in circles. As soon as I flush to paper, then my mind is unblocked to go solve the next problem. Most of the time, I remember most of what I've written down, so the paper is write-only.

My best work I do while half-napping with a notebook by my side.

Re: The Case for Slow Programming

#137

Post by MichaelGG »

hasenj wrote: post #25
elwell wrote: post #11

> "I’m Glad I’m not a Touch-Typist." Yes, typing speed, when looked at in isolation, does not cause the production of high-quality code. But there is an argument to be made for reducing the friction between one's mind and the code on the screen. Insofar as we can ignore that transference of data from biology to technology, we can think more fully and clearly. So, emacs commands that are fully ingrained in one's subco…

I used to believe that. It's why I picked up coffee script. I thought, the less there is to type, the more you can focus on the problem rather than the code. I found out I was wrong. The redundancy actually helps. There's somehow a calming effect in it. I don't know how to put it into words. I found out that I never actually think while typing per se. I have to first jot down my thoughts on paper. Typing out the code…

My hands sometimes get pain and there's a hardwired response that makes me feel awkward, physically, I've I start typing out a lot of repetitive code. When I read Java or most C# code, I just cringe at all the extra crap, at all the pomp and boilerplate. Every time I have to write it, I feel annoyed that I need to type more stuff out like an idiot, because some compiler writer had misguided ideas, or because they already dug enough technical debt to allow more expressivity.

Re: The Case for Slow Programming

#138

Post by MichaelGG »

BhavdeepSethi wrote: post #8

And yet, most coding rounds in interviews are rigorously timed. Almost always, the importance is given to code completeness rather than code design/elegance. I'm sure a lot of talented engineers lose out here.

If you can't write a simple function to reverse a string, or words in a string, in a rather short amount of time, is that a good sign? Sure, everyone can pop out the "well the most elegant is use the stdlib's reverse function". But then you say well implement that as efficiently as possible, and we know the end result is a simple little loop -- what should taking more time mean? Someone that takes 10 minutes to come up with the function makes me a bit more nervous than someone that takes 1 minute. Is that wrong?

Re: The Case for Slow Programming

#139

Post by oldpond »

One of the key points in the article is that the OP had lots of experience with Bay area startups. This could be part of their culture. If you use agile you can achieve a code velocity a touch higher than standard, and if you really want to push the limits you can. I agree, however, that good design takes time. I was at a conference in Sweden last year, and the conference App was a bit problematic. The poor dev team was chained to their keyboards right in the middle of the breakout area trying to fix it in real time. I felt like saying, "Guys, it failed, go enjoy the conference."

My experience lately in "normal" shops (non startup) is that the skills sets are just plain missing. It's hard to find anyone that can code at all, let alone code fast.

Good post. Thanks for this.

Re: The Case for Slow Programming

#140

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]
Post reply on HN