Hacker News new | ask | show | jobs
by meheleventyone 2063 days ago
That's a different idea though.

Rather the whole point here is that when learning it's better to focus on quantity over quality AND by doing so that quality will naturally be better. The parent is looking for examples of this latter idea.

2 comments

I'm mostly interested in the source of the story, it sounds completely fabricated and if it is true, it should be very easy to replicate.

But let's take the idea to the extreme, imagine we are building an system, one team starts building and improving on the design for 6 months. Other team builds and starts anew every 2 weeks. Who would have a better system at the end of 6 months? Tough to tell, the iterative one will probably build it from the ground in a better way with less technical debt but who will have a more complete system or more features.

I don't think it's important for the message if the story is true or made up. It's overthinking things to an extreme.

I also think it's being misapplied when put into a completely different context. Teamwork, not students learning, project that is harder to start again and slower to iterate that way etc. I'm not sure we should consider every piece of advice as being some how completely universal.

We could also overthink it in the other direction. The students themselves could have come to the conclusion that the best way to get quality was lots of practice and made lots of pots or parts of pots until they had perfected pot making and merely presented the final result. Whereas the students that went for quantity merely made a load of crap pots. Same lesson but roles reversed.

I think it does matter whether true or made up. Otherwise, why not present it as a thought experiment?
> I don't think it's important for the message if the story is true or made up. It's overthinking things to an extreme.

Agreed. There's a lot of pedants on HN who have what I call "the Snopes illness."

If you consider version n+1 of your software a new product - it's the same idea.

This is basically agile vs waterfall.

Starting simple versus starting complex is different than making the same kind of thing repeatedly to refine the act of making it and the end quality.

Iterating on a project is definitely a great way to learn about it, refine how you make it and accrete complexity. So it can but doesn't necessarily have to encompass both ideas.

I also think that whilst it's tempting to stretch the anecdote to fit all sorts of ideas it's particularly unhelpful when trying to discuss the idea it actually references.

But if you threw away all the code after each version, I doubt you'd get much done. Sure the code might be perfect, but you can do only so much in a short timeframe.

Perhaps it would be best to iterate fast early on in the project, throw away a couple of weeks with PoCs and then go for the big one.