I'd like you all to meet Bob.
Bob is a nice guy, and a good programmer. Give him a problem, any problem, and he'll get the job done, cleanly and quickly. He's been at this company long enough to know what the business wants before they do. All-in-all, he's an excellent software developer. There's just one little problem...
He's a zealot. (DUN DUN DUN!)
Specifically, he's a JavaScript zealot. Every problem he's ever encountered, he's solved using JavaScript. Need a file uploaded? The client-side portion will be in JavaScript. Progress bar for said upload? JavaScript. Password generator? JavaScript again! Every single issue he's ever encountered has been solved using the almighty JavaScript.
By itself, this would be an issue, even in a shop where JavaScript is a standard cog in their technology wheel, but an issue which could be overlooked. The real problem is that Bob won't shut up about it. Every team meeting includes at least one "if only we'd done this in JavaScript" snarky comment from him; it's been a good day if there's less than three. His teammates don't bother asking for help from him, because they've learned that the answer is always JavaScript, even if it's the wrong answer. Hell, they're sick of even hearing the word JavaScript.
Bob the JavaScript zealot is actively harming his team.
Fanatics like Bob, be they fighting for an architecture or a language or a stack, are a cancer when working in groups. First of all, the other professionals in said group slowly start to dread working with the fanatic, putting ever increasing distance between themselves and this divisive personality, which hampers team productivity. Who would want to work with a person who's only ever going to have one opinion, one solution?
There's another reason why having a fanatic such as this is counterproductive: most of the time, they don't feel the need to keep learning.
From their perspective, it's easy to see the justification. If there exists a technology which already does everything I have ever or will ever want to do, and I understand it well enough to write applications in it, why should I ever try something new? It's a twisted conclusion, but one that's pretty easy to arrive at. Once mired in this deduction, every problem the fanatic encounters morphs into a self-fulfilling prophecy: use technology X and all your woes will be cured. The worst part is that the person who will be harmed the most by this line of thinking is the zealot himself, and he either willfully doesn't or ignorantly cannot understand why.
To be clear, not everyone who espouses a certain technology is a zealot. A zealot is a bad apple, one who is undermining the team's efforts by wishing aloud "if only we'd done this in Tech X", or even consciously fighting against the team's standards in favor of their chosen savior platform. They're often obnoxious, so infected by the plague of arrogance that they are sure they cannot be wrong. They're the worst kind of teammate; a person who thinks the team should just do everything their way.
Zealotry of any kind has no place in the team-oriented environment that is modern software development. We should not hold up any piece of tech as a panacea, a deity to be worshiped and evangelized, because just as quickly as we understand it it will fall into disarray and, eventually, obsolescence. Everything can be improved upon, and doggedly trying to implement everything in a single language (or framework, or archictecture) is a hindrance.
Further, one of the reasons we have so many different technologies is that they're each good for different things. They're all tools, implements in our development toolkit, and we should use the one that's right for the job, not slavishly adhere to a tool simply because that's the one we understand the best. Use the technology that's fit for the task at hand; that's what tools are for.
Instead of being a zealot, what we should strive to be is an advocate. The advocate can demonstrate both the pluses and minuses of their chosen technology; the zealot either can't or won't see the downsides. The advocate is willing to be wrong; the zealot isn't. The advocate can be a wonderful team player, educating the team about Technology X while thoroughly and clearly communicating its shortcomings, while the zealot drives people away through obnoxious and counterproductive behavior. The advocate improves a team; the zealot tries to drag it down.
Zealotry does nothing except preserve our own inflated sense of self-worth. It doesn't help us deliver a better product, write better programs, or be a better developer. It holds nothing of value to our professional careers. Don't be that guy, unwilling to learn and listen. Don't be a zealot. Don't be Bob.
"Bob" image is fatboy-sitzstack, used under license
Have any of you encountered a zealot (or better, an advocate) in the wild? How did you deal with it? Did you have to work with them a lot, and did they get better or worse? Share in the comments!
