Why homogenous dev setups aren’t the best idea

I wanted to write a quick blog post on why it’s important for developers on a team to use different setups to develop. Why it’s important to have Linux and windows users in a field (web dev specifically) that’s been dominated by macOS. And why it’s important to stay away from Chrome-only development.

I think the answer is almost obvious at first: diversity in development means you catch more cross-browser/cross-platform bugs. So why doesn’t every team have “quotas” or at least a thorough QA step every step of the way?

The situation right now

I’ve worked on a handful of development teams and on applications that ranged from having half a dozen users to websites that serve millions. Almost every team I’ve been on has an almost identical setup for development:

1. latest OSX machine
2. latest Chrome browser
3. iTerm2 with bash/zsh (fish is great, why isn’t anyone using fish?)
4. Sublime Text or VSCode

I’ve always been driven to setup my development environment differently than everyone else. I’ve always had plenty of personal reasons to do so (eg. macOS interface is just not pleasing to me, Windows ftw) but the end result was always the same, I stuck out like a sore thumb with:

1. latest Windows machine or maybe ArchOS
2. random browser I use on rotation (will it be Opera? or Firefox? or Chrome? who knows?)
3. ConEmu or TMUX with Bash or PowerShell, or CMD
4. VSCode, Emacs, VIM, or Sublime Text

It’s definitely been annoying our ops guy because tools don’t always behave the same way on different platforms.

What my dev setup taught me

Over three years ago, I started working at a company called Landdox. We have an app that does document/land management for Oil & Gas companies. We have a few “famous” “hard” problems we dealt with when we first started building the app:

1. original color scheme looked great on Macs — it was illegible/unusable on every single other machine.
2. a “plus” sign on a button was always misaligned — it looked centered in Chrome on a Mac but not on Firefox or Chrome on a Windows machine. I spent a week debugging this and considering using images…
3. form fields were cut off on IE Edge so you couldn’t see the text you typed, or the option you selected on a select field.

We were a small company but already the fact that I had a Windows machine meant that I was able to debug and fix these and more importantly, notice these problems as they arose.

Tooling and new developers

Tooling issues suck. It sucks when Docker runs perfectly on a Mac machine but fails on Linux or when it fails on Windows. But fixing problems cross-platform meant that when we onboarded new developers that had their own productive setup, we didn’t have to force them to work on machines, OSes, and editors that they weren’t comfortable with.

This meant that I, as a Windows developer on the team, paved way for at least one other developer we onboarded who used Windows almost exclusively. He also switches to work on a Linux machine but that’s ok, we have Linux devs that paved way for that setup as well.

I just want to mention that when I had to work on a Mac setup years ago, it took a good deal of time to get used to it. Normal apps I depended on (like Np++) didn’t exist and had very poor replacement (TextMate? Really?). I wasn’t a fan of the UI either. I didn’t detest being a mac user and eventually got proficient with it.

I embraced the change of pace but if I was interviewing with a company right now and they demanded I use a Mac, I’d most likely turn them down. In fact, I’ve done that early on in my career pretty often.

Browser testing while developing

We occasionally get tickets due to performance issues in our application. We’re running an AngularJS/Angular hybrid and if you’re ever done that on a production application handling tons of data, you’ll know that there are strange performance hiccups when the two frameworks conflict (“thrashing” is what I’d describe it as).

This thrashing is pretty easy to spot and generally appears cross-browser; however, there are sneakier performance bottlenecks that do not. And we found one that occurs only on IE Edge, and somehow, only on my machine (other Windows-using devs haven’t been able to recreate it).

Before I get to where this lead me, let me expand on the idea of using your dev environment as testing grounds.

Not every team has QA and fickle bugs that exist only in certain conditions are difficult to test for or find using regular QA techniques. We employ e2e tests but those run on Cypress which means they run in a Chrome-like environment.

I’ve been using Firefox as my primary browser. It’s a really fucking awesome browser and the dev tools are AMAZING — definitely not “secondary” to Chrome as developers like to say.

With Firefox, I’ve identified numerous bugs and annoyances during my regular development. I had to download a report that was built inside the browser (yep, you can build an excel spreadsheet in your browser without hitting the server!) but the way the name of the file was constructed resulted in an invalid file in Firefox.

I’ve also noticed a weird bug with form fields and a few others where entire sections of the site would disappear.

Onto IE Edge

So back to that performance problem. I decided to move to IE Edge as my browser of choice so I could watch out for these things. Our customer base uses Edge to a certain degree so that means that I’ll see these bugs before they do.

So far, Edge has revealed quite a few things to me:

$scope.$watch

Let’s see how this goes!

Please share your setup! I’d love to hear about it

The post Why homogenous dev setups aren’t the best idea appeared first on AntJanus.