Jekyll2021-07-20T14:41:46+00:00https://aaronhayman.com/feed/writing.xmlAaron Hayman | WritingAspiring WriteriOS Writing Bliss2020-09-13T00:00:00+00:002020-09-13T00:00:00+00:00https://aaronhayman.com/ios-writing-bliss<p>I have absurd requirements when it comes to writing. A big part of this comes from the fact that I’ve been developing software for over a decade. I have certain habits, tools, and expectations for how my work should proceed. Let’s detail out my… issues.</p>
<!--more-->
<h2 id="git">Git</h2>
<p>I keep all my work versioned using Git. This is absolutely a requirement for anything I do. For those who don’t know, Git is a system through which you “commit” changes (work you’ve done). Those changes are saved as a point in time, allowing you to restore your work to any commit.</p>
<p>There’s a mental freedom in writing that Git affords you. Specifically, Git makes it easy to delete stuff you like. I can’t count how many times I’ve written a wonderful scene that doesn’t fit. I know it needs to go, but there was so much good stuff in there. With Git, I know I can always go back and find it, which makes it much less painful to delete. Without Git, I would have a much harder time deleting stuff.</p>
<h2 id="vim">Vim</h2>
<p>I’ve become addicted to a very specific way of entering text: Vim.</p>
<p>Most people won’t know what Vim is. It hails from the days before GUI’s (graphical user interfaces) when all text had to be manipulated using the keyboard alone. This is the realm of command prompts and text-only interfaces, where finger-dexterous wizards ply their craft using weird and obscure runic-like symbols sent spiraling into the black ether. In those days, we called it VI, but it has since then been iMproved… thus, Vim.</p>
<p>Vim operates in three modes: command, insertion, and selection.</p>
<p>In command mode, the keyboard performs commands instead of entering text: <code class="language-plaintext highlighter-rouge">j</code> moves the cursor down a line, <code class="language-plaintext highlighter-rouge">k</code> moves it up a line, <code class="language-plaintext highlighter-rouge">h</code> moves right, <code class="language-plaintext highlighter-rouge">l</code> moves left. <code class="language-plaintext highlighter-rouge">e</code> moves to the end of the word, and <code class="language-plaintext highlighter-rouge">w</code> moves to the beginning of the next word. I can delete a word with <code class="language-plaintext highlighter-rouge">daw</code> or delete a sentence with <code class="language-plaintext highlighter-rouge">das</code>. There are thousands of combinations.</p>
<p>In insertion mode, the keyboard does what most poeple think it should do: it enters text just like any text editor. To leave it for command mode, I press escape.</p>
<p>Selection mode: This is a special command mode that allows you to select visual blocks, or columns of text, then perform commands on each row of that text. I could, for instance, select several rows, press <code class="language-plaintext highlighter-rouge">i</code> to enter insertion mode, and then press ` - ` to prepend a dash to every selected row at once.</p>
<p>If Vim sounds absurdly complicated, that’s because it is. It took me over a month to become vaguely proficient at it, and several months to get back to “normal operating” speed. Yet from there, I continued to improve as muscle memory allowed me to perform edits faster than I could ever have managed before.</p>
<p>It’s hard for me to overstate just how efficient Vim has made me. In the time it takes you to reach for the mouse, I’ve already rearranged the sentence.</p>
<p>As a secondary bonus (but one of the primary driver for me), it’s all but eliminated RSI (repeative stress injuries). With “normal” text editors, you’re constantly “reaching” for the arrow keys, the mouse, or twisting your hand to copy/paste/etc. With Vim, that’s all gone. All the commands I need are on the keyboard, no twisting required.</p>
<h2 id="cloud-sync">Cloud Sync</h2>
<p>Technically, Git can be used for syncing but it’s a manual process: you commit and push the changes to a server, then pull those changes on another computer. It works… but I can’t count how many times I forgot to push changes, leaving me without my latest work on another device.</p>
<p>So I rely on a secondary syncing service to keep my changes in sync. For a long time this was Dropbox. I’ve moved away from that lately <sup id="fnref:4" role="doc-noteref"><a href="#fn:4" class="footnote" rel="footnote">1</a></sup>, choosing to roll my own syncing server using NextCloud. In both cases, all the changes I make our automatically synced between machines.</p>
<h2 id="ios">iOS</h2>
<p>I’ve long had a love-hate relationship with iOS when it comes to writing. I’ve done significant portions of my writing on my iPhone and that is nothing short of amazing. I have vivid memories of writing stories with one hand while a sleeping baby rests in my arms. That would not be possible without the incredible app ecosystem iOS provides.</p>
<p>And yet… Git and cloud sync doesn’t work together. I can have both, but not at the same time. There is a fantastic little app called “Working Copy”, a full git client, that I can use to get, make, and push changes with. However, it did not sync with cloud providers like Dropbox, and it’s text writing system (mostly geared toward coding) leaves much to be desired. There were <em>other</em> apps I could use to write and some of them <em>did</em> sync to cloud providers (Ulysses was my favorite), but I couldn’t use them to push changes (save/commit my work).</p>
<p>Finally, there was the iPad. With a full keyboard, the iPad <em>should</em> be a fantastic text editor. It should be, except for one tiny omission: there’s no escape key.</p>
<p>There have been attempts to create a Vim editor in iOS. For the most part these have worked except for the damn escape key. It is, simply put, a foundational part of Vim.</p>
<p>On my Mac, I long ago remapped the Caps Lock key to Escape, allowing me to transition to command mode easily and with the least strain to my wrist as possible. With no Escape key on an iOS keyboard (and no way to even send an escape command), the editors always had to resort to some other means: an on screen escape key, or customizable key combo like ctrl+c. Sure, it works, but Vim is all about muscle memory and my text was littered with capitalized nonsense as I habitually used what now comes natural.</p>
<p>So, I gave up.</p>
<h2 id="bliss-in-a-bottle">Bliss in a Bottle</h2>
<p>Then iOS 13.4 came about. It took me three point releases to realize what had happened (or really, I just happened upon an article). Apple, for some unfathomable reason, decided to allow users to remap the Caps Lock key. One of the options? Escape.</p>
<p>I almost cried.</p>
<p>I immediately went on an search to see if there were any apps that utilized this. I found a few, wasted some money, but then discovered there was a full Vim port called iVim <sup id="fnref:1" role="doc-noteref"><a href="#fn:1" class="footnote" rel="footnote">2</a></sup>. I have no idea how they managed it. I didn’t think Vim was programmed in a language iOS could consume, but apparently yes? And not only does it work, but you can load a surprisingly large number of plugins <sup id="fnref:2" role="doc-noteref"><a href="#fn:2" class="footnote" rel="footnote">3</a></sup>, which is incredible– Vim is a very customizable editor, and this allows me to make it exactly the way I want it. Don’t like the colors? You can change those. Want a status bar on the bottom that tells you your word count? Done. So lovely.</p>
<h2 id="full-integration">Full integration?</h2>
<p>So now I’ve Vim, actual Vim on my iPad. Yay.</p>
<p>Now I need to figure out how to actually use it. Typing my stuff in a random buffer doesn’t work well unless I can save it somewhere. More importantly, I need to edit my file, the same ones I normally edit on my Mac. After some playing around, I discover something really important about the Files app: Once you “favorite” an app, Files will automatically open that app when you tap on a file that is supported by that app.</p>
<p>Now, take this whole idea of “automatic open” and combine it with a split screen: Files on left, iVim on the right. Tap on a markdown file, and it opens in iVim on the right. This is the <em>exact</em> configuration I use on my Mac. Moreover, I can write my own scripts if I want to <sup id="fnref:3" role="doc-noteref"><a href="#fn:3" class="footnote" rel="footnote">4</a></sup>.</p>
<p>Friends, I am home.</p>
<p>Moreover, Working Copy exposes all it’s file structures to Files. This allows me to access them directly and then, once I’m done, I can push all those changes up easily. Even better: this is exactly how my website accepts new posts. So I can now use my iPad to post to my website easily, and using my favorite editor.</p>
<p>I have only one missing piece, and it’s:</p>
<h2 id="icloud--git--disaster--bliss">iCloud + Git == Disaster || Bliss</h2>
<p>Working Copy allows you to specify “synced folders”. These are folders that are synced via the cloud, but should also be git repositories as well. This <em>should</em> allow the best of both worlds. I haven’t tried it yet, but my theory is that these synced folders would allow me to edit as I please, then go into Working Copy and save/commit them. If so, it’s essentially the last piece of the iOS puzzle for me.</p>
<p>I suspect caveats.</p>
<p>For instance, there’s a good chance those synced folders only sync when Working Copy is actually open. If so, then editing anything from Working Copy within the Files app is asking for trouble. This is manageable; I just need to hide the Working Copy folders from Files (doable).</p>
<p>The second issue: iCloud is notorious for handling git wrong. Git tends to shuffle, move, and edit a lot of files behind the scenes, especially when you commit. All of those changes need to happen or you can corrupt your repository. iCloud does not always handle this well. I’ve heard horror stories, but I’ve also heard of successes. I suspect it depends on usage: maybe don’t try to sync multiple computers all editing the files at once. But I have only my Mac, my iPad, and my iPhone. Is that too much? I dunno.</p>
<p>I also already use a different syncing service, one I control, and one I happen to like. When things fail, it gives me actual errors I can use to track down the issue and fix it. If something goes wrong, I can SSH into the server and literally fix the files in question. iCloud is a black magic box that fails silently.</p>
<p>But I’m tempted. I already have 2TB of storage for photos that use maybe a quarter of the space. If I can trust iCloud – and that is a big honking <strong>if</strong> – then it would be ideal (a lot of apps support iCloud implicitly). But Apple doesn’t have a great record with stuff like this. Yet… I’m tempted, folks, very tempted.</p>
<p>We’ll see.</p>
<h2 id="conclusion">Conclusion</h2>
<p>So now I’m writing this post in Vim on my iPad, something I never thought would be possible. Even more impossible: I’ll submit this post with said iPad.</p>
<p>Life is getting better folds; it truly is.</p>
<p>And now that I’m done writing this, perhaps I will go on to work on my book, in an editor I love, on a device I love.</p>
<div class="footnotes" role="doc-endnotes">
<ol>
<li id="fn:4" role="doc-endnote">
<p>This was frustrating. Dropbox practically created the market for file syncing. And I generally don’t mind companies expanding into new markets, it’s practically the ethos of tech, but I draw the line when they start forcing their new stuff into my face without any recourse to back out. Okay, cool: you now allow multiple people edit files at the same time. But for all that is holy: I just want to sync. I don’t care. Stop invading my space! <a href="#fnref:4" class="reversefootnote" role="doc-backlink">↩</a></p>
</li>
<li id="fn:1" role="doc-endnote">
<p>There’s also an old ‘port’ simply called Vim. I’ve seen it before, but it was limited. iVim, in contrast, appears to be not only a full port, but it’s also very integrated into iOS. <a href="#fnref:1" class="reversefootnote" role="doc-backlink">↩</a></p>
</li>
<li id="fn:2" role="doc-endnote">
<p>There are some very clear restrictions: Plugins that either depend on underlying subsystems (ex: Java, or whatever) or must build said dependency don’t work. There are several a lot of plugins that have to cmake or compile a separate program. Luckily, I don’t really use those. <a href="#fnref:2" class="reversefootnote" role="doc-backlink">↩</a></p>
</li>
<li id="fn:3" role="doc-endnote">
<p>And yes, I have done just that in the past. Sometimes, be a software developer is <em>awesome</em>. <a href="#fnref:3" class="reversefootnote" role="doc-backlink">↩</a></p>
</li>
</ol>
</div>I have absurd requirements when it comes to writing. A big part of this comes from the fact that I’ve been developing software for over a decade. I have certain habits, tools, and expectations for how my work should proceed. Let’s detail out my… issues.Iteration2020-05-19T00:00:00+00:002020-05-19T00:00:00+00:00https://aaronhayman.com/iteration<p>I’ve been somewhat astounded by just how similar writing is to software development <sup id="fnref:1" role="doc-noteref"><a href="#fn:1" class="footnote" rel="footnote">1</a></sup>. This is probably a self fulfilling prophecy. I’ve been developing software for years, so of <em>course</em> I’d take the skills I learned there and apply it to my writing.</p>
<p>So perhaps I should rephrase: I’m amazed at how well my own personal principles of software development have translated into writing.</p>
<p>It seems to me that many of the issues so many writers have <sup id="fnref:2" role="doc-noteref"><a href="#fn:2" class="footnote" rel="footnote">2</a></sup> could be mitigated by approaches developed for writing software. There’s a lot of “principles” or approaches I could cover, but I’d like to focus on one: iteration.</p>
<!--more-->
<p>I never, ever expect the first words I write to be… well, good. I expect to rewrite them; I expect to rewrite them <em>a lot</em> — once, twice, five, even a dozen times. In other words, I expect to iterate my writing.</p>
<p>To me, this is perfectly normal. I would never write code and expect it to run flawlessly the first time. I’m never surprised when I get half way through writing some piece, only to realize I could have done it a better way; then I scrap what I’ve written and write it the better way.</p>
<p>Yet one of the main problems I hear advice for is: “the empty page”. Authors, sitting at their desk, staring into space, waiting for inspiration, while an empty page sits before them. It’s a dreaded thing, this blank sheet. It conjures images of boundless potential; it conjures feelings of a vast, empty space just waiting to swallow you whole.</p>
<p>“What if I get it wrong?”</p>
<p>“What if it’s <em>bad</em>?” (gasp!)</p>
<p>“What if people hate what I write?”</p>
<p>“What if…” — well, I bet you can fill in the blank.</p>
<p>But I barely notice the empty page. All of the advice about overcoming writers block always seemed over-wrought. It took me time to realize why: I expect to iterate.</p>
<p>If you expect to rewrite, it frees you to write in the first place. It doesn’t matter whether the words are good or not; it doesn’t matter if the story is good or not. You can make it better on the next pass. Perhaps more important: Every word you put down, whether good or bad, makes you just a little better.</p>
<p>You can always make the words you put down better, so long as you’ve written words down in the first place. So write.</p>
<p>I get a particular satisfaction in improving things. I like it. I like the satisfaction I feel when the second iteration is better than the first, when the third is better than the second.</p>
<p>Some would argue that it doesn’t need to be perfect, that by trying to be perfect, you run around in circles. And yes, if you’re on your thirtieth iteration, it might be time to move on. But that is not the problem most people have. I would argue that the process of improving, of <em>perfecting</em>, your writing is essential. It is, at least in my opinion, the best way to learn.</p>
<p>Read all the books you want; they’ll help. But the act of improving your own writing will embed those lessons in a way that no book can.</p>
<p>Coincidentally, this is generally called ‘editing’.</p>
<p>So yes, learn to edit your own books; learn to iterate. Not only will you become a better writer that much quicker, but publishers appreciate writers who don’t foist all the editing work onto them. And if you self-publish, readers will appreciate it all the more.</p>
<div class="footnotes" role="doc-endnotes">
<ol>
<li id="fn:1" role="doc-endnote">
<p>My day job. <a href="#fnref:1" class="reversefootnote" role="doc-backlink">↩</a></p>
</li>
<li id="fn:2" role="doc-endnote">
<p>Issues I’ve gleaned from reading books on what (not) to do when writing, or by watching videos, or by listening to podcasts, etc. Since I don’t actually know <del>many</del> any writers personally, I can only guess at what issues they have from all the advice out there for writers. — Secondary text to test scrolling, which means i need a lot more text and i don’t really care about punctuation or anything like that; just the words on the screen and how they feel and look and many many words scrolling over and over and over again. I should have copied and pasted gibberish, really. <a href="#fnref:2" class="reversefootnote" role="doc-backlink">↩</a></p>
</li>
</ol>
</div>I’ve been somewhat astounded by just how similar writing is to software development 1. This is probably a self fulfilling prophecy. I’ve been developing software for years, so of course I’d take the skills I learned there and apply it to my writing. So perhaps I should rephrase: I’m amazed at how well my own personal principles of software development have translated into writing. It seems to me that many of the issues so many writers have 2 could be mitigated by approaches developed for writing software. There’s a lot of “principles” or approaches I could cover, but I’d like to focus on one: iteration. My day job. ↩ Issues I’ve gleaned from reading books on what (not) to do when writing, or by watching videos, or by listening to podcasts, etc. Since I don’t actually know many any writers personally, I can only guess at what issues they have from all the advice out there for writers. — Secondary text to test scrolling, which means i need a lot more text and i don’t really care about punctuation or anything like that; just the words on the screen and how they feel and look and many many words scrolling over and over and over again. I should have copied and pasted gibberish, really. ↩Work and Play2020-01-14T00:00:00+00:002020-01-14T00:00:00+00:00https://aaronhayman.com/work-and-play<p>I first started writing a couple of years ago. I did it on a whim. I was tired of reading the same thing and wanted to try my hand at writing something I’d like.</p>
<p>Unlike most people (I think), I don’t always learn first what I need to do before I do it. I often try to learn the absolute minimum, then tackle the largest project I can with what I know. I then look back and ask myself, “What did I do wrong?” So long as I can figure out at least a little bit of what went wrong and why, I can then go back and fix those things.</p>
<p>On the plus side, I’m not the kind of person who finds themselves stuck with writer’s block, or writer’s paralysis, or the ever-learning but never-doing cycle. I write, then I edit.</p>
<!--more-->
<p>The first draft of my book, which I’m currently calling “A Storm of Knives” (not final), was an absolute train wreck. I was sure there was a story there, but not even I could read it. If ever there was a newbie writer’s mistake, I made it.</p>
<p>So I bought a few books on self-editing, my favorite of which was “Self-Editing for Fiction Writers,” learned a lot about what I did wrong, and then spent the next year re-drafting the book six or seven times.</p>
<p>In December of last year, <a href="worldbuilders.org">World Builders</a> launched a charity auction where authors, editors, and agents would offer their services on eBay and give the proceeds to charity. It seemed like a good opportunity, so I bid on a few authors and one editor. I won the bid for the editor.</p>
<p>It was a stroke of luck. I’d already started to suspect I was hitting a wall with my writing. Even when I <em>did</em> write better, and even when I could tell, I couldn’t explain exactly why one thing I wrote worked better than another. If pressed, I might say it flowed better, or felt better, or something else equally ambiguous.</p>
<p>The editor changed that. He gave me the details of what exactly I was doing wrong and why. He gave me a framework from which to understand how to improve my craft and why.</p>
<p>I’m now working on draft… eight? nine? and I’ll probably end up drafting more after this one. So, by the time the book is publishable, I’ll have rewritten the thing something like ten times or even more.</p>
<p>Then I hear about new authors who wrote a book, never re-drafted, and don’t understand why nobody wants to read it. They don’t realize they need at least another ten drafts.</p>
<p>Some authors write new books instead of re-drafting old ones. It’s a valid approach though I feel they are missing out. I can see and compare my work directly with itself as I get better. That is valuable, and I get the satisfaction of watching the original idea come together, rather than having to get over the disappointment of letting it go to write the next new thing.</p>
<p>Of course, and this is important, personality matters. I have a personality skewed toward fixing things, improving them. Like an artist that starts out with a rough sketch, I enjoy seeing those lines get ever refined into something beautiful. Not everyone is like that, and it’s very important to find a way that works for you.</p>
<p>But no matter what you choose, it takes work. It always will. But just because it’s work, doesn’t mean it can’t be fun.</p>I first started writing a couple of years ago. I did it on a whim. I was tired of reading the same thing and wanted to try my hand at writing something I’d like. Unlike most people (I think), I don’t always learn first what I need to do before I do it. I often try to learn the absolute minimum, then tackle the largest project I can with what I know. I then look back and ask myself, “What did I do wrong?” So long as I can figure out at least a little bit of what went wrong and why, I can then go back and fix those things. On the plus side, I’m not the kind of person who finds themselves stuck with writer’s block, or writer’s paralysis, or the ever-learning but never-doing cycle. I write, then I edit.