Work Logging

Joey Hess' blog of his work on git-annex-assitant has been a great inspiration to me. Basically, Joey had a very successful Kickstarter campaign to fund his work on a very cool tool of his that he wants to expand to be a kind of drop-box replacement. As part of the project, he's been blogging nearly every day about the work, his progress, and the problems he's faced.

I really admire this kind of note taking, and think it's really interesting to see how people progress on cool projects. More than that, I think it's a cool way to make yourself accountable to the world, and help ensure things get done.

By the same token, when your project work is writing, increasing daily workload by writing notes/posts rather than actually doing work is a problem, on the other hand, given the right kind of templates, and a good end of day habit, it might be easy and a good habit.

Anyone else interested in this? Thoughts on using rhizome versus some other area of tychoish.com? So many choices!

Analog Editing

After doing the first pass of editing on my technical book, "Systems Administration for Cyborgs" on a screen and feeling utterly buried by it, (See: /posts/the-editing-hole,) and I'm considering different approaches for the next book. Specifically, for this novel I have, I'm thinking about getting the novel printed somehow and then editing it "analog style."

I'd love to hear feedback from anyone who has done this, particularly recently. Particularly from people who are very digitally savy. Here's my pro/con list:

Pros:

  • It might be nice to have a different "editing context," to help me keep focus on the project without the distractions of the internet and current writing projects.
  • Having marked-up pages gives me an actual marker of progress, rather than a list of commits or diffs.
  • It might be nice to get some practice writing longhand again. It's embarrassing when someone hands me a pen and I've basically forgotten how to use it.
  • It gives me a start to a collection of paper ephemera that I can burden some archivist with at some point.

Cons:

  • Context switching, from a computer, to paper, to a tablet, or whatever is annoying and eats time/focus.
  • Paper would force a more linear editing process, which may get me to focus on the story and characters more closely at the possible expense of seeing "broken sentences," and other things that may be distracting to the next readers/editors/etc.
  • If I edit on paper, I have to go through and apply those changes to the actual text. Which adds a step, and probably a number of additional weeks to the editing process.
  • I'm awful writing things out long hand and I pretty much haven't written anything long hand in 4 or 5 years.

Reflections

There's also another little thorny problem: I'm not sure what the future of this book is: The prologue stands alone, and I want to try shopping it around. If I can get that published as a short that might be the hook to getting the rest of the book published.

Initially my plan was to have a friend read it as a podcast, and attempt to publish the prologue as a short, and then try and for-real publish the next book. The podcasting idea, while nice, wouldn't work out as originally planned (long story.) Besides, it really depended on having someone else to the reading (I have neither the time, technical skills, nor the real ability to do the reading.) Which leaves me without a plan, and the following thoughts about the publication of this text:

  • I feel like my writing career [1] is in good (enough) shape that my identity as a writer depends on publishing this novel in a particular way.
  • On the other hand, getting the novel (or parts of it published) would be a great thing, and validates all this time/energy/interest that I have in writing science fiction.
  • I'm not opposed to self publishing, except that it means more work for me for what is probably less impact (i.e. readers.)
  • It took me embarrassingly long to write this novel. And knowing how much better my writing has gotten in the last three or four years, means that I'm pretty worried that this is really a cold pile of shit. I recognize that this is probably more reason to get the novel out to first readers, but I also feel like I should do them the favor of at least a little editing.

Printing in the Digital Age

As an aside, this has given me some time to do research on getting things printed, which I'd like to record here and share with you:

(Given a 325-350 page manuscript)

  • I don't own a printer, and have no particular interest in owning one, but a good color laser (in the 300-400 USD) or a good black and white (200-300 USD) becomes much more economical if analog editing becomes a thing.

    The downside of printing things yourself is that you still need some way to bind things. And there are maintenance and supply costs not factored into the above.

  • The price to get printing/binding done at Staples is in the 35-40 range. Chances are that these copies are likely to be the highest quality, quickest turn around, and the web interface--though annoying--is probably the most straight forward.

  • You can use Lulu.com to order prints. The same book costs 15 bucks. It's also spiral bound (which seems preferable to perfect binding for writing.) I'm not sure what "lulu standard" paper is like quality wise, but I suspect it will be ok. If you're ok with a fussy online interface, a weird approach to covers (no really, I'd just like transparent covers,) and turn around time, the price seems unbeatable.

Also, Lulu's cover making interface makes it really hard to get a plain cover that doesn't look like a joke.

I did some hunting around for local copy shops (I swear it seems like I pass several on my walk to work,) but had difficult finding a shop who would be able to do a very small order, and has the digital setup to accept a PDF for printing via email or a web site.

[1]I have a full time job writing and editing. While its not the same as writing fiction, it is rewarding and economically viable, and I'm working on the kinds of projects that I want to work on. Can't argue with that.

The Editing Hole

I'm stuck in an editing hole, and not only am I not editing the things I need to edit, I'm not getting anything done.

