It’s Not All Bad
I’ve been working in a lot of programming languages lately. I write code in 3-5 languages a day. I try to keep the blocks I work in each language as long as possible, but even when I do a good job at separating the domains that I’m working in I’m doing a lot of context switching.
As a bonus, I’m also doing most but not all of the work on a Mac, and the remainder on a remote Windows VM.
Some of the Good
There are some good things that come with working like that. So far one of the biggest has been learning Ruby and using Rubocop as a style guide checker has taught me habits that are making my non-ruby code cleaner, such as stopping when a function gets to long or deep and seriously thinking about if I should be breaking it up into smaller chunks. The context switching helped make sure that I was still thinking that way when working in other languages and so I didn’t internalize it as a ruby-only habit.
Some of the Bad
That being said, there are a lot of costs to it. The biggest one is that I’m working in languages with very different rules and lots of tiny differences. I type nil instead of null and self instead of this (or vice versa) more often than I’d like to admit. That being said, while it makes me feel silly, it never gets into the realm of writing genuinely bad code.
One of the things that absolutely kills me is having to switch mental models of how messages to nil/null objects are handled, and how objects are passed (copy, reference, etc). The Java habit of failing if you try to execute a function from a null value means I end up writing what I feel is far too much “guard” code on the Java side because I’m parsing data that can contain null values almost everywhere. I then need to resist the urge to check if an object is null before even trying to send it a message in Objective-C. It also makes me really appreciate how optionals work in Swift, both from the standpoint of writing code, and how it makes you think about the structure of the code.
Improving it Going Forward
Working with this level of context switching has made me think a lot about how to reduce the volume of context switching I’m doing in a particular project.
The most obvious one is to write more exhaustive requirements, and once I have those requirements to built unit tests with mock data for each section. Learning how to write good unit tests is quickly climbing my list of coding skills to develop.
I’ve also considered adding more visual cues to each environment I work in, such as using “dark” schemes on Windows and “light” schemes in my Mac to make which machine I’m currently using more obvious.