Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be prolific

chrismytton.com

Post reply on HN
Print view View original

41–50 of 134 posts

Re: Be prolific

#41

Post by quickthrower2 »

throw149102 wrote: post #34

I realize this is a silly criticism, but it's strange that the author would write about how it's valuable to make a lot of stuff but then to only write 11 sentences about the topic. It seems like it would be much better way to demonstrate the point if the author wrote 100 pages about producing more work/art/code, without any rhyme or reason or editing. After all, the thesis is "Quantity leads to quality", why not jus…

I think the subtle point is as long as it’s safe, practicing a lot will make you better than being a beginner trying to be an expert.

In the blog analogy he could write 100k words and throw them away. They were for getting good. Then write 200 words for a blog post that gets published. Don’t publish the first 100k.

Or poker for example, play 100k hands at tiny stakes before moving up to higher stakes.

The weightlifter example is a good point. Some disciplines need education in addition to just practicing.

Re: Be prolific

#42

Post by iamgopal »

throw149102 wrote: post #34

I realize this is a silly criticism, but it's strange that the author would write about how it's valuable to make a lot of stuff but then to only write 11 sentences about the topic. It seems like it would be much better way to demonstrate the point if the author wrote 100 pages about producing more work/art/code, without any rhyme or reason or editing. After all, the thesis is "Quantity leads to quality", why not jus…

Well that page landed on hn first page. thats something. also We do not know how many edit author did for that page to be like that.

Re: Be prolific

#43

Post by appleflaxen » 

  There’s a story about an art teacher that split their class 
  in half. They told one half of the students that they’d be 
  graded based on a single piece of work, and the other half 
  that they would be graded on the quantity of work produced.
Does anyone know of an actual event where this happened, or is it apocryphal?

(I don't disagree with the premise, I'm just curious about its basis)

Re: Be prolific

#44

Post by Insanity »

polskibus wrote: post #5
Insanity wrote: post #2

It's the same with software I imagine, because of several reasons. 1. Writing more code (and being conscious of it) makes you a better engineer. You'll run into more issues that you will fix and, hopefully, remember. 2. If you'd take the art example and say "Paint 20 cubist pieces", and then transfer that to "Write 20 authentication servers", each iteration you'll benefit from what you learned and be able to 'clean u…

Ad1. In my opinion it's the variety of problems an engineer has solved that matters. There are plenty of crud developers that are helpless whenever a more complex problem occurs, even though they did hundreds of crud pages in their life.

Yup, I tried to convey that in the "being conscious of it" part. I meant to say you have to actively see it as learning / improvement.

Re: Be prolific

#45

Post by billfruit »

saberdancer wrote: post #12
lqet wrote: post #6

Earlier quoted context omitted.

Here is an article discussing this: https://medium.com/swlh/the-science-backed-secret-to-rapidly... > On the first day of the class, the ceramics teacher divided the class into two groups. All those on the left side of the class, he announced, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. > The works of highest quality, the most beautiful and creative desi…

It's an anecdote which could be completely fabricated, I'd expect it is since the source seems to be a book where it is mentioned as story with no names. If anyone has some kind of study or more concrete example, I'd love to hear about it.

Why is a study or a concrete example necessary, if I might ask. It works perfectly fine as a thought experiment.

Re: Be prolific

#46

Post by feralimal »

ChrisRackauckas wrote: post #11

When teaching mathematics I like to always mention that the greats like Ramanujan, while it seems like they just knew everything from pure thought, they all actually did a ton of work by hand. Ramanujan in particular is known for his fastidious notebooks calculating thousands of digits numbers like pi. From writing out the calculations for hours and days, he'd come up with simplification formulas and develop new insi…

I agree absolutely.

I would also say that this applies more broadly - that busy work is required in all parts of one's life. Deconstruct everything. Accept nothing. You will still learn, but you will recognise the assumptions and beliefs that you hold, and having recognised them you will also test for their truth.

I see 'busy work' as the root to a more valid personal epistemology; one that is based on personal use of the scientific method.

Re: Be prolific

#47

Post by saberdancer »

meheleventyone wrote: post #35
ajuc wrote: post #17

Earlier quoted context omitted.

Unix vs Multix. Plan 9 and GNU Herd vs Linux. Spring vs EJB. Rest vs Soap vs CORBA. C vs Algol. It's easier to do something simple and iterate on it than to do something perfect from the start.

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.

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.

Re: Be prolific

#48

Post by ajuc »

meheleventyone wrote: post #35
ajuc wrote: post #17

Earlier quoted context omitted.

Unix vs Multix. Plan 9 and GNU Herd vs Linux. Spring vs EJB. Rest vs Soap vs CORBA. C vs Algol. It's easier to do something simple and iterate on it than to do something perfect from the start.

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.

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

This is basically agile vs waterfall.

Re: Be prolific

#49

Post by lordnacho »

Maybe the thing I would add is that you need to have reached a level of competence where you can critique your own work.

It's hard to describe it, but in many areas you will find there's a level where you know where you're going wrong, or where you need external help, and generally whether you are on the right path.

Before you reach that level you will just fumble around forever. I'm pretty sure I could play a lot of silly piano tunes without getting anywhere, since I have no experience at all in that field.

Post reply on HN