Not every product is adopted the same way. Some are chosen. Others are mandated. That difference matters more than most teams realize. When productivity-enabling teams treat all internal tools the same, regardless of how engineers encounter them, they risk misjudging what good support looks like, how trust is built, and what it actually takes to succeed. When a tool is optional, adoption has to be earned. Engineers choose it because it saves time, improves quality, or integrates cleanly into their workflow.

Imagine you’re running a startup that sells bread. But not just any bread. This is highly experimental, handcrafted, possibly AI-assisted bread. Because of course it is. You’re proud of the recipe, but growing this company means doing far more than just baking a loaf. In this small startup bakery, the team wears many hats. One moment, someone’s a baker. The next, they’re handling customer support, writing distributor documentation, or running marketing campaigns.

In 2015 the company I was working for wanted us to do an overhaul of the existing UI to give a better user experience. We took it as an opportunity to explore the landscape of JavaScript frameworks, something I’ve done many times. We knew the app would be behind a login, so server side rendering was not important for SEO, freeing up the search space to nearly anything. We quickly became enamored by ClojureScript, as we already had been considering Clojure for a backend rewrite.

Back in March, the company I work for was creating a small app and were trying to decide which javascript frame work to use. There was an email chain debating which framework to use. I finally responded, and today a coworker convinced me to post that email: Was debating if I wanted to take the bait, but I love to argue, so I couldn’t resist. I am not a fan of pushing the entire rendering process to the client.

This presentation was built with meteor-impress