My setup for remote programming on OSX in 2019

Published:

Hi! My name is Andrew, and I work remotely as a software developer. I’ve worked while traveling across America with spotty or no internet connection. I’ve worked in countries like South Korea and Japan. I like traveling, and this is how I stay productive.

Working remotely at WeWork in Gangnam Seoul
Working remotely at WeWork in 강남

1. Development Machine

Before we begin, why apple and osx?

  1. battery life

  2. battery life

  3. weight

  4. unix-like environment

and to an extent, some proprietary or osx-only apps: photoshop, premiere, affinity designer, and sketch.

Before you scoff, I used freebsd and arch on my home pc as daily drivers. I used a modded thinkpad t430 for a few months as well. [0] I put in an i7-3632QM (quadcore) chip, a quieter heatsink, 2x8gb memory, a t420 old-style keyboard, and a 9 cell battery.

It was sweet… before I started lugging it around.

Weight-wise it was slightly heavier than my 15" macbook (~4.5lbs?), and the battery life made it unusable. I was getting 4-5 hours, max, and occasionally it would just die earlier than expected. (Forcing me to go reset the system time in BIOS).

I was always worried about my power source. I have lived out of two backpacks and worked remotely while traveling, so I can’t rely on always being next to an outlet. My 2015 13" macbook pro’s battery is still good to the point that I can get 6-7 hours out of it while working with Rust/C#. It’s more like 8-9 if I’m only doing light writing, etc.

I know someone’s going to respond with "but oh, you should’ve just used power with x, y, z configurations!". I _did_ experiment with different settings with power and other alternative tools–nothing seemed to help. Call me a grumpy old man but I want to work and get things done… not fiddle about with battery tuning settings and the like.

Eventually I’ll need to replace this mac. All post-2015 macbooks have been undesirable to me so I’ll probably go with a dell xps 13", or maybe a System76 Galago. I just want a durable machine with an excellent battery that’ll work years later and won’t have me configuring things constantly. Is that too much to ask?

At home I do have an x201 and x220 thinkpad however. They’re great for testing different operating systems, etc. I just don’t like traveling with them. The x201 is quite small so hopefully it’ll become my main writing machine.

2. Configuring OSX & Tools

The first thing I always do is install xcode-tools, iTerm2, brew, and zsh. Then I clone the osx branch of my dotfiles repo and symlink the files where they need to be. I should automate this part with a script, but making that script would take me far more more time than just doing it manually. Not worth it, for now at least.

You can use brew leaves to see installed items and brew cask list for cask items. I stored mine when I originally started abstracting out my dotfiles.

2.1. poor man’s window tiling

After using i3 I can’t go back to non-tiling window managers. I long for the day that i3 works natively on osx. Sigh.

I’ve somewhat replicated it with chunkwm, skhd, and karabiner. Chunkwm is a tiling window manager, but it doesn’t handle keyboard input. That’s where skhd comes in. I copy/pasted to my khdrc but to be honest I don’t use most of these hotkeys still.

Then, I use karabiner to make my right command key into a hyper key– it presses shift, command, control, and option.

2.1.1. cons

Some applications have minimum window sizes. So if I have too many windows in one workspace, they will just overlap. Spotify and KakaoTalk are example offenders.

2.2. poor man’s workspaces

I use 10 Spaces. I added shortcuts to quickly focus them: hyper + 1-5, w-y.

I disable "Automatically rearrange Spaces based on most recent use", in Settings → Mission Control. This has got to be one of the worst defaults ever made.

My workspaces generally follow this order:

  1. terminal (currently iterm2)

  2. browser (firefox)

  3. misc / Rider / Safari

  4. misc

  5. misc

  6. [w] misc / desktop / vlc / signal

  7. [e] misc / discord

  8. [r] kakaotalk, messages app

  9. [t] anki

  10. [y] thunderbird

Something about the Catalina update broke hyper + q.

2.3. apps

I almost always have iterm2, firefox, kakaotalk, anki, and thunderbird running.

Misc tools I generally use:

  • DB Browser for SQLite

  • Insomnia (REST api testing)

  • Azure Data Studio (ms-sql querying)

  • Datagrip (reading stored procedures / db schemas)

Task bar apps:

  • Harvest (time tracking)

  • Duet (to use my ipad as an extra display)

  • Caffeine (prevent my computer from sleeping)

And non programming-related ones:

  • Discord (messaging, language study, rss)

  • KakaoTalk (messaging)

  • Line (messaging)

  • Signal (messaging)

  • Anki (flash card study)

2.4. code editor

For non-C# code, I use neovim, vim, or vi, in that order. I don’t really care what you use. I like (neo)vim, so I use that. I just become disappointed when people reflexively dismiss it (or Emacs) because they have any learning curve, like at all. There’s a reason why vim has one, and it’s not because Bram Moolenaar is particularly masochistic. In particular, modal editing and buffers [1] are why I enjoy vim.

Even if you don’t use vim, I urge you to read the manuals of the software that you do use. Small tidbits of knowledge add up over time, especially with common repetitive actions.

It’s also good to know a little vi when you mess up your FreeBSD installation and have to dip into an emergency shell. Will nano be accessible then?

