The Invisible Developer

At least in the JavaScript world, there's a tendency towards following the herd.

"What does <Insert Startup or Big Company Here> use?"

"I saw a lot of people talking about this on Twitter."

"My CIO just said we need to be using ____."

Technical decisions are made not because they're appropriate for the project or for the team/individual, but simply because they're in style. In turn, projects go from unchecked optimism to freak in the clocktower burdens where everyone involved lets out an audible groan when they're mentioned.

Why does this happen?

The term that's come to mind is: The Invisible Developer. As you work, there's a nagging thought in the back of your mind. You want to use a less-popular library or you find a framework that's past its hype cycle that makes sense to you and you freeze.

"Is anybody else using this? I probably shouldn't use this...what is everybody else using?"

This is a trap that I encountered early on in my work and I see others falling into it on a regular basis.

The trap is getting your mind ensnarled in the dogma of the day. Worrying more about how popular a tool is or who's involved with a project more than the usefulness of it. Thinking that if you use this taboo tech, someone, at some point in the future, is going to point and laugh.

This is the invisible developer. They don't exist. At best, it's the other people on your team, but they too are beholden to the invisible developer. He sits on their shoulder, muttering "actually" and "if I were to do this" or "nobody's used this for years."

The antidote is to recognize, first, that the invisible developer doesn't exist.

They're a figment of your imagination, a form of self-doubt that stunts the development of your judgment skills.

Beyond your first few years, relying on this character is counterproductive. Instead, you should challenge yourself. Do use that taboo tool. Play with it. Really try to understand it. Take the toaster apart.

The advantage? While you will most definitely end up wasting some time, what you gain, what the invisible developer can't see, is experience.

You learn about the quirks, the gotchas, and the trade-offs that are invisible at the popular kid's table. You learn about the secret swimming hole that nobody knows about while you're out collecting bugs.

And in turn, you become more valuable as a developer. That weird rendering quirk that no one can figure out at work? "Oh, I saw this cool mini framework that nobody's talking about that can solve this in minutes."

Superhero sh*t.

This mindset helps you with your own ideas, too. Instead of just using whatever is the soup du jour, you take a crack at building your own framework to understand how they work.

The point here is to have fun. Don't make development a matter of fitting in, but a matter of figuring it out.

Remember, if we're honest, the goal of our work is to solve problems well, and ideally, quickly. Sometimes, solving those problems quickly may require working with tools or languages that others scoff at (or that we've convinced ourselves are off-limits).

Instead of getting rattled by the hoodied malcontent in the corner, learn to trust yourself and don't be afraid to go down a road and double-back.

The skillset that you develop will make you an irreplaceable asset to whoever you work with.

You'll also feel better, too.