61–70 of 95 posts
Works a treat, even if you liver may not fully appreciate it.
[0] Whiskey may be substituted for your preferred liquor, but it is a solid traditional writers' choice
[1] TL;DR 'Write drunk, edit sober'
I hated writing then. It was just painful. I procrastinated any writing assignment till 2am the night before it was due.
Now I love writing. Writing is often something I do when I'm procrastinating something else. (ummm, that would include right now I guess)
I'm not a linear thinker and forcing myself to do it that way would just be a way to make me hate writing again.
All perspectives have been successful tech book authors.
The more difficult thing is how you collaborate with coauthors with different writing style that might conflict with yours.
All I can say is, I am old enough that I remember when writing rough drafts, by hand, on paper, was how you did writing. If you changed your mind right after you wrote something, it was awful because you had to squeeze it in between the lines or in the margins or draw circles and arrows and such. I hated writing then. It was just painful. I procrastinated any writing assignment till 2am the night before it was due. N…
FWIW I learned to write longhand and then using an early electronic typewriter with only three lines of text retained in memory. Modern word processors have been great. Sometimes, though, when planning something out, I'll use a paper notebook.
This might be an unpopular opinion but I always edit while writing my first draft. This is how I've written 250+ technical blog posts and over a million words worth of course notes. I basically write a couple of sentences or paragraphs, stop, review, reword things if needed, change things around and move on. Then at the very end I'll give it all a final reordering / fixing until I'm happy with it. I feel like I can't…
This conversation is simply the English-equivalent of TDD conversations. * Conventional development = writing, then editing * Test-driven development = writing and editing simultaneously The preferences are endless and neither removes the most difficult part which is the conceptual architecture. Personally, I like to splatter a whole bunch of ideas down first and then later go back and commit.
This might be an unpopular opinion but I always edit while writing my first draft. This is how I've written 250+ technical blog posts and over a million words worth of course notes. I basically write a couple of sentences or paragraphs, stop, review, reword things if needed, change things around and move on. Then at the very end I'll give it all a final reordering / fixing until I'm happy with it. I feel like I can't…
I also start writing in a fairly basic text editor, not a word processor, which makes it easy for me to reorder that point form outline with my keyboard and get the flow of the major points down before I start the actual writing.
The text editor also prevents me from spending too much time on that 5% of improvements until the very end. But, I do edit major grammar issues and color as I go since, like you, I feel like I can't move on until it sounds right, and the way I say something often shapes what comes next. Still, having an outline helps me get into those weeds a little bit in the moment and not lose sight on where I'm going next.
I can't stress the outline enough. I wish I did it in the early days, but I wasn't able to "see" the whole story from the beginning back then. Now, I find it is the thing that helps me see what is important to the topic. Sometimes I feel like I need to talk about a point up front but after roughing it out I realize it's actually more interesting and easier to understand if I hold it back until the end. Conversely, there are some really interesting things that can't be explained until the end but I can tease them up front to build excitement and then explain them after the foundation is laid.
cat /dev/stdin > yourfile.txt ctrl+d to exit. You can edit the current line (to fix spelling misteaks) but not anything else. You can reference as much as your terminal shows. This is a perfect example of the superiority of the Unix way. Simple programs that do one thing and work well together, combined into things their authors didn't think of. This is my idea of beauty.
cat > yourfile.txt :)
Shameless plug - my app, Writing Streak, has the "typewriter" mode (Alt+T) that prevents you from editing the text you wrote, and a "blurred" mode (Alt+B) that hides the text you type, achieving the same effect: https://writingstreak.io
Blurring everything makes it impossible to fix (or see) typos which is annoying, knowing that the output of the thing is going to be full of typos. Hiding texts has another issue (even if not hiding the current line), that is you don't even have a rough idea of how much you've written and what the paragraph lengths look like so far.
If we do blur, but don't blur the current line, it solves both problems for me.
All I can say is, I am old enough that I remember when writing rough drafts, by hand, on paper, was how you did writing. If you changed your mind right after you wrote something, it was awful because you had to squeeze it in between the lines or in the margins or draw circles and arrows and such. I hated writing then. It was just painful. I procrastinated any writing assignment till 2am the night before it was due. N…
It wasn't so bad when you were writing something that was going to get retyped anyway (like for a newspaper). But a lot of the time something like a paper just basically got submitted as essentially a rough draft because you weren't going to edit and retype it.
Either way, there was no way I'd turn in my rough draft as a final, as it would either be a mess to look at, or terribly/confusingly written.
I just don't see the benefit of imposing a linear process. I prefer to start my writing with what comes easily, and immediately start tweaking.