Doomed Emacs

After a year or so of dedicating myself to getting Spacemacs setup just right, I made a pretty substanial jump a few weeks ago. I’m now running doom-emacs which provides fewer nice surprises (missing evil-surround shortcuts by default) than spacemacs, but loads much … much faster. The other day I found myself coding while sharing my screen on Zoom and is was painfully obvious what price I was paying for spacemacs not cleaning up after itself and generally lazy loading things leading to less than fast context switching.

I was willing to struggle through some the slower operations for my own sake, but getting caught with other people watching as my editor on a brand new computer struggled to do basic things like searching for symbols in the codebase was embarrassing.

I’m not done with Spacemacs. I still love the idea, and I also believe that half the problem was likely the way I was using it and configuring it. But part of the appeal of spacemacs are the defaults. And it was the defaults that was making it hard to use it on a daily basis.

Another nice aspect of Doom Emacs is that aside from a handful of evil-mode shortcuts, a lot of what you’re encouraged to use are stock emacs keystrokes. That means that I’m not learning some cryptic layer on org mode when I use emacs, I using the default keystrokes that I will find in vanilla emacs. That’s very useful and will hopefully make me a more respectable member of the emacs community, rather than a vim outcast.

Continuous Tool Improvement

I was reviewing the feeds I subscribe to in elfeed this evening when it occurred to me that a lot of my feeds have to do with Emacs. I will often blow through updates on feeds, making sure to only pickup things that are truly useful. But I discovered an amazingly high signal to noise ratio regarding tips for using Emacs more effectively. This got me thinking about how I couldn’t possible remember all this stuff, so I tossed some of the things I was learning in my file to review later. At that point, it dawned on my how important tool choice is, and how important it is to learn how to use your tools effectively and be receptive to learning new things about them.

This could apply equally to any well made tool for any discipline (woodworking, drawing, research), but for me that means Emacs. Not everyone is going to ever need to touch Emacs. For me, I can’t imagine not having it, and everytime I learn something new, I get a little more effective with it.

For reference, tonight I learned how to make all URLs, regardless of buffer, clickable. I also learned how to break an org-mode block in two with a single keystroke to insert a comment.

Reading Lists

Oh Goodreads. Your website is a cluttered mess. Your UX hasn’t been improved in years. The only value I derive from keeping my reading list on you is that my friends can see what I’m reading. Which is a neat trick, but since I’ve mostly given up on Facebook too, it not really enough to keep me.

I was an early adopter of Goodreads, but my life has taken a turn towards the personal and the text-based. I use Emacs (via spacemacs) as much as I can. Org-mode might be the single most impressive IDEA rendered into software I’ve ever seen. It simply makes the things I use on a regular basis more powerful and expressive, which is not something I can say for Word, Twitter, or Chrome. Those are merely tools. They don’t amplify my ability to document and create.

Really the post Leaving Goodreads is what convinced me to go, one more time, back to my reading list in org mode. But the killer feature this time around was ox-hugo, which allows me to easily dump Org-mode subtrees into a hugo-powered blog directory. A simple rsync later and I can publish random subtrees, including book reviews!

The whole thing is so elegant, I couldn’t have dreamed up the process if I had tried. The whole thing was truly an evolution of tools, and one that was only possible because each tool, Emacs, spacemacs, org-mode, hugo, ox-hugo, does it’s job so elegantly.

Hacking Healthcare

Table of Contents


I wouldn’t recommend this for beach reading, but that’s hardly the point. Hacking Healthcare provides a really concise, if slightly outdated look at what it means to work in IT with health data. Unfortunately, I’ve come away pretty underwhelmed at the impact that open source software has had in healthcare. While many industries seem to be going full bore into software built by collaboration, with support provided by for-pay companies, healthcare still seems dominated by proprietary software. What this book shows, is largely why that is so.

Between ontologies (specific words coded for reference), HIPPA-compliance, and the general un-sexiness of health care data, it is amazing anyone at all spends their time trying to make doctor’s lives easier. And even more challenging, a high percentage of docs are well-educated and just technical enough to think they know the best way to solve a problem. That leads to very inflexible ways of thinking, for better or worse.

There’s also the reality that paper really does work very well for healthcare. Before you replace something, you have to understand the value of it, and the value of a patient chart is huge. Doctors and nurses have shorthand; they can scribble in text when checkboxes don’t provide the context they need; they can write down three different possible ways to diagnosis someone and come back later to review their notes, to ensure codes in bills match patient conditions. It should come as no surprise then, that computer-aided solutions often fall flat.

Recently I spent an afternoon in the ER. The RN on duty was quietly cursing under her breath as she struggled with an electronic health record input that required her to code everything. Going back to ontologies, that means that when she used rubbing alcohol to clean off my scrapes, that required her to lookup and specify ICD10 diagnosis code S40.212A, “Abrasion of left shoulder, initial encounter.” What the fuck? No wonder she was frustrated. Nevermind if it turned out to be my right shoulder but she was tired from being on the end of a ten hour shift.

And of course, this doesn’t even get into the politics of ontology. The AMA maintains it’s own list of DX codes, but they charge money for access to them. Meanwhile, there’s also LOINC, a free standard, but which is not accepted by all insurers. And of course, Medicare and Medicaid have their own standard which maps, roughly, to ICD10 and LOINC. BUt don’t forget Snowmed … sigh.

And that’s just ontologies. There’s also the simple matter of what IS a patient chart? Is it just the patient? What happens when a patient changes their name? Should we assign an ID to the patient? But how do we track the ID across the various systems they might travel through when they are referred?

What about billing? Oh my. Let’s not even start with that.

Suffice it to say, reading this book was mostly humbling. I will likely return to it as a reference in the future, as I mostly skim read it this time. But it is a fantastic overview of the state of healthcare IT from 2015.


The VistA effect, as explained in Longman’s book about the VA, is where the quality healthcare outcomes are continuously measured to enforce higher levels of patient safety and care.

This hinges on “meaningful use” measurements, which include:

  • Demographics
  • medication lists
  • problem lists
  • vital signs

These are trivial for a clinician to understand, but very difficult to model in software.

Given how difficult some of these problems are to reason about (is Fred Trotter and Frederick Trotter the same person?), are there opportunities, as a forward thinking healthcare problem solver to open source certain tools that make expunging HIPPA data easier? Or perhaps to rectify demographic information? Can we, while still making money and not tipping our hand too much, help those who are technical to advance the state of the art in healthcare IT?

Another Engine

Once, I used Jekyll. Then I switched to Pelican. I’m finally here on Hugo, and hoping that this will make it easier to keep things updated. The eternal question when chosing a method to publish a blog is, why publish a blog. I don’t really have an answer for that yet. I wish I did. Honestly, I do. You don’t have to believe me, because I believe in myself, and if this is all one big simulation, you don’t matter anyway.

Incidentally, perhaps the best part of this transition is the ox-hugo plugin, which makes writing new posts and publishing them a dream. Now, instead of some complicated cocktail of adding a new file with the write filename and proper metadata, I can just org-mode capture the thing. The more I use emacs (and specifically spacemacs), the more in love I am.