On the Importance of an Open Mind in Software Development

Software developers can be a contentious lot. Just check out any of the comment threads on Hacker News if you need confirmation. We tend to see ourselves as intelligent and passionate, but far too often, we can come across as arrogant and combative. It seems like no matter what topic you pick–choice of language, testing strategies, micro services, the list goes on–there’s a holy war going on between the adherents of two or more sides.

I like to think that most Atomic developers understand that it’s a waste of energy to prop up an opinion about software like a tenet of religion, but we’ve definitely got our prejudices. Certain technologies can be dismissed pretty flippantly from time to time. I’m not saying that all platforms are of equal value. However, as developers, we do ourselves a disservice when we dismiss some technology or library out of hand. We owe it to ourselves to take time to truly understand the problem that technology is attempting to solve. We need to get into the mind of the creator, at least far enough to start to see his or her map of the world.

When in Rome

As a software consultancy, we work on multiple platforms and languages, often jumping between technologies pretty quickly. When confronted with an unfamiliar paradigm, the knee-jerk reaction is to criticize it. Instead of taking the time to properly learn the new paradigm, the temptation is to shoe-horn in patterns with which you are already familiar.

For example, when I was first leaning C#, I had spent much of the last two years working in Ruby, so I wrote C# code that looked like Ruby code. I wanted to use arbitrarily deep associative arrays everywhere (Hash in Ruby, Dictionary in C#). This works fine in Ruby, but it is far from idiomatic C# (get ready for a lot of casting).

I will gladly concede that there are probably patterns in your favorite language that are worth shoe-horning into some other language. But until you learn how that other language is meant to be used, you won’t know if you are providing a helpful tweak or going against the grain in a way that will come back to bite you later.

In jazz music, the classic axiom is that you must know what the rules are before you know when to break them. I think this principle applies to nearly everything in life, but it is especially true of writing software. Do you love React, but are forced to use Ember on an existing project? Learn how to be productive in Ember before trying to get the team to jump ship to React. Prefer top-down TDD, but your new project lead wants to do bottom-up? Give it a try for a few weeks before insisting that your way is better.

Before you decide that system tests take too long and are prone to be flaky, consider the kind of confidence in your code that only an all-encompassing test can provide. Is it truly in the best interest of the project to forego that type of coverage for a faster test run? It might be, but it isn’t a question you can answer without serious consideration.

Maybe you shy away from working in Visual Studio because it is slow and bloated. Try refactoring some C# code in Vim (without OmniSharp) before you decide that your editor doesn’t need any compiler-aware features.

And in general, if you had a bad experience with some technology years ago, learn about current best practices instead of reciting your old horror stories.

It’s All About Growth

Some of the occasions when I’ve grown most as a developer happened when I let go of my existing prejudices, throwing myself into whatever new technology was in front of me with an open mind. For me, this was especially true for testing, functional programing, and JavaScript frameworks. When I first came to Atomic, I was skeptical about testing in general and TDD in specific. The value proposition was not clear to me from the outside, and it was only after I spent enough time writing tests that the lightbulb turned on and I realized, “Oh! This is how I’ll make sure I can refactor code without breaking anything!” (Among many other good reasons for writing tests.)

With the “why” in hand, it is a lot easier to see when it is appropriate to deviate from the pattern. For example, you might realize that isolated unit tests are really valuable in general, but for Ember components, any logic not abstracted into a service is usually tightly coupled with the DOM. So, cover the logic in the components with integration tests that include the DOM.

I don’t believe in silver bullets. No one technique or technology is right in all circumstances. As software generalists, I think our responsibility is to understand the tools in our arsenal well enough so that we don’t try to fire a shotgun like a sniper rifle. Also, I recommend giving the original maker of the tool the benefit of the doubt–he or she probably had a good reason for most of the choices that were made. Most of the time.