> innovation tokens Aside: Sorry to be blunt but this is such a dumb term that distracts from some of the important lessons in this talk. The author confuses "

> innovation tokens Aside: Sorry to be blunt but this is such a dumb term that distracts from some of the important lessons in this talk. The author confuses "innovation" with "novelty", "niche", "general familiarity" and so on. Choosing existing solutions has nothing to do with innovation. The innovation already happened. You're just integrating with it. But what about expertise, leverage, problem fit, cost, licensing, performance, bloat, implied workarounds, maintainability, community, attracting the right people and trust? What about simplicity? I think the bottom line here is to choose mastery and depth over novelty and breadth. Being really good at using very few orthogonal tools is a good thing. Spending more time on the abstraction layers above and below you rather than switching between arbitrary choices too. But these things have _nothing_ to do with how novel, niche or "innovative" a given tech choice is. That's just plain old conservatism, which can be an advantage or a disadvantage depending on what kind of work you're doing.