You Are Not In A Relationship With Your Tools

Note: I haven’t forgotten or abandoned the Committed series.

Yesterday, I was beginning to prepare an internal talk, and I referred to some old materials I used when doing similar talks for previous teams. These talks go back years, and the concepts in them go back even further. Still, I see a lot of resistance to one of the ideas in particular.

tl;dr - Languages, platforms, libs, frameworks, and tools are not looking for a monogamous relationship. You don’t need to marry one and use it exclusively, nor do you need to leave one to experiment with another. The more the merrier. If you really must crush on your tools, at least be polyamorous.

Rewind: The Technology Council⌗

I cannot make this up. I was once in a position where the grand plan was to create a sub-team of four(ish?) engineers called The Technology Council. To be fair, I can’t remember if that was the official name, or just what those of us in the trenches started calling it.

These engineers would no longer touch production code. Their responsibility would be to create an allow list of libraries and frameworks that the other developers would be permitted to reference. Removed from the actual problems, they’d be able to see more clearly which tools would solve them. Of course, it goes without saying that once a single tool was chosen for Problem X, it would suit Problems Y and Z just fine.

Revolt⌗

I expressed my displeasure with this idea. How could developers stay up to date or experiment with new approaches if they had to wait months for council approval? Then, when I eventually resigned, I was told I could be on the council if I’d stay. Apparently there was some confusion, and it was believed that I just wanted to be one of the deciders.

Before I left, I gave my team an internal talk called (prepare to facepalm) “Enterprise Agility - Surviving the Waterfall and Staying Sane³ to Boot.” Despite the title, I still stand behind most of the ideas in that talk, especially since they were heavily inspired by a (much better) talk I had just seen at CodeStock¹.

One of the slides in my talk was titled “A Word About Golden Hammers.” Here’s one of the quotes I had in my notes.

What I am against is the thought that there is one solution to all problems, or that all problems can be solved by one solution. Every problem is different. The key, and the most important thing of all, is to understand not only what you’re using (framework, libraries, etc), but why that’s the right tool for the job. - Anthony Ferrara

The New Hotness vs. Legacy Rot⌗

Have you recently heard anyone mocking someone else’s use of jQuery 1.6? Are you simultaneously locking into Angular so hard that you think your blog absolutely must be a SPA? If so, you will be the jQuery 1.6 of five years from now².

jQuery solved some very real problems, and arguably still does. There was a time when if you didn’t have a $(function(){...}), your reputation as a professional web developer would be in serious question!

Huh? -> This is really cool -> I use it everywhere -> Hmm, sometimes it’s not so great. - Mike Hadlow

Don’t let angular.module(...).run(...) be your $(function(){...}).

More Than You Need⌗

These days, people cast aspersions on $('#fancyDiv'), touting the power and simplicity of vanilla.js’s document.getElementById('fancyDiv').

These people often simultaneously take a dependency on the entirety of Bootstrap because they want their buttons to be blue. What follows is a lot of headaches and tweaks trying to comply with Bootstrap’s opinions.

I feel like there is always the “one true way”. The way the tool wants me to do it. … Need another way? That’s gonna be a lot of work. The “one true way” makes me feel like I am driving a slot car. There is nowhere else to go. - Rob Maher

More ironically, what follows is a lot of headaches are tweaks trying to make things look less like Bootstrap and more like what the UI/UX folks really wanted. This becomes a lot harder than the couple of lines of less or sass that would have just made that button blue.

Weapon of Choice⌗

Mastery of a single weapon or superpower will allow you to tackle a certain set of scenarios with grace and ease, but there’s a reason that teams like The Avengers and Justice League exist. It’s rare that any one skill or power will enable you to be the hero of all conflicts.

Instead of a single weapon, what you could instead have is a utility belt. For your superpower, you could choose a curious mind and sharp, critical thinking. Then you could reason about which gadget will best get you out of each jam.

Always be yourself. Unless you can be Batman. Always be Batman. - unknown source, no less true

Disillusionment⌗

If you decide to start using X more than the Y you were using, you aren’t “leaving” the former for the latter. At least, you don’t need to do so. If you do so, no one cares.

Please do tell us what you’re learning and exploring in X. This is how we learn and grow. What I’d like to see recognized more is that adopting X does not imply that Y gets thrown into the bin. Y’s strengths are not removed by your new discovery of X. It could very well still have value in certain applications.

Wrapping This Up⌗

The other day I was asked what tools and languages I’m using right now to get my job done. I very honestly replied that I’ve been working with a wide variety of things including but not limited to C#, node, PowerShell, and bash. The people I work with closely and I believe in familiarizing ourselves with many options, knowing their strengths and weaknesses, and utilizing the right tool for each task. We are building components that do their job and do it well, and then composing those to create the big picture solution. I hope this concept will become more mainstream in the industry. I hope I will never have to explain again why I know both PowerShell and Node, or why I’ve started learning golang along with them.

–