Hacker News Reader

Comment by JonathanFly | Hacker News Reader

>Start sloppy

>Another trick to start sloppy - you might have high expectations of your finished work.

>You want to write a great book, not just a good one. Or create a stellar artwork, or start a great business. >All those expectations can put more pressure on you than you can bear, leading you to avoid it by procrastinating. >Instead, you can escape those expectations by starting deliberately badly.

I use this one a lot. I always heard it called a 'vomit draft'. It really works. It's easier to see how truly terrible thing could be improved than it is to just start working from a blank slate.

View on HN

This idea is captured nicely in the book "Art and Fear" with the following anecdote:

"The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."

Was this book some sort of dystopia about teaching?

how cool, thanks for sharing!

Maybe this works for potters but I don't think it'd work for developers. If a compSci lecturer suggested one group would get an A for writing a perfect, bug free app and the other group would get an A for writing 50,000 lines of code, I wouldn't expect the group writing as much code as they could to make the best app.

In this hypothetical scenario, instead of counting final lines of code, maybe we should count lines of affected code: take each commit and count how many lines were added, modified or deleted.

That matches "the quantity trumps quality" idea above more closely in our industry.

Group B would be assigned to write 50 apps in this case. In your example 50000 LOC would be like making a really giant pot.

In the pottery example Group A were marked by weight ("fifty pound of pots rated an “A”, forty pounds a “B”, and so on."). Making a single giant pot could get you an A if the lecturer wasn't pedantic about the meaning of "pots".

Well, if you're making "pots", you're not making "vases", "pans" or "thimbles". The experiment doesn't work if you don't set any acceptance criteria.

I think it could potentially work!

Consider someone with little to no experience with programming trying to build a single app and planning it out and refactoring and refining it continuously, compared to constantly creating and archiving multiple toy prototypes of the same app and then considering the best among those.

(The app's size and complexity should be commensurate to a single clay pot in a ceramics course.)

It requires the students to actually try to make something of quality, sure, but only to the same degree that the students in the original (apocryphal) story did- after all, those students could easily have shown up with a pile of baked misshapen clay instead of proper pots.

This would be analogous to

creating 1 pot using 10 tons of clay = writing 50,000 lines of code for 1 project

writing lots of different projects = creating lots of different pots.

That only works if the second option is constrained to make all the projects approximately the same number of lines of code.

I think if doing this I would have a group split so one has to create an app that's finished (defining that would be fun) and one that has to write one that's code is 'clean' (again, fun defining that).

I say this because I've worked with a lot of inexperienced developers that commonly have a stack of half finished projects, or things they've re-written half a dozen times to get the architecture right. I'm my experience you learn a lot by finishing things, and being constrained by previous decisions.

Bonus points if you can get customers relying on your work, nothing motivates like support emails.

I think it does work for developers. You also learn programming by doing it, rather than by thinking about it. Write 50 apps, and your 50th is bound to be better than if you start out trying to write the perfect app on your first try.

One group writes as many tests as it can, the other one big integration test ;-)

How about for writing the same app 5 times, no matter the quality of it? Is that a better analogy?

Knuth suggests, in TAOCP, that the best way to write a program is to write it once, scrap it completely and rewrite from scratch. Very much in line with spending an entire semester making one perfect program vs spending a semester writing and rewriting new programs from scratch.

First pass: you figure out which problems need to be solved. Second pass: you already "what" figured out, now you can focus on how to do it nicely.

I used this extensively for code assignments in university, but for a different reason. We had to do most things in C, which can be very painful for prototyping and experimenting with new approaches. So I would solve the problem first in Python, try different approaches, and then after I was happy with the solution I'd write it again in C. Saved me a lot of time in the end.

A better approach in my experience is to grow the whole system from a “skeleton” implementation, refactoring the architecture and code as your understanding grows. With the key use cases being your guide.

in the extremes, neither of approaches work, if you are just fighting yesterday's bugs or paralised by choice and perfecction, both are bad ideas.

It's like order and chaos, what you want is to find a balance that allows you to explore, and leave things a bit open so they can also be extended, but also sound and precisse enough so that it actually works, and does the job.

If they had to make a ~1000 line program 50 times the analogy would work better.

I don't find it now, but I've read that anecdote is made up. And I don't think it make sense. Except for when you are an absolute beginner, you won't improve if you don't put in any effort in the quality of your work. See deliberate practice etc..

I think you are missing the forest for the trees.

The point is to get over that mental hurdle of achieving perfection, which blocks a lot of people from getting started.

I understand the point they are trying to make, but I still think the anecdote is harmful. It gives the impression that it is more important to put in the work than any real effort. The only thing you’ll be good at after producing 1000 crappy pots is producing crappy pots.

High quality crappy pots.

It's also tinted by the fact that learning a skill is usually logarithmic. If you are a student with no pot-making skills, those first few pots are gonna give a lot of XP. I think it'd be a different outcome if done with more experienced potters.

I think you are over-simplifying the situation. Malcom Gladwell's book Outliers popularized the notion that a person needs on average 10,000 hours of practice to truly master a given task. A lot of people took this to mean, "if you put in 10,000 hours of practice, you will become a master." This is not true. The 10,000 hours of practice is necessary, but not sufficient. The practice has to be _intentional_, guided, goal-oriented practice. Not just playing the same song or making the same shot over and over.

That was exactly my point. It is harmful to believe that mindless practicing, or pottery, will make you a master just because you put in the time or prescribed number of pots. How am I oversimplifying?

No, the point of this anecdote is that you get good at quality by pursuing quantity.

It's an appealing idea because it's counterintuitive, and here on HN were are absolute suckers for contrarian ways to outsmart the herd. But we have been given no reason to think it actually works.

Well, in writing terms, it seems to have worked for Ray Bradbury:

> The best hygiene for beginning writers or intermediate writers is to write a hell of a lot of short stories. If you can write one short story a week—it doesn’t matter what the quality is to start, but at least you’re practicing, and at the end of the year you have 52 short stories, and I defy you to write 52 bad ones. Can’t be done. At the end of 30 weeks or 40 weeks or at the end of the year, all of a sudden a story will come that’s just wonderful.

From: https://lithub.com/ray-bradburys-greatest-writing-advice/

... incidentally, also Neil Gaiman's advice in the Masterclass lectures.

The reason it works so well for writing is, as Neil Gaiman points out, that if you work for a year on one story, you've probably practised starting a story 52 times. But you've still only practised finishing a story once. And getting into the habit of finishing things is one of the most important habits to get into.

Really like this piece of advice. Thanks for sharing!

There’s exactly the same anecdote in the popular book “Atomic Habits” but instead of pottery, it’s a photography class.

Man, I could get an A in like, 20 seconds.

I can’t remember the name of the ceramicist, but hearing him interviewed on Radio 4, his apprenticeship in (China|Japan) involved every pot he made being deliberately smashed at the end of the day for a year. A way to get over a fear of failure and to learn to keep repeating the process of learning.

David Bowie and Tin Machine used this technique on their album Tin Machine.

>The Sales’ also pushed for a punishing first-take philosophy, which Bowie found enticing. No overdubs unless necessary for guitar solos, no synths (the old Queen boast), and most of all, no lyric rewrites. The band would go to lunch and return to find that Bowie had written out a complete provisional lyric for whatever song they were working on. But that was as far as he was allowed to go: he was forced to keep to his first instincts. Sometimes this worked out, sometimes it didn’t (see “Crack City”).

>Given these strictures, Bowie and the band stuck to music “that didn’t have too much orchestration about it,” as Bowie said in a 1989 interview. “If it got too chordy and arranged, it wouldn’t be anything what we wanted to do. The structure had to be as loose as possible so that we could improvise.” Rather than reworking songs, they just kept cutting more, with as many as 35 to 40 pieces coming out of the sessions. So most of Tin Machine is basic blues-centered rock, with the average song having no more than five chords: it lacked the harmonic ambiguity and structural games of Bowie’s older work. While the record often worked on a song level, with 14 tracks on the CD version, the album was a wearying listen. Few records are as exciting in miniature and as draining as a whole as Tin Machine.

from here https://bowiesongs.wordpress.com/2012/04/25/heavens-in-here/

It's often easier to add to something that already exists than to start something new from scratch. And when you're the one who created the thing in the first place, it's that much easier to make the improvements.

Even if the initial thing is so terrible it needs to be redone completely, at least you figured out what you don't want. All while getting into the habit of doing the thing.

I stumbled upon this when trying to get started with my master thesis. In frustration, I threw a bunch of buzzwords and random thoughts at LaTeX and then stashed it for a day or two. After that, I picked it up, looked at it critically and went "well, this paragraph is obviously wrong, here's what it SHOULD say..." and two hours later I had a very rough draft finished.

Currently struggling with writing a bachelor's thesis hard, so any other ideas/ tips you have, would be greatly appreciated!

Write out the whole thesis as headers and fill all the sections with Loren ipsums until you have the page count you want. Then, start filling in the real text

Please double check for the lorem ipsums before you hand it in.

Reminds me of an idea from Ira Glass's lecture circuit: as you learn a craft, you develop the taste to recognize that your own work is crap long before you get good enough to satisfy your own standards. You just have to push through and trust that it eventually ends.

As Ernest Hemingway never actually said, "write drunk, edit sober". Which I don't take to mean literally getting drunk before you start working on something, but do it as if you were drunk, i.e. with little to no inhibition.

At work I found calling this draft a 'straw man' gets quite a few more people off of the starting blocks.

It's just an avenue for having a discussion about what we actually want to say.

You can't clean up a blank page. Gotta foul it up first!

I also like how they mention marathon. Indeed, you don't start training for marathon by running all 42km on the first day, are you? No, for some of us in our current shape even running 5km is hard! So we should start with smaller things - those we can do - and tell ourselves that we have achieved something - and that tomorrow we probably will achieve slightly more.

I agree a lot with this. A blank page is the worst - I find it hard to get started. But if I just put something (probably something bad) it is much easier to just continue improving it.

For me it's different. It's easy for me to start a project. I get overly excited over a week, banging a lot of code. But as soon as I get stuck, I often get stuck forever and never come back to the project.

Or I decide to "refactor" a piece of code, and then spend days thinking about how I'll "refactor" it, rather than just doing it or not doing it in the first place.

Make it work, make it right, make it fast [1]. This has helped me tremendously in my programming career and especially in my side projects, where I have very limited time and energy. Its a solid strategy for breaking down complex work.

[1]: https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

> Start in a way that you could enjoy. Start doing in in a way that you could have fun, even if it's not as efficient as other boring/normal ways, so that the fun itself is the motivator.

Fred Brooks in The Mythical Man Month:

> Plan to throw one away. You will anyway.

Does this mean that, for instance, if you're writing a novel, you start without a structured outline?

Many people do! This is the 'architect' vs 'gardener' debate. A lot of writers start out with the notion of a story, then let it develop in the writing. If I remember correctly, Stephen King writes this way.

>Does this mean that, for instance, if you're writing a novel, you start without a structured outline?

It could, but there's no reason you couldn't start with a terrible outline instead of diving right into prose. The point is just that when you see something your brain will stark noticing all the ways it sucks and it gets things going.

This absolutely works for me. I call it the 'zeroth draft'.

Anything worth doing is worth doing badly.

Reply on news.ycombinator.com