I'm at a point where I have about 25 things on my personal task list, and 16 of them are editing related tasks: edit the article in this file, edit this fiction, edit this documentation, edit these would-be-blog posts, and so forth. It seems like I went on something of a six month writing bender, and while I did a little bit of editing during this period, I have clearly fallen behind.

There are a number of factors:

1. I've been making a point of putting editing tasks on the todo list because I want to make sure that I actually finish projects rather than just abandon them. I've not been particularly good with follow through in the past few years, so that's been a big personal improvement project.

The sad part is that my editing queue is probably 10-20 times larger, but I've got some projects on the less-actionable back burner.

  1. I'm not a very good editor.

I'm awful at copy (or otherwise) editing my own work, and while I know that I've become better at this in the past few years. I still know that it's not perfect and so it seems sort of futile, which makes it hard to get inspired to do editing.

3. I find writing to be rewarding, and given the choice I will probably always choose to write new stuff. While this is clearly a learned response to the kind of work, this doesn't make the effect any less real.

  1. I find editing to be really difficult work.

This is probably related to #2, but editing wears me out. I find it difficult to spend long periods of time editing, which makes it difficult to make any really substantial progress on the pile of editing tasks.

As a result, I take a long time to edit things, I'm most effective at editing in short bursts. I often want to break up longer editing tasks with other kinds of work just to keep a clean mind set. After a week or so of this, I have almost everything else done on the list, leaving me with a big pile of editing that looks even bigger for the lack of other things on the list.

So now, I'm trying the following:

1. I'm working on making editing tasks smaller, which will turn into more editing tasks, but it'll be possible to face editing tasks in units less than 10 or 20 pages.

  1. Make more tasks for other projects.

There are two ways to get stuff done: 1) You can be really focused and work on one project at a time until it's finished, or 2) you can be working on a lot of projects in parallel and when you start to loose focus, you switch to another kind of project. The idea is that you end up getting more done because you're being productive more of the time. I subscribe to the second theory.

Here's hoping it works!

Onward and Upward!

Limitiations of GitHub Forks

Assumption:

  1. git is pretty awesome, but it's conceptually complex. As a result using git demands a preexisting familiarity with git itself or some sort of wrapper to minimize the conceptual overhead.
  2. The collaboration methods (i.e. hosting) provided by git, which are simple by design to allow maximum flexibility, do not provide enough structure to be practically useful. As a result providers like GitHub (and BitBucket and gitorious) offer a valuable service that makes it easier--or even possible--for people to use git.

Caveats:

  • there are problems with using centralized repository services controlled by third parties, particularly for open source/free software projects.

    There are ways that GitHub succeeds an fails in this regard. but this dynamic is too complex to fully investigate within the scope of this post.

  • If you use GitHub as designed, and the way that most projects use nGitHub, then you have a very specific and particular view of how Git works.

    While this isn't a bad thing, it's less easy to use git in some more distributed workflows as a result. This isn't GitHub's fault so much as it is an artifact of people not really knowing how git itself works.

Assertions:

  1. GitHub's "fork" model[^fork] disincentives people from working in "topic" branches.

  2. By making it really easy for people to publish their branches, GitHub disincentives the most productive use of the "git rebase" command that leads to clean and clear histories.

  3. There's no distinction between a "soft fork" where you create a fork for the purpose of submitting a patch (i.e. a "pull request") and a "hard fork," where you actually want to break the relationship with the original project.

    This is mostly meaningful in context of the other features that GitHub provides, notably the "Network" chart, and the issue tracker. In a soft-fork that I would intend to merge back in, I'd like the issues to "come with," the repository, or at least connect in some way to the "parent." For hard forks, it might make sense to leave the old issues behind. The same with the network chart, which is incredibly powerful, but it's not great at guessing how your repository relates to the rest of its "social network."

The solution: keep innovating, keep fighting lock-in, and don't let GitHub dictate how you work.

Making Things Easier

I spent a lot of time in the past few months thinking about "automation," as a project to take things that take a long time and require a lot of human intervention into things that just do themselves, and I think this is the wrong approach.

While total automation is an admirable, it's difficult, both because it requires more complex software to deal with edge cases, but also because it's hard to iterate into a fully automated solution.

Let's back up for a moment and talk about automation in general.

Computers are great at automating things. When you figure out how exactly to accomplish something digitally (i.e. polling an information source for an update, transforming data, testing a system or tool,) writing a program to perform this function is a great idea: not only does it reduce the workload on actual people (i.e. you.) I think the difference between people who are "good with computers," and people who are "great with computers," is the ability to spot opportunities for these kinds of automations, and potentially implement them..

To my mind the most important reason to automate tasks is to ensure consistency and to make it more likely that tedious tasks get done.

Having said this, rather than develop complete task automations for common functions, the better solution is probably to approach automation on the bottom up: instead of automating a complete process, automate smaller pieces particularly the most repetitive and invariable parts, and then provide a way for people to trigger the (now simplified) task.

