Watch Me Make Mistakes
paulgraham.com
paulgraham.com
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.
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.
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.
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 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.
- 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.
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.
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.
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.
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.
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.
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.
"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.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.
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.
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?
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.
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.
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.
(If its not ok to post self links, let me know and I'll delete)
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.
Hopefully they started from a better point than the vanilla code dump: https://github.com/mattsta/etherpad
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.
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)
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.
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?
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.
Edit: Works in UIWebView though - might be a bug in the nitro JS engine.
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.
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.
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.
that's a 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.
Watching someone think character by character is far more illustrative.
edit: amusingly, I had to go edit the comment. I find that very reflective of the original article.
I guess growing up with computers and not being able to spell are not synonymous.
Walter W "Red" Smith
well done
> 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.edit: redaction