Hacker News new | past | comments | ask | show | jobs | submit login
Watch Me Make Mistakes (paulgraham.com)
603 points by llambda on Nov 9, 2011 | hide | past | favorite | 116 comments

Thank you for making your process public. In almost any endeavor where one compares his own process only to the observable outcome of another's process, he can believe erroneously that his (possibly superior) results are the fruit of inefficient labor and near incompetence. While I must edit repeatedly to produce reasonable prose, PG can just dash off a brilliant essay. Few know how may takes were required for a screen actor to nail a particularly difficult scene -- we just see the near-perfect result. Obviously, the same phenomenon occurs in software development. Look at how brilliantly Kevin Bourrillion (et. al., of course) designed the Guava API! [One of my favorite APIs from a design perspective] How many discussions over beverages with Josh Bloch were actually required, and to how many internal iterations at Google were we never privy?

It is only by adjusting our perceptions of the processes by which others produce quality work that we can feel good about our own abilities.

I spend a lot of time thinking about stuff like this. Specifically, the difference between creative endeavors (where you iterate on something before releasing it), and performance-based endeavors (where you try to nail a live run-through of what you've practiced).

In either situation, the amount of work that went into things is hidden from the audience. We simply admire (or abhor) the final product or performance. But it's actually much different to be a creator than it is to be a performer. As a performer, there's no guarantee that the extent of your practice will shine through in the end: performance-under-pressure and amount-of-preparation are equally important variables (although the latter can be said to affect the former).

Creators are lucky by comparison. Their only real concern is iteration. You can generally assume that the more time you spend working on something, the better the finished product will be. So iteration is a function of (A) how much time you have before you release, and (B) how efficiently you spend that time. It can be hard to measure B without comparing yourself to others. But I'm often surprised at how much my writing/design/code/etc improves with even minimal increases to A.

You may enjoy Matthew Herbert's mistakes manifesto, designed to enhance those little moments you didn't expect.


At first, I enjoyed watching this, it allowed me to see a glimpse of pg writing one of these famous essays.

However, after the initial 'wow' factor, I realized a slight flaw in this idea of learning by solely watching others (in replay). You see, without any context of changes or explanations for the mistakes that have been made and corrected, I as a viewer may as well just wait for the final product - as the learning is limited.

If this was with programming (a potential target use) for example, I may be none the wiser why the person writing the code suddenly deleted a chunk of code and replaced it with something else, unless of course some annotation / narration was provided to accompany the replay.

Don't take this as a negative point, the idea is great, but I think it could be far more useful with this added feature.

While I agree that annotations would be awesome, there's a lot of value to be found in what already exists.

Part of the appeal of pg's writing is how ... "tight" it is. The man just plain writes well. It was helpful to see a lot of the weaker bits of sentence structure flagged to be pruned later. I could see the same difficulty I experience in structuring my thoughts expressed through three or four iterations of a sentence being hurriedly typed and just as quickly deleted.

Again, annotations would be wonderful, but I'm not sure they're going to happen. Aside from the feature not even existing yet, that would mean the author would need to both want to and be able to go back through the revision history and describe what they were thinking at the time. I doubt most people would be able to do this well, and have strong doubts that anyone would want to do it regularly.

There's a lot to gain here already. Combining the frequency of edits with what actually is changing can give you a pretty good insight into the author's thought process.

I agree, this functionality is not required to make the product succeed. The product is already useful in itself.

I was merely referring to a use case of someone learning to program / think like a programmer by watching replays of real programmers doing their job. e.g. similar to pair programming / training with a mentor, but be distributional across the internet.

As far as 'training' / 'learning':

- If the student looks at some finished code, they can understand how to do something for a specific use case once, but maybe not know how the original programmer got to that solution.

- If the student watches someone write that code, they can understand how to write something similar again themselves and know roughly the process of thought that was used.

- If however, the student can not only watch someone write that code, but also 'understand' why they wrote certain code in places or why they changed the code throughout the process, then they will not only learn how to write for this particular use case, but become a more competent programmer and be able to apply what they learnt to many situations, in context of what is required.

that's what screencasts are for - write code and annotate it with with a voiceover as you along. There is big enough niche between plain text code and screencasts.

FWIW[+], two-and-a-half suggestions for playback mode:

- mark the current edit point more prominently,

- automatically scroll to where the edits are taking place (obvious if you test this on a small screen),

- if you implement the former suggestion, signal big jumps prominently in a way that helps viewers keep track of where they are in the overall document.

[+] I know this is an early proof-of-concept for playback mode, and my suggestions are probably obvious, but it can't hurt.

For those looking for it, the final essay: http://www.paulgraham.com/13sentences.html

It is probably the massive cold I have, but does that mean this replay is from a "playback" file of the old etherpad interface since it is dated February 2009?

Yes! The Etherpads found an old copy of the underlying file and gave it to the Stypis, who converted it to their representation.

That's a pretty clean writing style: In the first 80% of the edit, pg's re-editing is mostly to find better ways of saying what he just wrote, but -at least compared to mine- pretty light in terms of correcting mechanical issues of text formation: most of his mechanical corrections are deleting the typo-ridden last word and rewriting it.

I note also that pg's rephrasing most often consists of deleting the end of the paragraph back to where he was last happy with it and rewriting (we can call this the clean-slate approach), rather than editing the section to transform just those parts of text that should change (the conservative approach I use). I think the conservative approach is faster, but it introduces more errors. I guess the overall cleanliness of pg's writing style is related to this. I wonder if I should try to change to a more clean-slate writing technique.

> I think the conservative approach is faster, but it introduces more errors

interesting. i use 'conservative' and sometimes get surprised how could i write and send such non-corellated or repeated sentences so close to each other.

<Minor Argh!> I went to bookmark Stypi, and it had commandeered CTRL-D...On the one hand, I get it. But it's still a webpage in MY browser.

It's a browser bug. If you don't want a web page to capture a keystroke, tell your browser not to send web pages that keystroke.

Are you suggesting that the default behavior for Firefox 8.0 = bug?

Google books steals cmd-F. :-(

This gave me a completely new look at pg. It really lets you get inside his head.

What I learned: pg is an extremely literal and logical person by nature but in hindsight will tone down his own literalism in favor of a simple, goal-directed, aesthetic.

it would be interesting to use a colour gradient (say from yellow to red) to indicate how long something survived, before it got deleted. so you could see immediately the different kinds of mistake - transitory ones, or stuff that took you a while to realise.

I'd love to see the pitch Stypi gave to get accepted into YC. It looks like a great product - but I'd be interested to know what market of users Stypi will be making happy that aren't already serviced by Google Docs, etherpad, Apache Wave etc.

They applied to do something different. I forget what. They switched to this idea halfway through YC.

It would be awesome if they could incorporate something like this into an IDE, specially Eclipse. I know I would use it.

One would assume that since they got accepted into YC that they had a pretty good hypothesis of what their target market could be. But it's not clear from their website what it is (and it doesn't look like it's an IDE).

The OT technology that powers stuff like this is interesting but is being rapidly commoditized by JS libraries (check out the awesome ShareJS http://sharejs.org/ for an example). So what makes these guys interesting hopefully isn't the tech itself, but the market they want to bring it to.

How would you use it in an IDE? For pair programming?

Certainly can't imagine it would replace source control - it would be incredibly frustrating having other devs break your codebase all the time, you'd be debugging all their mistakes as well as yours, and as a team we'd be disincentives from making any big changes since it would halt anyone else's work while the change is being worked on.

There's a reason we create abstractions like commits and branches, and don't all just work from a share drive.

I would use it mainly as a historical archive. To "see" a program evolve. I think that is a very interesting use case, even if limited.

I believe the Cloud 9 IDE uses basically the same engine (Ace) as Etherpad.

So their market is a free IDE?

It looks like they took Etherpad and added exactly one feature showing deletions in yellow.

Our team started with Etherpad, added a real-time collaborative grid similar to Google Spreadsheets, multiple tabs, integrated full-text Lucene search (indexed immediately), spellcheck, file browser, permissions system, automated time estimates, element insertion, a special script print format, and teleprompter output. I guess I am jealous that we never got interviewed by a hot chick in a fancy high-rise.

Anyway I am wondering, did they use the regular Java/appjet Etherpad, or is it based on the node.js Etherpad Lite?

Also Google Wave wasn't really about collaborative text editing.

It was more about a generic framework for developers that used operational transforms to enable collaborative manipulation of all types of content or objects. But people didn't get that.

Please post a link to your service it sounds very interesting: I would like to use it.

Actually its an intranet application that may end up only being installed in one location. There is also a chance that the AP could adopt it (if they are smart) to replace their old-fashioned ENPS (electronic news production) system but I don't know if that has any likelihood.

   "There is also a chance that the AP could adopt it (if they are smart)"
It's a temptation to think of your application as an IQ test: "they will adopt it if they are smart. But if they don't adopt it I would revisit your presentation and demo before chalking it up to their lack of intelligence.

Nice features. In what does it make it a "company" rather than a cool side-project? (Don't take it the harsh way, I'm really interested in the answer :)

The fact that a lot of people like the feature and want to use it for starters. If they can sell enough ads to make the hosting worthwhile, they have a successful company I'd assume.

Interestingly (refreshingly?) pg's succinctness doesn't come naturally. Early iterations of sentences are riddled with filler words - "that", "immediately", "very" - which are culled. So the trick is to go back and specifically look for words which can be deleted.

It looks like pg tends to refine sentences before moving to the next one. Consider the "I'm not claiming that you only need..." line near the beginning, which went through a ton of revision before being nixed. And at the end of the essay, everything was revised again. This contrasts with how I sometimes wrote essays in school: grid out lots of paragraphs, meet my word length requirement, and then go back and revise. Kinda like a waterfall method.

This would be a neat feature for, say, HN comments. April Fool's day or something. It'd be fun to see the history of a given comment. Or the thought process behind it. It might even yield interesting metrics: maybe a heavily-edited comment would indicate a higher quality than one which was dashed off, regardless of length.

Even though it would be extremely frustrating to read everything in this format I feel like I got twice as much value from it. With every sentence I watched him make the same point in 2-3 different ways. So if I didn't quite understand some concept he was trying to convey the first try, by the final edit I had formed a complete picture. Reading comprehension win!

Seconded. You get in the head of the author, because intent becomes clear from the different way an argument is phrased. Additionally, the jumps between edits show why one thing leads to another. I enjoyed watching this a lot.

What does the [xfs] placeholder stand for?

Same thing that xkcd stands for: nothing.

It's just a series of letters that is unlikely to exist in any normal word, so he can search for it easily later, and replace it with a number. Since you never know what order the footnotes end up being, he starts off with a key in a hash, rather than index in an array.

You'd think that this would be automated in modern editors... The only thing I've seen that bothers to do it is LaTeX.

Restructured text does this too.

I'm actually interested in how this is done. Is there a systematic method for it, or does one pick an arbitrary string? I've always used (and been forced to renumber) ordinals, so this seems quite useful.

Now I want to see how pg wrote arc, from start to what it is today, all in stypi, of course.

Actually I think this is a better way to learn other people's code. Is there any plugin for emacs that can record your editing?

For anyone who writes (and these days who doesn't?) I highly recommend the classic "Elements of Style" by William Strunk. If you only read one book about writing this should be it.


Btw, I think it's more efficent to first write a "braindump" and then start editing, rather than reiterating a sentence a time. You'll remove and rework a lot of what you write but it's easier to get in the flow and just "get things done" before you start rewriting it.

I can absolutely second this. I read it once a year. Many of its techniques are readily applicable to programming or design, after a tiny bit of abstraction.

re: the braindump on the first draft - Ernest Hemingway said he'd "write drunk, edit sober".

Steven King wrote a rant on the same topic, about throwing away dictionaries and spell checkers while in the zone, otherwise you risk getting sucked into editing too early and derailing the creation process.

I've found that it works well even with programming. Braindump code to get things working as quickly as possibly, then refactor mercilessly. Stephen Kings "On Writing" is pretty good read in general and useful not only for fiction but other writing and the creative process as well.

A design equivalent for me would be to start with low fidelity mocks (quick paper sketches, gray boxy wireframes, whiteboarding) before going for higher fidelity and adding visual polish.

Like how this: http://dribbble.com/shots/230767-Stats-Page-For-iOS-App

Turns into this: http://dribbble.com/shots/246763-Appstores-Analytics-Main-St...

Often when I find myself running into creative blocks, it's because I started working on the window dressing too early in the process and need to scale it back to rougher designs.

Imagine if you could see the process of someone writing a HN comment, or see stats such as how long they took to write it or how many edits they made. I made a simple little visualization a while back when I was interested in this: http://justindonato.com/static/demos/sprezzatura/

(If its not ok to post self links, let me know and I'll delete)

Cool idea. Self links are basically fine as long as they are relevant and you identify them as such.

Stypi looks like a neat tool! Visiting the website it instantly presents a collaborative document with a link such as http://www.stypi.com/7e4op8ww

Don't know if I'll ever need the playback feature, and the name feels a bit awkward. Will be interesting to see where they want to take this as a startup.

It looks like they are using the public Etherpad code base. Interesting choice to revive a many-years dead company's code as your foundation.

Hopefully they started from a better point than the vanilla code dump: https://github.com/mattsta/etherpad

Actually I believe they started from scratch. They're pretty good hackers.

Best starting point would probably be Etherpad Lite https://github.com/Pita/etherpad-lite

Don't you dare to take away Cmd+L from me, Stypi. This one is sacred.

I didn't know about Cmd+L, thanks!

Much of this playback reminded me of watching my metrical-verse generator run: a backtracking search editing just the end of the text (or the paragraph anyway), getting stuck for a while on a difficult rhyme before backtracking further, etc. Neat. (Of course this human wasn't limited to that one style of composition.)

That's awesome to watch. If you start with an outline of statements you want to make, you spend less time picking through little clauses around the things you want to say. You have half an outline there to start with: your list of things to tell startups. There are other things it's clear you want to say: the quote from Paul Buchheit, mentioning this came from a conversation with a reporter, etc.

If you nested the list of things as one bit of the outline and then had the key phrase items of the intro as another, just don't worry about adjectives or adverbs or punctuation or flow or anything for the first pass, you may find you get faster overall, especially for longer pieces.

Wow, watching this allowed me to get 3x more value than just reading the article because it allowed me to see PG's thought process more clearly. But it was also 5x more difficult and painful to read than just a regular article.

It's really fascinating to see the thought process unfold like this. I wonder how much variance there is between writers? No doubt everyone has slightly different style and method, but this gives clear way to visualize it.

A relevant quote:

Tellers of stories with ink on paper, not that they matter anymore, have been either swoopers or bashers. Swoopers write a story quickly, higgledly-piggledy, crinkum-crankum, any which way. Then they go over it again painstakingly, fixing everything that is just plain awkful or doesn't work. Bashers go one sentence at a time, getting it exactly right before they go on to the next one. When they're done they're done.

I am a basher. Most men are bashers, and most women are swoopers....

Writers who are swoopers, it seems to me, find it wonderful that people are funny or tragic or whatever, worth reporting, without wondering why or how people are alive in the first place.

Bashers, while ostensibly making sentence after sentence as efficient as possible, may actually be breaking down seeming doors and fences, cutting their ways through seeming barbed-wire entanglements, under fire and in an atmosphere of mustard gas, in search of answers to these eternal questions: "What in heck should we be doing? What in heck is really going on?"

-- Kurt Vonnegut. Timequake p.137-138 (1997)

"awkful" -- nice.

I'd love to have this 'during playback, show me things that survived the editing process' feature to be able to better reflect on my own writing. The feature may convince me to switch from to Stypi from Google Docs.

I think it just shows you that everything you ever do is built piece by piece and that never be afraid of changing or swapping any of the pieces. Your only goal is to put the pieces together better.

monetization idea -> sell as a background service on say HR application forms (or any text area on a form) so that they can watch back exactly how somebody filled in their application.

That would be worth gold the right buyers, assuming legal cleared it. Is there an ethical issue, do you think, with not informing the fillee of that? No current opinion either way.

and thus began a new cat and mouse game between the watchers and the paranoid, with browser plugins for blocking the tracking, followed by sneakier tracking, until eventually the trackers are installing rootkits and everyone starts running their browser in 3 layers of virtual machines.

The right way to do it is to make it pretty obvious. Kind of like text-area enhancement with a slider and status bar at the bottom at the bottom with the words 'Auto Save: On', that the user can toggle.

The truly paranoid will write stuff in a text editor and paste it in, the less paranoid will turn it off. But I have a feeling most people will leave it on.

What was interesting to me was not the subtraction of mistakes but the addition of tone. You wouldn't mistake PG's writing style for John Gruber's, for example.

PG's essays have always struck me as similar to Ernest Hemingway's, who had a terse minimalist style of writing that dispensed with flowery adjectives. So it was heartening to see that PG's initial writing style was more conversational and seemed like something I might read on a typical blog post, before getting tighter and more formal by the final version.


The last time you did this was using etherpad. It was interesting to see your write up( http://news.ycombinator.com/item?id=557191). It was a learning experience for an amateur like me. I haven't spoken to you, but It felt like I did just that -whilst you were writing.

So, would there be a way to save this write up? Etherpad is dead and so is the link you shared earlier. Is there an archive to dig into to see that version again for comparison?

Not dead: Etherpad is easy to install and run for yourself, family, and friends (I did this about a year ago): http://etherpad.org/

Awesome. Just awesome.

I think writers would find it as an indispensable tool to find out where they make mistakes. It can function as a kind of a feedback loop which helps you refine your skill.

Wow it crashes safari on my iPad. Does it happen to anyone else?

Yes, for me too. Every time.

Edit: Works in UIWebView though - might be a bug in the nitro JS engine.

Worked for me, for a while anyway.

It would be awesome if the system gave a rating (read:score) based on how many revisions someone puts into a document, so people have an idea of how hard they worked on it.

I like that that the font actually adjusts appropriately when using zoom-in/zoom-out, but it would be nice if the width of the playback div would also narrow to stay within the browser's width zooming in.

I would also appreciate if you used a heavier font weight, or permitted changing the font easily. It's a bit thin-looking and not easily taken in, at least for my eyes.

This could also have applications in tutoring and teaching writing.

The Stypi link crashes my Safari, iOS 5 on iPhone 4.

Crashes on my iPad 2 too

> I asked the founders to make something special for me: a version of playback that shows text that will ultimately be deleted in yellow.

Now a killer feature would be highlighting text that will be deleted immediately, not just in retrospect. =)

I guess, some super-smart NLP algorithm could be developed to make that possible—once enough data on what gets eventually deleted is collected.

I agree this feature would make for an even more enlightening experience. Color/shade the highlighting as a function of its total lifetime on the screen. Words that are typed and deleted immediately after are the darkest yellow, words that live longer (like until the 2nd editing pass) are a lighter yellow, words that survive to the final remain white.

The potential academic implementations (like in a classroom setting) are promising. Groups of students can collaborate on any projects they want, or even with the teacher present. Commercial implementations could be launched by Stypi to accompany popular academic suites like Blackboard for online assignments.

It might be interesting to have different levels of abstraction, especially for code. Many times, I'm more interested in looking at how the overall design/interfaces of a module change rather than the code inside a method. I might think of analogies to text in terms of organizing thoughts as sections.

Just great - reading these comments got me to go install etherpad again, I noticed etherpad-lite, paused to install it as a private service on one of my servers, now looking at the client JQuery API for embedding in other web apps. Yes, reading HN can be a time sink!

This is extremely cool.

Only one thing I would suggest really - width of linked Stypi page should have some reasonable maximum width, something close to 80 chars. Otherwise, it is really hard to see where all changes are made when browser is maximized.

"it's better to make a few people really happy than make a lot of people kind of happy"

that's a gem.

Paul Buchheit's gem really.

I find that idea really appealing, but I'm still not 100% convinced of its truth. I get the impression that FriendFeed made a few people really happy (still does) and Twitter made a lot of people kind of happy during the same time period. It seems Twitter was more successful. This argues against the gem.

At the same time, Fred Wilson sees it the same way that Paul Buchheit does, independently from watching companies succeed or fail. This argues for the gem.

I remember the days of using "talk" (ntalk, usually) on local unix systems for character by character online chat, vs. linemode IM like current IM systems and IRC.

Watching someone think character by character is far more illustrative.

Would be nice to see where the cursor is. I completely lost track of some edits as 1. the cursor was not shown 2. it did not scroll correctly 3. speed... i am pretty sure you do not type this fast:)

I tried to register an account and when I saw the registration box with no openId/oauth login, I stopped and left. They should seriously support login with at least google, twitter, and facebook

Watching this gives me much more confidence in my writing abilities. I thought I was the only one who proofreads and changes things again and again until they are perfect :)

This is really cool. No Common Lisp love though in the syntax highlighting! /sadface

edit: amusingly, I had to go edit the comment. I find that very reflective of the original article.

After watching this, the thing that surprises me the most is the lack of spelling mistakes.

I guess growing up with computers and not being able to spell are not synonymous.

Doing a BA in philosophy (read: essays) in an age when checking your spelling meant breaking out the dictionary likely broke him of most of his poor spelling habits. I find my spelling has gotten immeasurably worse since the advent of typing the word I'm trying to spell in the omnibox and seeing if any of the results are bolded.

This is neat, although reading it in pg's voice in real time is kind of weird. Especially since the sentence structure and tropes are so distinctive.

"Writing is very easy. All you do is sit in front of a type-writer keyboard until little drops of blood appear on your forehead"

Walter W "Red" Smith

Is this feature available for anyone besides pg?

Fascinating. I'd love to see it generate a "brain signature" to identify people with similar writing/creation/deletion styles.

Fascinating. Makes me think of the original meaning of the word 'essay' - 'to attempt.'

I am trying to think of applications of such a product? Can anybody help me here?

"....It's interesting how often the last sentence of a paragraph can simply be deleted."

well done

I like the last sentence... It has a very lispy feel to it.

    > And there are awkward or unnecessary words and sentences, most of which I catch in successive passes near the end. It's interesting how often the last sentence of a paragraph can simply be deleted.

Stick-slip. Interesting how similar writing process is to video editing.

Crashes MobileSafari (iOS5, iPad2) every time.

Yes, for me too

Writing is work, most often a lot of work.

Crashes on Safari on my iPad with iOS5


The "final version" was published in February 2009.


I was not aware of this, and perhaps many of today's readers as well.

Ooh, watching that caused me too much fremdschämen. Neat concept, though.

Thanks for introducing me to a great new word.

Thank you for showing us that clarity and brilliance isn't always as easy as the final product makes it appear.

Make an option to add sound (select an mp3 or microphone) and you have the most amazing learning tool for programing; it would be like a videotutorial where you can directly copy the code!

edit: redaction

This is wonderful -- it should be left running on a large (but cheap) monitor in every small company's breakroom.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact