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

161–170 of 346 posts

Re: The Case for Slow Programming

#161

Post by Retra »

tomphoolery wrote: post #112
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,…

Careful is a good way of putting it.

It's possible to change the entire world in half a page of code. That should be the goal...

Re: The Case for Slow Programming

#162

Post by burke »

NateDad wrote: post #58
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…

Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.

Yeah, I was also about to post a comment recommending Go. It's not completely immune to tooling bloat, but it's actively reductionist in that respect. It's relatively pleasant.

Re: The Case for Slow Programming

#163

Post by burke »

woah wrote: post #141
NateDad wrote: post #58

Earlier quoted context omitted.

Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.

I found go to be quite cumbersome in comparison to npm. Magic folders in the filesystem and such. With node you never have to do more than npm install and everything is ready.

Go has a couple wonky conventions, but it's a very very simple system. Once you accept and learn to deal with the GOPATH quirks, that's pretty much the only tooling weirdness in the whole ecosystem.

Re: The Case for Slow Programming

#164

Post by chandankumar »

IMHO, writing a good program goes through lot of thought process. You keep thinking about the solution of same problem till you get the best solution (or at least you are satisfied with it). So it is going to take some time. But I guess after having some experience, you will find a way to create well designed code more quickly than before.

Re: The Case for Slow Programming

#165

Post by jschwartzi »

beat wrote: post #65
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 my favorite programming tool. The beauty of paper is that it's easy to find out when you're wrong, when you're pursuing the wrong path, without going deeply in and getting distracted by the small-scale details of the code. This gets right back to the design thing.

To put it another way, it's far less time-consuming to edit a Word document than it is to update an entire production system.

Re: The Case for Slow Programming

#166

Post by MrDom »

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…

> The justification is always "speed" but my point is that is wrong.

Not necessarily. Proper architecture takes time and planning and reasoning. If it didn't, we could make a program do it for us. There is absolutely a time tradeoff between coming up with the proper architecture for the application vs just using something that looked cool from a google project. The latter will always be faster at first, but not in the long term.

Re: The Case for Slow Programming

#167

Post by danenania »

michaelochurch wrote: post #149
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. I think a better adjective would be robust . But I'd hate "Robust Programming" become as much of an abortion as "Agile", now an excuse for micromanagement and business-side…

I agree about what the term 'agile' has become, but in many situations (especially in startups), spending too much time and energy to make something robust in version 1 is worse than hacking it together with spaghetti code. The key is to know which mode is appropriate for what you're doing.

If we want to create more tolerance for good engineering practice, we can't act like primadonna artists obsessed with building our perfect masterpieces on someone else's dime. We're hired by businesses, so our arguments need to be grounded in business value.

"It's a shitty architecture" isn't going to get you anywhere.

"It's going to fall apart and cost you millions if you do it that way, but if you take out these less important features and spent more time on what matters, we can do it right for the same cost..." People might just listen to that one.

Re: The Case for Slow Programming

#168

Post by rapind »

lectrick wrote: post #125
barking wrote: post #100

Earlier quoted context omitted.

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.

Relevant: http://knote.com/2014/11/10/why-germans-work-fewer-hours-but...

I now love german culture. It's like finding my soulmate.

Re: The Case for Slow Programming

#169

Post by keyle »

cesarbs wrote: post #62
NateDad wrote: post #58

Earlier quoted context omitted.

Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.

That sounds awesome, I'll definitely give it a try.

I am afraid a language change is not going to help your burn feeling

Re: The Case for Slow Programming

#170

Post by sethammons »

tomphoolery wrote: post #112
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,…

I like "deliberate" programming -- though, the syllable count may be too high.
Post reply on HN