my current workflows

The accusation has been leveled at me: “for Akira, the tool is the job”. I care deeply about the tools I use (perhaps this is part of why I ended up in theory after always thinking I’d be an experimentalist and trying hard to become one). As such, I usually think a lot about the tools I choose to use. Often this decision boils down to (in no particular order):

• Is it free software
• How detrimental might a bug be to me
  • How rewarding or miserable of an experience might it be for me to try to fix the inevitable bug that bothers me enough to want it fixed
  • How easy or hard might it be for me to try to fix such bugs (e.g. what language is the software written in)
• How “user friendly is it” (yes this will always be in the eye of the beholder)
  • How flexible is it from a user standpoint (e.g. how is it configured and can I keep that under version control)
• How actively is it currently developed
  • How active is the community (say, those who do not have commit access)
  • What kind of ethos does community seem to have and how pleasant or unpleasant might my interactions be with them (I acknowledge that I will always be half of this equation, and it is important to acknowledge that)
  • Do I think it will still be developed in 5, 10, or 20 years

I think it’s good to be pragmatic about one’s ideals which is why I don’t try to say any of these should ever a priori outweigh another.

So, while the decisions that lead to my workflows are inherently complex and subjective, I think its worth attempting to describe them so that I can remember my own thought processes, and see how they evolve. Perhaps someone may someday also find them helpful to whatever journey they are on with the tools they use.

Also see What I want is hackable software, not free software.

Unfortunately, I still need to document what how I’m currently using emacs and org roam, but for now, see migrating this website to org-roam and presentation software for some more recent thoughts.

Since I’ve had various models of MacBook Air over my life, I’ve found that carrying a lightweight laptop around is always a better mobile solution than trying to figure out how to sync notes/config between devices (and believe me, I’ve tried!). One should always strive for reproducibility (what if your system fails!). However, I think people underestimate the amount of active state they work with across their apps. They also underestimate the cognitive overhead of having to be the one to sync state. Syncthing or anything that tries to sync at the speed of interaction with the system is probably the best approach, but even then it can leave synced stuff in corrupted states depending on the app and data one is trying to sync.

I use org-mode’s support for Literate Programming to my various dotfiles contained in org files tangles the code blocks into the correct destinations. This lets me easily keep everything in git and makes it easier to document things.

Adding the following to the top of the file will then tangle on save:

# -*- eval: (add-hook 'after-save-hook 'org-babel-tangle nil t); -*-

• presentation software
• my current stack and how it’s configured