My Workflow, 2016

Late last year, I posted about my transition to working on a remote machine. As a part of that transition, I picked up Vim as my primary editor, so that I could do more in my terminal than before. My workflow has evolved a lot in the past year, so I'd like to put it out there so others may find useful tidbits.

Source control: Git

I don't feel like I need to talk extensively about this. I use Git for my source control. I think back to when I didn't have any kind of source control and I don't totally know how I managed. If you're not familiar with Git, please take a few minutes and try it. Instead of going on about why I enjoy using git, I will talk about how I use git.

1. Keep master golden

Master should be a working copy of the codebase. If I pull master, I should be able to install dependencies and start up the application with no issues, so long as my platform is supported. If I'm working in Node, I want to see npm install && npm start bring up the application. If not that, then as few steps as possible to go from 0 to development as quickly as possible.

2. Branch for small features

Break a branch off of master, do a small chunk of work. I try to avoid having too many branches open at any given moment, and I try to ensure that they stay up-to-date with frequent rebases from master if master has changed. If a branch is tied to a pull request on Github, I try to avoid rebasing, and opt to merge, unless a rebase absolutely makes sense. Rebasing will destroy the public history of the branch, and it can be a burden on others to figure out what happened in a comment thread.

3. Continuous Integration

or CI, this is key. It makes managing a project so much easier. If you are working in open source, read up on Travis CI if you aren't familiar. If you have never heard of CI before, the basic idea is that when a commit is pushed or a pull request is opened or master changes, automatically run your build and tests (or any other script) and report the results.

Another great CI tool is Circle CI, which will actually do one private Github repository for free.

Editor: Vim/NeoVim

I talked about picking up Vim to allow my development environment to be more portable. Well, I ended up falling in love with the editor. For years I swore by Sublime Text, spreading the good word of how great this editor was. I was afraid to lose some of the powerful features when switching to Vim, but oh boy, turns out it was the other way around. Now I feel out of place in anything but Vim, and I wonder why I can't just do a quick google and clone a repo to suddenly have more badass functionality.

Neovim is something I started using just a month or so ago. Its Vim, but refactored for maintainability. I don't really intend to hack on Vim, but I do like that it has much more sensible defaults, like allowing mouse interaction in my terminal (as little as I use it), and having things like native clipboard support enabled by default. Its a solid choice, but not without its faults. Neovim struggles a bit when being extended by python, one of the biggest problems being that it doesn't play nicely with Powerline, a nice toolbar ui for Vim. That said, I quickly found Airline, which is a native VimL replacement, and works beautifully. If anything, Neovim has made me realize that we should be trying to do everything we can in just VimL to maximize portability.

Vim has a high learning curve, and I wouldn't actually suggest it to someone casually. You need to dedicate time to learning it, and you need to know that you will lose productivity for a little while while learning it, but you will end up far more efficient on the other side, I promise you.

Window Setup

I mentioned that I use Vim in a terminal in the section above. I much prefer using the terminal Vim rather than Gvim or vim.app because I really like a consolidated, clean window setup. The less windows, the better. These days, at work I have an iTerm instance running tmux, and a Chrome window, and that is it, save for the occasional opening of an email client. In tmux, I keep three windows. Window 1 is for neovim, 2 is for git, and 3 is split into a few panes to run applications or servers. I keep that on Desktop #1, and on Desktop #2 I keep chrome. On my work MacBook, this means I am one hand-swipe away from my editor or the browser.

I tend to not use external monitors at work since we have laptops and tend to be up-and-about. At home, my setup is a bit different. My home laptop is a Surface Book, which is a gorgeous laptop / tablet hybrid. Yes, it is by Microsoft and runs Windows 10, but I am pleasantly surprised by the quality of Windows 10, and I run a lot of windows only programs, not to mention gaming and game development, which Windows lends itself to greatly.

On my Windows laptop, I do use Gvim, using the same .vimrc as I do at work. I actually keep all of my config files in a Git repository to keep them sync'd across devices. Along with Gvim, I use cmder, which helps to make the Windows Command Prompt bearable. It adds a lot of aliases for bash commands (ls, for example).

Stack

I'll end with my stack information and links to what I tend to use. I love JavaScript. All of my work in the past few years has been in JavaScript. Since Node came along, I haven't needed any other language, since I can use it in both the back and front ends. Now with Node 4+ and Babel, ES6 is easier to access than ever, making JS even more enjoyable.

My typical stack looks something like this:

Back End

Pretty bare-bones. I have been tinkering with Sails (and Trails) but I wouldn't list them as a part of my go-to stack just yet.

Front End

React dominates here right now, in my opinion. If you are unfamiliar, and are a front end developer, or if you have heard of it but not sure about it, please please please give it a try. I use it in tandem with Reflux.js, which is a reimagining of Facebook's Flux architecture. I find it to be simple and easy to approach. Redux has become the general popular choice now, and while I believe it has its merit, it certainly is harder for newcomers. Any package that requires a 30-video introduction (as it boasts) is not a great way to steer someone for an intro-to-React app. That said, I can imagine it will be replacing Reflux for me soon enough.