The end result, is a system that's more flexible easier to write, and less prone to failure under weird edge cases. Perhaps this is a manifestation of "worse is better" also.

Thoughts?

Onward and Upward!

A Life Changing Laptop Riser

*tl;Dr>* I got one of those nifty laptop risers that puts your laptop up closer to eye level, and it has pretty much improved all of my interactions with computers a thousand fold and it's made it possible for me to effectively use two screens. This post explores this.


One of my coworkers had a laptop stand she wasn't using and I asked to borrow it for an afternoon, and my neck stopped hurting. I never thought my neck hurt before, but apparently it does.

Or did.

But there's more: for years now I've kept an extra monitor around (and had one at work) but the truth is that I have never really felt like I've been able to get the most out of an external monitor.

Somehow, putting my laptop 4 inches in the air was the little change that made everything better. The laptop is generally on the left of the external monitor, and I have task lists, notes buffers, the chat window, and my status logging window on the laptop, and then three windows on the external (emacs buffer, terminal, emacs buffer) on the right. My primary focus centers between the monitors, but probably edges slightly toward the external, most of the time.

Also, I discovered that I--apparently--have a slight processing/attention defect whereby I find it painful and difficult to focus on things that are happening on the right side of the screen for any amount of time. Which is weird because my right eye has always been noticeably stronger. I'll ponder this more later.

My virtual desktops for email and web browsing are a bit less rigid, but the same basic idea. Somehow it seems to work. I've done a little bit of work recently to get the layouts right, to minimize the impact of the window management of most context switching (scripting various transitions, saving layouts, etc.) In all things are going great.


It strikes me that I've not posted here even a little about my setup in a while. The truth is that it's not terribly surprising and I've not changed very much recently. I'm back to one laptop, and as anxious as having one laptop makes me sometimes (I fear the lack of redundancy,) not having to keep it synced makes life easier. I've put some time into doing a little bit of polish on all of little bits of configuration/code that I have that makes my computing world go around, but mostly it's pretty good.

It's nice, and I'd write more about it, but I want to get back to getting things done around here. Exporting and exploring some of this stuff in greater depth is definitely on my list, so hang in there, and if there's something you particularly want to see, be in touch.

Aeron Woes

I have an Aeron chair at my desk at home. Confession.

I got it in April when I moved to New York City. The only piece of furniture that I had that I couldn't move in my (now former) car was my desk chair. I found a good deal on an Aeron chair and I rationalized to myself that the cost of the chair was actually about the cost of movers. Savings right?

It also helped, that I was leaving a job where I had an Aeron chair in my office, and I knew that in the short term I would be working from home. While my old desk chair was (and is) quite nice, it's not quite the same. Sit in an Aeron chair for a couple of two years, and it's hard to go back. I've sat in other chairs since then, and it's never quite the same.

Having said that, after a cleaning incident today, I would like to collect a few gripes about the Aeron chair for your consideration.

  • The assembly right beneath the chair collects dust and dirt in a proportion that doesn't seem quite possible. It's clearly an artifact of the mesh, and likely a commentary on the air circulation of my apartment.

    Regardless, dusting nightmare.

  • The arms scuff and scratch on desks, if the bottom of the desk isn't completely smooth. This isn't an actual problem: the chair still works fine and is as comfortable as ever, but it's a annoying.

I've never looked at the underside of a desk before seriously. With every other chair I've either ordered a variant sans arms, or I've take then arms off as soon as possible.

The Aeron arms are low enough that they've never bothered me, so I thought "might as well." But it's still annoying.

That's all.

Constraints for Mobile Software

This post is mostly just an overview of Epistle by Matteo Villa, which is--to my mind--the best Android note taking application ever. By the time you read this I will have an Android Tablet, but it's still in transit while you read this and that's a topic that dissevers it's own post.

Epistle is a simple notes application with two features that sealed the deal:

1. It knows markdown, and by default provides a compiled rich text view of notes before providing a simple notes editing interface. While syntax highlighting would be nice, we'll take what we can get.

2. It's a nice, simple application. There's nothing clever or fancy going on. This simplicity means that the interface is clean and it just edits text.

For those on the other side there's Paragraft that seems similar. While in my heart of hearts I'm probably still holding out for the tablet equivalent [1] of emacs. In the mean time, I think developing a text editing application that provide a number of paradigmatic text editing features and advances for the touch screen would be an incredibly welcome development.

In the end there's much work to be done, and the tools are good enough to get started.

[1]I want to be clear to say equivalent and not replacement, because while I'd like to be able to use emacs and have that kind of slipstream writing experience on an embeded device, what I really want is something that is flexible and can be customized and lets me do all the work that I need to do, without hopping between programs, without breaking focus, that makes inputting and manipulating text a joy. And an application that we can trust (i.e. open source, by a reputable developer,) in a format we can trust (i.e. plain text.) Doesn't need to be emacs and doesn't need lisp, but I wouldn't complain about the lisp.