October 11, 2016
From nczonline.net, with love.

Technical Tribalism

Hi everyone,

While I was at Yahoo, all of the front-end developers used the YUI library as a corporate mandate. That made sense: if you are paying people to maintain a front-end library, you get the most benefit by having the whole company use it and contribute back. I, for one, really enjoyed working with YUI and many in the company felt the same way. We were a YUI tribe, which served us well at Yahoo. Of course, we wouldn't all be at Yahoo forever.

I ran into a former coworker shortly after leaving Yahoo as he was preparing to join a new company as a tech lead. During our conversation, he mentioned that his top priority would be to switch them over to YUI. The company was using jQuery, and he said he really didn't want to use it. I gently suggested that, perhaps, this wasn't really a battle he wanted to wage. He could certainly evaluate the overall architecture to see what improvements would be made, but going into a company and trying to get everyone to switch to your favorite library or framework is rarely a formula for success. This company's architecture might have been excellent and still built on jQuery, so why decide up front that you don't like it?

When I joined Box, I ran into a similar situation except that people seemed to assume that I would try to eliminate jQuery from the front-end. Time after time I was asked, "are you going to get rid of jQuery?" My response was always the same: "No, jQuery isn't going anywhere. However, I want to make sure its position in the architecture is well-defined." Crafting a solution that used jQuery calmed the fears of the developers and started building trust with the team.

I was reminded of these stories this past week while reading an article about what it's like to try to learn JavaScript in 2016. While the article focuses on just how many technologies and libraries it seems like developers need to learn, there's also a fair amount of technical tribalism in the account. Technical tribalism is chastising developers for not doing things the same way you're doing them, for using jQuery instead of YUI, or using Angular instead of React, when you have no idea about their constraints or the project they're working on. I ran into this, myself, when I dared state on Twitter that I thought I might hate React or JSX. I was immediately attacked by dozens of people claiming I was stupid, ignorant, uninformed, and too "old school." I'm an industry veteran, so I'm used to these random temper tantrums online, but imagine what that experience would be like for a beginner.

Pledging allegiance to a particular technology or approach is fine so long as you don't become dogmatic about it. As I've discussed before, it's unlikely you'll be doing the same thing for your entire career, so your ability to adapt to new technology as it appears is the most important factor for a successful career. Four years ago, every company I spoke with was asking me how to improve their Backbone-based application; today it's React. In another few years, it will be something else. Don't get so caught up in the tribe that you can no longer thing in terms outside of the hot technology right now and are actively hostile to anyone who doesn't belong. This isn't what our industry needs. On the contrary, we need more people who are willing to abandon their tribes to fully understand a problem and arriving at the correct solution rather than the popular one.

Be well.


Exclusive Offer: NCZOnline Newsletter Year One

I've received a lot of great feedback about the newsletter since it began, and a lot of you have mentioned really enjoying the essays, but it's hard to find them after a newsletter has been release. To help with that, I've created an ebook called NCZOnline Newsletter Year One that contains all of the content from the first 12 months of the newsletter in an easy-to-read format. As an added bonus, subscribers can buy the ebook for $0.99 USD for the next seven days(coupon code is provided in the email edition of the newsletter). Each purchase helps pay for the costs of providing this newsletter, so your support is greatly appreciated.

Recommended Links

The Service Worker Lifecycle (article)
Perhaps one of the most complicated parts of service workers is the lifecycle. This article, written by one of the creators of service workers, discusses the lifecycle in detail, include diagrams and animations to illustrate the concepts.

Node.js, TC-39, and Modules (article)
Node.js has been attempting to implement ECMAScript 6 modules for some time now. This has led to several different proposals, and ultimately, to difficulties in implementation. This article covers the history of ECMAScript 6 module design and implementation issues for Node.js, including the recent meeting with TC-39 to discuss what can be done to address these issues.

You Might Not Need Redux (article)
Speaking of tribalism, if you think you need to use Redux if you're using React, you might not need it. In this article, the creator of Redux walks through the scenarios where you might not need Redux. It's a refreshing discussion about the use cases for a common utility and at what point its true value becomes worth the overhead of inclusion.

Moment of Zen

"To raise new questions, new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advance in science."
- Albert Einstein

Recommended Book

My favorite books are the ones that question things I thought I knew, and Debt fits that description. Most of us learned that money was created as a replacement for barter economies, where the only means of acquiring goods was through trade. This book tells a different story: that credit and debt existed before barter, and that today's currency descends from those concepts of credit and debt directly. While a bit slow at times, this is a fascinating (and long) anthropological history of the rise of currency in various forms right up to modern times. Could everything you know about money be wrong? Find out with this book.
This newsletter is subscriber supported!
There are many ways to support it: Leave a tipbecome a patron, or buy a book.

Recently on NCZOnline

ES6 module loading: More complicated than you think
One of the most long-awaited features of ECMAScript 6 is the formal definition of modules as part of the language. For years, JavaScript developers have struggled with organizing their code and needing to decide between alternate ad-hoc module formats like RequireJS, AMD, and CommonJS. Formally defining modules as part of JavaScript will eliminate a lot...

Mimicking npm script in Node.js
I'm a big fan of npm scripts[1] and have been using them in all of my projects instead of a standalone build system. The feature I like the most from npm scripts is the ability to run command line executables that are installed in your project's node_modules/.bin directory. That allows you to, for example, install...

Reflections on ESLint's success
It's hard for me to believe, but I first conceived and created ESLint[1] in June 2013 and first announced it's availability in July 2013[2]. As frequent readers might recall, the primary goal of ESLint was to create a linter with rules that could be loaded at runtime. I had seen some problems in our JavaScript...

Books I've Written


Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.

Ready to subscribe?

Join over 2,000 others and subscribe to get the newsletter delivered to your inbox every other Tuesday. 
If you enjoy this newsletter and would like to support my work (including the newsletter, my blog, my books, and ESLint), please consider becoming a patron. I provide a lot of free content and your support allows me to spend more time doing so, and there are great rewards for patrons.
Copyright © 2016 Nicholas C. Zakas, All rights reserved.

unsubscribe from this list    update subscription preferences