Follow @nemild
nemil
  
 
Chasing the Shiny and New in Software
Debates about the best current frameworks or programming languages regularly happen in web development. In this vein, Jared Friedman, the co-founder of Scribd, wrote a post recommending Node.js over Rails for anyone starting a new company in 2015.

He makes a few key points:
  • Rails is slow
  • Hack academy graduates are using Rails, devaluing it for senior engineers and diminishing its future prospects
  • A startup should use what a prospective engineer will want to hack on in the future and future proof their application
  • At Scribd, they've made the transition from Prototype, to jQuery, to Coffescript, to Angular, to React over the last few years
Node* is a great choice for startups, but two parts of his broader critique worry me. First, that a startup engineer should understand what technology will be popular in a few years and future-proof0 their stack. Second, that great software engineers will be attracted to a startup by the modern stack, rather than interesting technical problems. In the past, I've heard more pernicious forms of this from the startup developer who refused to take a job where ES5 Javascript was written (CoffeeScript had recently come out), to the engineer bent on ripping out Postgres for Mongo in production soon after Mongo was released,1 to the desire to continuously refactor into the latest frontend framework.

I worry that some programmers (and their employers) have this attitude, namely a focus on transitioning stacks to the newest. They pick companies primarily based on the framework, aiming for the latest instead of the best tool for the job. They spend their time playing with new libraries and frameworks, instead of improving their core technical skills. Let's call them stack chasers2 - those pushing for new technologies (or their own favorite technologies3) in a startup's stack, with limited advantages for key outputs (software capabilities that users value, development team productivity).

"Modern" Web Development
Pity the modern web or mobile app developer on Hacker News. As a full stack startup developer in 2012, you were building websites using Ruby/Rails on the backend, Backbone/Coffeescript/Underscore on the frontend, while deploying your app with Capistrano (or the relevant Python analog). By 2013, you'd transitioned to Node/Express/Mongo on the backend, Grunt/Ember on the frontend. In 2014, you'd switched whole hog over to the MEAN stack (now with promises), but experimented with Koa and considered a shift to Go (after the Express core contributor made the jump). In 2015, you're using Gulp/ES2015/React on the front end, Express/Go on the backend, React Native over the native mobile languages, and slowly transitioning your system over to microservices with Docker. Soon, you'll be transitioning to Phoenix, figuring out if Angular 2 is the right choice - and maybe even plotting a world where Go can work on Android and where an open sourced Swift might fit into your stack. (I’m clearly exaggerating for effect, though this is a fair representation of what is popular in HN headlines)4

There are several reasons this can be rational. The modern web engineer is required be “current" to get a future job or contract; employers use a framework or language as a filter, rather than testing critical thinking and skills. Employers don't realize that strong developers can become experts in many languages or frameworks in weeks, often days, with the right support. Sometimes the writing is on the wall: Swift is replacing Objective C, the world is moving to thinner, less monolithic backends and heavier, more responsive frontends. And often times, there are huge advantages to a switch: productivity goes up substantially or new user features are suddenly possible. And yet, all changes are not do or die for an early to mid stage company, and learning something for fun or a side project is a far cry from arguing that it's critical for production.

It's illustrative to compare a modern web or mobile developer in a startup to our other computer science brethren. A friend is a computational neuroscientist at a top tech firm - and like almost all people working in technology, his world has been reshaped every few months - with rapid advances in computing power, brain imaging, and deep learning algorithms. The basic programming tools have changed little though. To be fair, there was one C++ 11 to 14 transition which caused some angst. There are also distributed computation systems, key/value stores and other external services, but these are built with stable APIs. Most of his time is spent with architecture and algorithms in a single DSL, rather than rewriting functionally similar code or learning libraries that provide debatable benefits and change quickly.5

Choosing Tools
People may suggest that choosing a modern stack is a critical recruiting tool for great startup engineers.6 My own observation is that the greats look for other things. By far, the most important are interesting problems to work on - and interesting people to work with them on. Traction and a powerful mission are additional ways to attract great people (engineers or otherwise).

