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

141–150 of 346 posts

Re: The Case for Slow Programming

#141

Post by woah »

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.

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.

Re: The Case for Slow Programming

#142

Post by cesarbs »

ternaryoperator wrote: post #69
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…

One treatment of this exact problem: Just let me code [1] [1] http://www.drdobbs.com/tools/just-let-me-code/240168735

That was a nice read, thanks. I'm glad to know there are more people that share the same feeling as I do towards the state of our craft.

Re: The Case for Slow Programming

#143

Post by woah »

cesarbs wrote: post #94
balls187 wrote: post #84

Earlier quoted context omitted.

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…

Sounds like you have a problem with the shitty ms stack. Have to do some c# at work and I feel your pain.

Re: The Case for Slow Programming

#144

Post by sdrothrock »

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.

Latin has it in festina lente -- "Make haste slowly."

Re: The Case for Slow Programming

#145

Post by einhverfr »

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 am not so sure. The point of "slow programming" is the same as "slow food" and "slow democracy." I think you have to see the three together. The point is to slow down, deliberate, and then do. That doesn't mean long iterations, nor does it mean deferring progress. It means ensuring solidity of the progress as you make it.

I once interviewed for a job at one of the most recognized and big Perl shops in the world and didn't get invited to face to face because I "took my time" with their puzzles. My response was that my first drafts were faulty, and that I preferred to program slowly because I could deliver more code, faster, and better by taking my time with it. In the end, their loss.

Deliberation is important. That often means slower apparent progress but faster progress overall.

Re: The Case for Slow Programming

#146

Post by sramsay »

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 find it very hard to convince my students to pull out a pencil and a notebook before they start coding.

"Draw some pictures. Make some notes. Write a function that you suspect will be tricky. Make a flowchart. List the methods that will have to be in that class. Write out how the user will interact with it. Try to list all the pain points for the user. You can write it any way that helps you think. Make up a notation if you want."

Yes, the assignment is due and they need to get code on the screen. But one of these days I'm going to give them a programming assignment and tell them that I only want to see their notes.

Re: The Case for Slow Programming

#147

Post by markbnj »

Also in the largely-agreed camp, and probably unsurprisingly I'm about the same age. But unlike some I don't have a problem with the word "slow." Yeah, it has negative connotations, but it's clearly meant as an ironic counterpoint to the culture of speed. Whatever, as long as it will get the young guys I work with to figure out what the problem is before trying out a solution, I'll be happy.

Re: The Case for Slow Programming

#148

Post by michaelochurch »

Spearchucker wrote: post #103

This guy speaks to my soul . A couple years ago I worked on a project that tried to put a 40+ page printed form online. The form is complex. The form has a lot of intricate guidance and notes, and sections that must or must not be completed based on previous sections or fields. I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an adm…

The term "agile" deserves a preceding apostrophe, as in 'agile, because there are two letters (the 'f' and the 'r') being trimmed.

I fucking hate that nonsense. It's a total scam.

Re: The Case for Slow Programming

#149

Post by michaelochurch »

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 mediocrity, has proved itself to be.

Re: The Case for Slow Programming

#150

Post by einhverfr »

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 would agree but I would also say that good design takes a lot of time and practice to get right. You don't want to design too much up front, but you don't want to design too little. The top-level design really shouldn't be that detailed. The component design should get progressively more detailed.

One of the best things programmers can do is to learn software design and I don't mean UX design but rather API design. Be conscious of what you expose to the world. Be conscious of your interfaces. Design your interfaces. Think through error conditions etc. This allows you to push a lot of component design down to the people actually doing the work.

I have been instrumental in pushing my largest client at the moment from a fast programming mentality to a contract-oriented design mentality. The goal is to speed up the development of those components that need to be developed in a more agile manner by providing greater stability in a platform they can rest upon. You can't program fast if the ground changes under your feet (or rather you can but you will never get anywhere).

Post reply on HN