My Development Setup

• 5 min read
• August 27, 2020

Changing up your editor, theme, and plugins will not transform you into a 10x Engineer (because nothing will). But maybe you'll find something new or exciting in my setup, and perhaps that will spark joy.

Code Editor

I switched from Web Storm to Visual Studio Code in 2017, and I haven't looked back since. VSCode is free, has an impressive feature-set, and a truly massive number of extensions. It is the extensions that set VSCode apart from Web Storm and most other free editors. I'd be remiss if I didn't mention Emacs and Vim. Both have an equally (if not more) impressive library of extensions. To me, VSCode strikes a more comfortable balance between approachability and functionality.

Theme

A good theme is more than just pretty colors; it helps me focus on my code. Monokai Pro is my theme of choice. I think the color choices are spot-on. The icons are suitable (if a little limited). And the syntax highlighting is excellent. The package comes with six themes I use "pro". The theme also has a Sublime Text style forever-evaluation period if you don't feel like spending €9,95.

Typeface

I don't think my choice of typeface is going to transform unreadable code into something readable. Still, I have found font choice to make reading a bit less strenuous and helps code-intent stand out more readily.

My first typeface choice is Fira Code; it is a derivative of Mozilla's excellent Fira Mono, designed to make decoding code symbols easier. Code contains a lot of symbols, often comprised of several individual characters. Fira Code makes decoding easier by combing the multiple characters of a symbol into a single, easy-to-read character.

Fira Code contains other optimizations, but symbols are where its strength lies. For everywhere else, I use Operator Mono. Upfront, Operator is expensive, like really expensive. I'm not going to convince you that the price is worth it, especially with so many alternatives, and after partly dismissing Web Storm, for its cost.

Anyway, the folks at Hoefler & Co. did an excellent job designing Operator. It stands out for two reasons. It is incredibly easy on the eyes and has a cursive italic variant, which is exceedingly rare for a mono-spaced font. The italics are distinctive enough to help me pick up on pieces of the code when I'm looking for them but are never distracting when I'm not looking for them.

Hopefully, you now understand why FiraCode and Operator Mono are both excellent typefaces. But you're probably wondering, how am I using both of them? Thankfully there's a GitHub repo for that. @Kiliman's Operator Mono Lig automates generating a new font that inserts FiraCode's ligatures into Operator, creating a new font-family: Operator Mono Lig. Finally, I've got some custom configurations in VScode's settings.json file to utilize the Operator's italics and FiraCode's ligatures in a way that I like.

"editor.fontFamily": "OperatorMonoLig-Book",
"editor.fontLigatures": true,
"editor.tokenColorCustomizations": {
  "textMateRules": [
    {
      "name": "Italic",
      "scope": [
        "comment",
        "entity.name.type.class",
        "keyword",
        "constant",
        "storage.modifier",
        "storage.type.class.js",
        "markup.quote",
        "keyword.operator.expression.import.js",
      ],
      "settings": {
      	"fontStyle": "italic"
      }
    },
    {
      "name": "Bold-Italic",
      "scope": [
          "markup.bold markup.italic",
          "markup.italic markup.bold",
          "markup.quote markup.bold",
          "markup.bold markup.italic string",
          "markup.italic markup.bold string",
          "markup.quote markup.bold string"
      ],
      "settings": {
        "fontStyle": "bold",
      }
    },
    {
      "name": "Not Italic",
      "scope": [
        "invalid",
        "keyword.operator",
        "constant.numeric.css",
        "keyword.other.unit.px.css",
        "constant.numeric.decimal.js",
        "constant.numeric.json",
        "support.function",
        "support.type.primitive.js",
        "support.type.builtin.js",
      ],
      "settings": {
        "fontStyle": ""
      }
    }
  ]
}

A Bit More Scannable

A good theme and typeface go a long way toward making code easier to read and understand. There are a few additional extensions I add that help make everything a bit more scannable. Bracket Pair Colorizer 2 does pretty much exactly what it says on the tin; it colors bracket pairs to be easier to pick out. I've got it configured to display the current bracket pair in the gutter, which helps to make the beginning or end of the current scope more obvious.

I prefer a more compact two-space code indentation to four spaces. Indent Rainbow allows me to quickly identify which code indentations belong together without having to resort to using four-space indentation. It highlights indentation mistakes too, which is a handy bonus when detangling complex code.

My settings for both of these are below. I have them configured using the same color-scheme as Monokai Pro. If you're using a different theme, you may want to switch up the colors a bit. Note: Bracket Pair Colorizer doesn't seem to support RGB/RGBA colors, so stick to hex colors.

"bracket-pair-colorizer-2.colors": [
  "#939293",
  "#C0506C",
  "#BD7755",
  "#C0A354",
  "#83A660",
  "#4A97BF",
  "#857AB6"
],
"bracket-pair-colorizer-2.colorMode": "Independent",
"bracket-pair-colorizer-2.showBracketsInGutter": true,
"indentRainbow.errorColor": "rgba(255,97,136,0.4)",
"indentRainbow.colors": [
  "rgba(255,97,136,0.05)",
  "rgba(252,152,103,0.05)",
  "rgba(255,216,102,0.05)",
  "rgba(169,220,118,0.05)",
  "rgba(87,199,254,0.05)",
  "rgba(171,157,242,0.05)"
],

Know Why A Bit Faster

Working with a team on a more massive codebase makes it impossible to keep updated with all of the changes. Even personal projects, after a few months, can become completely foreign. I find Git Lens helps tremendously in understanding the context of a change. Specifically, there are two features of Git Lens that I love.

Inline notations appear on an active line. They describe who last altered the line, when the change was made, and the commit message. When I'm familiar with a file, this is usually enough to jump-start my memory.

For all the other times, when the notation information isn't enough, that's where the Git Lens tool-tip is useful. The tool-tip has the same information as the notation but adds the exact date, a diff of that line, and allows you to step into a full-file diff easily.

VS Code has an excellent version control integration. Both of these Git Lens features are dead-simple, immensely useful, and round out the built-in features. I'd love to see a first-party implementation at some point down the road.

As an aside, if you're using GitHub, the GitHub Pull Requests and Issues extension is a great way to handle the most common GitHub interactions directly within VS Code.

So, yeah, that's my setup. With any luck, you found something here that you liked. I'd love to see what you're using; reach out and let me know!