This is hardly curmudgeonly whining on my part to say that tech moves too fast, and that we should all be writing in Assembly or C++ or Ruby. Software engineers know what they sign up for - our field moves at a dizzying pace, and it's all worth it for both the impact we can have as a billion people come online. I'll argue that you need the ability to pick up a new framework, language, or library lightning fast (an Ask HN on how to do this) - and with experienced engineers around you, you should aim to be productive quickly (days or weeks). Beyond that, you should typically have deep comfort with a diversity of languages, not simply one (but this same attitude, shouldn't be blindly extended to frameworks or lightweight DSLs).

For startups, PG was asked in 2013 about ideal languages: "I mean, we have had startups writing their code in PHP – and that worries me a little bit. But not as much as other things worry me." Sam Lambert, Github’s Directory of Technology, in a recent interview speaks about his surprise at how much Github's stack is Rails, C, and Bash scripts when he initially interviewed with Github's CTO in 2013: "Then as the interview process went along, it was more revealed to me that this is actually a really pragmatic set of hackers that just hack on Ruby, hack on C and spend their time working on more interesting things using a more stable stack, rather than chasing after the latest and shiny tech." Github's approach strikes me as the right balance for web and mobile engineers (startup and otherwise): explore tools widely, but then pragmatically choose the tools that solve the problems you face (YAGNI applies in a lot more places than just user facing feature development).

What worries me is that certain developers, especially developers early in their career, may get the idea that a startup engineer is not a problem solver or computer scientist, but a glorified look up table - every few months their task is to memorize a new DSL - to get limited8 benefits. This devalues who we are as early stage engineers - building things that people want, working on interesting technical problems, and shipping code rapidly.

By all means, experiment widely in your extra time. Switch out languages/frameworks in production if the benefits are overwhelming, but think about what the benefits are. Be critical of people who are cheerleaders for the new, without being thoughtful about the expected advantages for your team. Spend your time learning concepts and solving interesting technical or user problems. And if you have the right application boundaries and choose the framework you're productive in for now, you'll have some flexibility if your about tech choice,9 but persistent enough to get to product market fit and beyond.

Open Hacker News on any given day, and there'll be posts beckoning you to contribute and build applications in a framework, language, library, or service of choice (including some companies like Mongo with serious cash, and therefore marketing budgets, behind their platforms). Some will have game changing capabilities, others a few critical differentiating features. But each will require time10 to become an expert. Some will loudly proclaim how they're the future, and look derisively at what you've learnt - but they'll need your skills and mindshare to truly compete with existing technologies. How will you choose?

Written with MacVim 7.4, though I should have used Atom - or at least Neovim.11
feedback? drop a note to nemild at google's email service
Published August 2015
All opinions expressed are solely my own. Thanks to the following for feedback and warm-spirited debates:
  • Ben Lerner
  • Vince Colonna
  • Connor Hailey
  • Michael Mokrysz
  • The team at Thoughtbot
Footnotes
Some Personal Thoughts
Like all software engineers, I have technology preferences, some a bit irrational. I sometimes like Go compared to more traditional web frameworks for both performance (compilation, easy concurrency) and how stable/feature rich the APIs are. I prefer HAML/Jade over HTML because I like enforced indentation and conciseness and speed of coding, and found Emmet/Zencoding too late. I was an early CoffeeScript acolyte, as I was consistently context switching into Ruby at the time. I roll my eyes at the number of Make variants that are considered “progress", but still will use Rake and Gulp.

The difference is that the best startup engineers I know aren’t dogmatic about these. For myself, I'd toss aside most preferences in a second, if I were working on an interesting problem. Show me a cutting edge innovation in Bitcoin (no counterparty risk, multi-party transfers using the Lightning Network?) or in the infrastructure of the Internet (IPFS?), and I'll switch to C++ or Go or Java, or whatever the open source devs decide on. Have a company working on an innovative database as a service that needs high performance and scale, and I'll move over to Cassandra after a few weeks of iteration (and probably a lot of mistakes). Give me the ability to pair with Jeff Dean for a week, and I promise to switch out VIM for Emacs going forward (among other changes).7 And if a Bret Victor/Braid/LightTable-inspired editor ever comes to full fruition, I'll drop that Emacs in a second from my day to day programming needs.

* While I discuss the broader critique, I'm doubtful that Ruby is dead - though I do see a world where a subset of the Rails middleware (e.g., templating, the asset pipeline) is made optional (Rails API is one example, a custom built Sinatra stack is another). If you have a product/team with good Ruby knowledge and are building a monolithic or tightly coupled webapp, I wouldn't switch - but be sensible about application boundaries. Sure, on average, Rails response times are slower than Go or Phoenix/Elixir or Node/Express, but there are a lot of startup products where it doesn’t matter (e.g., the CRUD webapp, with growing, but not web-wide scale). And the cheapest way for most early stage companies to scale is to throw more servers at the problem, rather than picking a lower productivity language with the hope of future scale benefits. (Back)

0. "Future-proofing" strikes me as a sisyphean task in software, even in the best of times. It gets even harder when the focus is a high level framework or library, rather than a (more stable) foundational language or tool. (Back)
1. In a startup that was building a basic marketplace CRUD webapp with a small addressable market, and deep uncertainty about product/market fit (Back)
2. I see ‘chasing’ mostly in frameworks, libraries, and tools, but from time to time in languages as well. (Back)
3. If much of the team has the same favorite, it may be better to follow this – as teams do well with the tools they know intimately. Things get problematic where individual engineers each have their own favorite and advocate for changes primarily because it’s easier or more comfortable for them, rather than beneficial to the team. (Back)
4. For a sample of churn fatigue on the Javascript frontend side, see this 2015 state of the industry post. Apologies for not including the Python stack (Django, Flask) in greater detail, which should also be included near the top of any list of popular web frameworks in the last few years. Apologies also for not including the changes in the mobile landscape. (Back)
5. I provide this comparison for illustrative purposes, not to suggest that the web development APIs should be this stable. (Back)
6. I agree with Jared that some engineers will want a stack that is “sexy” (has some buzz, is new, and is something their friends find exciting) – but I think these engineers are doing themselves a disservice by choosing this metric as a way to identify the startups that will grow their technical chops. (Back)
7. I know that text editors are a far cry from the current roulette of front-end frameworks, but hopefully the fact that I’m willing to switch something that developers value so highly says something. (Back)
8. Limited given the needs the startup has; compared to the framework's creator, the startup's stack or users may not dramatically benefit from the framework's key advantages, such as ease of scaling or faster performance. (Back)
9. I’m being a bit glib about switching things out – obviously, switching out a frontend framework is very different than switching out a database, so the latter requires more thought at the start. (Back)
10. Especially when considered in total across the full set of frameworks and libraries available to learn at any given time. (Back)
11. Said jokingly, I'm a fan of both these projects. (Back)