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

121–130 of 346 posts

Re: The Case for Slow Programming

#121

Post by TheCondor »

angersock wrote: post #67

I'll disagree with a few points here. First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the one pushing for smarter, smaller, better-designed solutions to our problems. It seems that a lot of people, especially those with an academic background, forget one of the three qualities of a good programmer: extreme laziness. Developers (often younger ones) t…

Actually, because you have deadlines and bills, that's why design does matter. There are definitely echo chambers where it doesn't, or at least it seems like it doesnt, but when it comes to making real money being able to deliver on time with quality matters more than anything else.

Re: The Case for Slow Programming

#122

Post by overgard »

cgearhart wrote: post #119
overgard wrote: post #117

I kind of disagree with the premise here, from my own experience, it's much better to work fast but ruthlessly refactor and never be afraid to delete your own code. I find I rarely nail things on my first attempt, but by being quick and failing fast, I learn more about the problem domain and I end up with a nicer end result than the person that agonized about their decisions rather than trying things out. (Of course,…

It depends a lot on the problem domain. Sometimes rapid prototyping is a useful tool, but the benefits rapidly diminish in the face of complexity. In my experience with moderately complicated scientific and mathematical software, there isn't anything to prototype - either it works, or it doesn't. If you aren't deliberate about design choices, the bugs can be really devious to find and squash.

I think the implication of this article is that fast = reckless, but I disagree with that. Sometimes you recognize that you need more data points, and writing something that works will move you closer to the correct solution, even if the first version isn't perfect.

But yeah, it depends on the problem domain. If you're asking me how to build a website, I can probably have a pretty solid idea of what that code should look like. It's not a novel problem, usually. If you're asking me to build, I don't know, a voxel renderer and you're trying to figure out if an octree is the right way to go for representing the data, or you need to do something more exotic, I'm gonna have to play around a bit.

Re: The Case for Slow Programming

#123

Post by 4ydx »

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…

This is why something like golang is appealing. Simple simple and more simple.

Re: The Case for Slow Programming

#125

Post by lectrick »

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.

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

Re: The Case for Slow Programming

#126

Post by seanconaty »

I like iterative development but I also really like the author's "cauldron of soup" metaphor. I've definitely worked on projects where I feel like I'm rebasing/updating more than I'm actually doing work to add any type of new value.

Re: The Case for Slow Programming

#127

Post by err4nt »

> My wife often comes out into the yard and asks me: “are you coding?” Often my answer is “yes”.

I think I need this quote in my kitchen! My girlfriend often pounces be with the accusation "YOU'RE NOT WORKING" if she sees me out of my chair moving around, doing mindless house chores or half-vacantly tossing a cat toy around the house, or running errands, but the reality of _design_ is that it happens all day. And when you're done 'work' for the day, ideas and solutions still happen.

I'm working in the shower, I'm working all evening. I'm working waiting for the bus. I can either let it pass or write it down, but I can't seem to shut it off.

But I don't mind. I've been learning to slow down too. I used to be a perfectionist and when I was billing a client I would only bill my butt-in-chair-and-head-down time as billable hours, but lately I realize if I sit and think, plan, and research for 2-4 hours, and spend 2-4 hours implementing the results of that thinking, I get more done each day than 8 hours of butt-in-chair-head-down typing.

They key is to approach it as design, and that's where my training as a graphic designer comes in handy. The Design Process was drilled into out heads and I've only recently been applying it to my coding :)

Re: The Case for Slow Programming

#128

Post by lectrick »

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…

It is the MOST trivial thing to measure performance in a Go game.

It is the LEAST trivial thing to measure the "code quality"/"unit of time" metric in a programmer. For example, you might bang out an implementation that looks fine, but 1 guy will say "that will become unmaintainable in 1 year" or "that will be a problem if we ever switch databases" or whatever and sure enough, a year later, the team has to do that... and that 1 guy was fucking RIGHT.

Who's to say how you measure such a thing?

The longer you spend in a career that has ANY creative component, the more you will come to loathe the importance placed on "performance evaluations." In fact, I'd argue that the more advanced you are in those creative jobs, the SLOWER and BETTER you work... the problem is that the newbies won't be able to recognize the "better" portion.

Re: The Case for Slow Programming

#129

Post by 4ydx »

angersock wrote: post #67

I'll disagree with a few points here. First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the one pushing for smarter, smaller, better-designed solutions to our problems. It seems that a lot of people, especially those with an academic background, forget one of the three qualities of a good programmer: extreme laziness. Developers (often younger ones) t…

You sack them as soon as you have their knowledge? Seems a bit extreme. Or you are simply saying that the person in question is aggressively keeping people off of their turf? That must be it :P I have been working at a small startup for the past 6 years. The code is all mine so sometimes it is a bit hard to relate to all of the internal struggles that programmers seem to have.

Re: The Case for Slow Programming

#130

Post by forgottenpass »

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…

With specific skill sets, you can build architecturally sound systems at no extra cost.

Except the extra labor costs of someone with that skillset.

Post reply on HN