4 ms·
Oh really? Everything? In ten minutes? Well, I am reading this, then I will reply to this comment and you all can judge for yourself. - Edit: see my reply,
by logicallee 12y ago
Oh really? Everything? In ten minutes? Well, I am reading this, then I will reply to this comment and you all can judge for yourself.
-
Edit: see my reply, in which I use the rules I just learned. This was a genuine experiment. Any feedback is appreciated. :)
- logicallee 12y agoI've now read the piece. In it, King starts by saying that it will really take me 20 minutes; but I looked and it's only been ten. Surprisingly, a lot of this applies quite well to the start-up scene. Here are his main points: 1. You have to be talented. Writing is useless if there's nothing left after you've taken all the extra words out. But rejection is okay: six rejections are okay. So are sixty. Six hundred is pushing it. Six thousand rejections and you can give up on the startup scene. Er, I mean writing. And you'll know when you're getting closer, too. You'll receive notes back. Personal phone calls. 2. Be neat. 3. Be self-critical. If you're not reverting commits you're not committing enough. Er, drafts. if you're not marking up drafts of your writing you're not doing it right. 4. Get to the point and remove every extraneous file. I mean word. Cut the words out. 5. Never look at reference materials while writing, or you'll lose your train of thought! Just put in a dummy function. You can look it up later. That dummy code will still be there. (His example was misspelled words.) 6. Know the markets. You wouldn't publish a link to closed source iOS app on Github, would you? But I've seen people doing that. 7. Write to entertain. Like I'm doing. You can write serious things, but if you want to preach get a blog. 8. Ask yourself: am I having fun? If the answer is anything OTHER than "I don't even remember what fun is" your startup is in good shape. You don't always have to have fun, as long as you sometimes do. 9. How to evaluate criticism. This is a good one: show your work to ten people. Listen carefully. If everyone is telling you your thing sucks, and everyone is giving you a different reason, that's okay. People suck and you can ignore all of them. However, if they start mentioning the same reason, then you know what to change. It doesn't matter if you're attached to it: change it. 10. Observe protocol. Pitch decks and all that. Get introductions. 11. Salespeople? Forget it. They won't care about you or work for you on commission until you're big enough to steal from. Sell your product yourself. ("flog your stories around yourself... send around query letters one by one, and follow up with samples.") 12. If it's bad, kill it. That's it. And this only took me ten minutes to write. Now let me edit for 5. - Done. I've now edited this for another 7 minutes. This is what it looked like before my edit if you're curious (right after I finished writing 'let me edit for 5'): http://pastebin.com/uD8YKxBh http://pastebin.com/uD8YKxBh
- velox_io 12y agoI was thinking how this applies to programming/ startup's too. I would say 5 is more about over-engineering, when a much more straightforward technique would work. Code is malleable, you can always come back to it.
- eru 12y agoYou can learn most of what you need to know about weight lifting in ten minutes. Doesn't mean you can get strong in ten minutes.
- hessenwolf 12y agoHell no. Crack, crack, knees and back.
- brudgers 12y agoNow, how to play the flute. (picking up a flute) Well you blow in one end and move your fingers up and down the outside. http://www.montypython.net/scripts/howtodoit.php http://www.montypython.net/scripts/howtodoit.php