Modern Vim by Drew Neil is a fantastic read. I read parts of it here and there to glean ways I can improve my vim usage. Every vim user should read Oil and vinegar - split windows and the project drawer from vimcasts.

You can see my neovim configuration here here, although I need to prune it a bit. The biggest changes I’ve made are:

  • mapping jj to escape from insert mode, or otherwise using ctrl-[ otherwise to avoid repetitive strain from hitting escape

  • using fzf
    fzf.vim to fuzzy search through my files.

  • using ale to asynchronously lint and fix files (but only on file save. I hate over-eager tools that complain when I’m halfway through writing code)

  • using plug to manage plugins and lazily-load them

  • disabling vim’s annoying swapfile system.

Oh, and gruvbox, possibly one of the best color schemes ever made. Every once in a while I experiment with a different scheme but I inevitably get drawn back to the king. If someone made Nord but with green as the main color instead of blue, I might use that.

2.4.1. cons

Vim’s autocompletion… exists I guess. A while ago I looked into it but it seemed not worth the hassle to set up. Anyway, ctrl-p in insert mode brings up suggestions from open buffers. Good thing p is right next to [, which takes you out of insert mode. /s

As an aside, did you know that vim displays Type :quit<Enter> to exit Vim if you hit ctrl-c, and that it’s done so for a long time? Is your joke very outdated and unoriginal? Yes, yes it is.

2.5. code editor (for C#)

I use IntelliJ Rider on both osx and arch. I think the value is worth it. It’s definitely nowhere near as snappy as vim but doing C# without autocompletions would eb… rough. The build profiles and test runners are pretty nice. Modifying environment variables and profile configurations is tedious.

The Intellij plugin ecosystem is great- you can easily install plugins in any of their editors, to my knowledge. There’s even an official rust plugin.

However, cmd-4 is the shortcut to close tabs..?! The default controls are interesting, to put it one way.

3. Workflow

3.1. tasks

Everything starts and ends with meetings and slack. I work on different projects for clients and my team has a daily 5-30min call at 9am (10pm in Korea).

In Slack and our meetings we’ll discuss what needs to be done. I or others will make bullet points of the most pertinent stuff that needs to be done. No agile or anything, thank god. We previously used a few different ticket tracking systems and I’ve found that they all suck. YouTrack sucks, but it was better than the proprietary abomination one of our clients made us use. The only good system I’ve found is:

  1. make a list (or queue, if you prefer it that way) of things

  2. roughly ballpark estimates, with the understanding that estimating things is notoriously difficult

  3. accurately prioritize those things (if everything is #1/urgent, nothing is)

  4. work on those things

  5. discuss progress and blockers in daily call and/or slack

  6. repeat

That’s it.

On top of this, issues in github/gitlab/etc are also pretty good if you come up with good labels. Right now I’m experimenting with Github’s Projects and semi-automated issues on our newest project.

Being 13 hours ahead does pose issues occasionally, but I solved this by going to sleep a bit later (about 1am or so). Having different things to work on is also important– if I’m ever blocked on something, such as waiting for a teammate to wake up and answer a question, I can just work on something else in the meantime. This async style of work won’t work if you always need rapid communication with your team.

3.2. logging my thoughts

The Notational Velocity application massively improved the quality of my life. At its core, the idea is deceivingly simple.

NOTIONAL VELOCITY is an application that stores and retrieves notes.

It is an attempt to loosen the mental blockages to recording information and to scrape away the tartar of convention that handicaps its retrieval.

You store text in notes. There is only one search box–if a file doesn’t exist for your search string, one will automatically be created.

— National Velocity

I began to use it for just about everything, since any and all information I had written down could now be easily searched through and found.

  • seldom-used vim tidbits

  • miscellaneous knowledge about real languages (I study Korean)

  • random snippets for programming languages (how do I open a file in ruby again?)

  • tentative to-do lists

  • niche, detailed information like serial numbers and specs for equipment that I bought

It was glorious. Except… it was, and still is, mac only. At home I use *nix systems or windows, so using it became tedious and I eventually stopped.

As I was writing this article, I discovered nVALT–Brett Terpstra’s fork. It has more functionality like markdown support and a better interface. No vim keybindings though, which made it unpleasant for me to use. Terpstra is working on nvUltra currently which may fix this.

A gif showcasing how notational fzf vim works.

After I started writing this article, Alex Singh released notational-fzf-vim, which is basically notational velocity but in vim! As the name implies, fulltext searching is powered by fzf, which in turn uses ripgrep by default. Both are excellent tools I use daily.

The preview window is amazing..!

In order to use it, you need to specify at least one directory for the plugin to search. This will be the primary directory where new notes will be saved, but you can search multiple directories.

" notational fzf vim
let g:nv_search_paths =
  \ ['~/Desktop/Sync/thoughts',
    \ '~/Desktop/Sync/thoughts/korean',
  \]

and some example files that I’ve written to this week:

packing-list.md
self-publishing.md
useful-shell-scripts.md
vim.md
watches.md
youtube-videos.md
korean/colloquial-or-slang.md
korean/color-names.md
korean/clothes-verbs.md

4. Conclusion

This is my personal setup. I find it fascinaing to look at other people’s workflows and see how they handle things. Usually I can take away a thing or two and improve my own workflow. Feel free to make suggestions.

References

1956 words — under programming, workflow