I commuted for years. Up and down Route 95, every day, over and over. On a good day it might take me 45 minutes to an hour each way, but one and a half hours was common, and there were a couple of three hour nightmares tucked in over the years. At the same time, my schedule was pretty rigid – help get the kids off to school, then get back in time to make dinner. Suffice it to say, there wasn’t much time to explore the neighborhood around work, and if you’d asked me what was around the office, I might have drawn something like this:

It wasn’t that I really thought that we were surrounded by post-apocalyptic wasteland, but rather that I’d labeled these areas as terra incognita, put them out of my head, and never thought about them again.

I’ve been thinking about this a lot recently, as I’ve been coming up to speed on the Scratch technology stack – a NodeJS / Express backend, with a ReactJS client-side app. But in a sense, the specific framework isn’t really the point – rather, the fascinating thing is the ecosystem of plugins that have evolved, and continue to evolve, around the proliferation of Javascript frameworks. Any time you need a specific piece of functionality, it’s almost certain that someone else has already developed it, and installation can be trivially handled by npm. It’s so fast, easy, and convenient that it soon becomes the default approach to problem solving.

Compare this with the world I come from – TripAdvisor may seem a bit extreme, but I don’t think it’s that unusual for companies its size and larger. It runs on Java, uses a custom-built framework, and views every external library through the gimlet eye of security, performance tuning, and backwards compatibility. New libraries can be added (because they can be evaluated in the context of a limited set of functionality), but it’s almost impossible to upgrade old ones due to unknowable incompatibilities between versions. This leads to predictable problems – different teams introduce different libraries with identical functionality, and even multiple point versions of the same library, because it’s easier to get approved than upgrading an old one.

Uncritically accepting externally developed code isn’t necessarily a good idea, of course, and not knowing how or why the code works can lead to leaky abstractions that will bite you eventually. At TripAdvisor, all the code was right there in the repo, and there was generally someone around who could explain how and why it worked. There were some parts of the code base that everyone had tacitly agreed to avoid, accept as immutable, and hope never came slithering out of the shadows to interact with their projects – but for the most part everything was fair game.

In this situation, of course, building it yourself isn’t just the default position, it’s generally the only position – getting external libraries approved is hard, there’s strong cultural pressure to build it yourself, and it isn’t like anyone else is writing plugins for your proprietary code base. So, you dig in, do your projects, and soon forget that there’s code outside your repo. It may be out there, but it’s for other people. For people who don’t care about security, performance, or backwards compatibility. Your vision narrows. What started out as an unfortunate impediment becomes a perverse badge of pride, and you look at the universe of people “out there” who are working in “toy” frameworks and just “cobbling together” libraries that other people wrote. Then you sit in meetings where you’re asked how the team can go faster, and you shake your head and avert your eyes because you just don’t know.

Don’t get me wrong – building from scratch is the only way to really understand how something works, and is frequently the right approach. But you can’t know that it’s the right choice if you don’t know any of the other options. I’ve been out in the world for two months now, during which time I’ve been taking a crash course on startup coding economics. At first, it was a bit disconcerting to hear the other developers casually mention that they were adding new libraries (OTHER PEOPLE’S CODE FOR GOD’S SAKE) without a lengthly vetting process. But why should they trust a popular open source library from a well-known contributor less than their own code?

At the same time, trying to convince someone in the Build camp to change is like trying to get a friend out of a bad relationship. “I know,” they say, “I know, I want to, I really do, but I can’t. Not now. You don’t understand. There are too many things going on. It’s too hard to start bringing that stuff in. Maybe when I have a little free time…” And so, they travel the same road up and back, every day, over and over, never turning left or right, never discovering the tools that are lying just off their well-trod path.

WE’RE HIRING

We’re funded, located in a great area, and most importantly – we just released the first version of our project! I’m looking for great engineers who are interested in working on new, fun, hard tech. It’s a plus if you have experience in mobile, dev-ops, or machine learning, but don’t let it stop you if you don’t!

If you’re interested, send me an email!

Follow me on Twitter