It’s been a couple of months since I left TripAdvisor, and as I’ve been coming up for air, I’ve been going through the necessary process of re-evaluating the conventional wisdom I’d come to accept over the past six and a half years. Some of it was great – generally applicable best practices that I’ll use for years to come. Some was reasonable but specific to the environment – things that made sense at Trip, but aren’t necessarily relevant outside. And some, well, some now just seem kind of crazy.

Like walking through a room I’d lived in for years, and suddenly noticing that all of the furniture was upside-down – had always been upside-down – the thing that sticks out most now is the homogeneous team composition. Far from being accidental, this was the explicitly desired result of an extremely rigorous (and, let’s be honest, a bit meshuga) interview process that selected specifically for smart, well-educated, flexible generalists – the expectation being that anyone who met the bar could come up to speed on anything we threw at them.

And it worked! People came in with .NET, Python, or C++ backgrounds, and started pumping out Java and Velocity their first week. There were some oddball teams – Commerce used Rails, Core Data used Angular – but as long as the technology fit the standard logic-based programming model, the generalists were able to adapt quickly. This flexibility was extremely important, because one of the articles of faith was that specialized skills created bottlenecks (“sorry, we can’t do any more database projects this quarter – that team is all booked up”). Better to have a workforce in which everyone could do anything, than one in which warp coils couldn’t be re-routed when Scotty was on vacation.

The problem, of course, is what to do for skills that can’t be trivially learned. Going from C++ to Java or Python is easy, but no one expects an engineer to be able to quickly replicate years of experience in, say, data science or graphic design – these were well understood to be special skill sets, and reqs were created accordingly. CSS was viewed differently, though – it’s easy for a generalist to get to the level of expert beginner quickly, which leads most engineers to believe that it’s easy – not a distinct skill worth recognizing as such. In this world, “twiddling CSS” is jargon for a boring, technically unchallenging project.

But CSS is hard. Not because of deep data structures or complicated algorithms – those are the kinds of problems engineers have been trained to solve, the kind they enjoy, and can work through even in an unfamiliar language. No, CSS is hard because of the complicated, nuanced, infuriating way the rules don’t quite fit together. The typical path to mastery leads through the valley of the shadow of web dev consultancy, building site after site for years, learning best practices, making mistakes, and tripping over all the special cases. I honestly don’t know if there’s any other way.

This isn’t something that a generalist is going to “pick up” over the course of a week-long project. Worse, the engineer is going to suffer a kind of psychic pain when coding in CSS – the kind of inner anguish one feels when randomly changing incomprehensible code and hoping against hope to stumble across a solution. CSS is supposed to be easy, but for some reason it isn’t doing what you want. Or it’s breaking on Safari but not Chrome. Or it’s almost working, but occasionally making the entire layout go crazy. Fear leads to anger. Anger leads to hate. And the generalist does the bare, hackiest minimum to get through the project, avoiding deeper understanding and “preferring to work on the backend.”

This is where the idea of the “unicorn full-stack programmer” takes a bit of a beating. 99% of them are only full-stack if you don’t treat front-end programming as a real discipline, along with data scientist, operations engineer, native mobile developer, etc. You can have a team of 100% generalists, but any project that requires a specialized skill will take longer, code will be rougher, and – critically – the generalists won’t have an expert to learn from. Consider the difference in experience required to paint a wall, replace a shower head, even knock down a wall between rooms… vs. building a house from scratch. You want an expert to set up the framework, enforce best practices, and mentor everyone else.

At TripAdvisor we removed all bottlenecks by creating an area of mediocrity. There were a couple people with the skills (in an engineering organization of hundreds I can count them on one hand), and they tried their best to curb the worst excesses, but they were always outnumbered, always outgunned.

It’s time to balance the party. I still love to see great generalists, but depending on the project, a strong team also needs a CSS expert, DevOps guru, native mobile specialist, and so on. Everyone with a superpower, everyone with the core skills necessary to contribute to the main project, and everyone with the friendly, humble, learning mindset that enables them to see, but not accept, the current limits of their knowledge.

P.S. In case it wasn’t abundantly clear – I’m hiring! If you’re interested in redefining how people shop online, shoot me an email at daniel at HelloShopper. Thanks!