Technologies come and go. We learn and grow as engineers over time but some things are eternal: knowing what is truly important to you is critical in differentiating between a path to misery versus fulfillment. Like your coworkers and your environment, the technology you work with day to day can make a big difference in your job satisfaction.

When I first discovered Ruby and Rails, its ethos and ecosystem resonated with me more than any other project I’ve worked with:

  • Maximize developer happiness
  • Convention over configuration
  • Very fast prototyping (remember DHH’s “Build a blog in 15 minutes” video?)

What this boils down to is simple: Ruby optimizes for me. Other languages or systems might hold runtime performance, stability or formal correctness paramount but often at the expense of developer happiness. When I test drive a library or framework, I find myself evaluating it against those criteria. Can I get started with it quickly? Do I need to twiddle a lot of knobs or understand a large domain model first? How much code is tedious boilerplate vs truly important application code?

One mistake I often see younger developers make is putting a lot of weight on runtime performance when evaluating a technology, often to the exclusion of almost all other variables. “Library X can frob 1800 times per second whereas library Y only frobs 1100 times per second so I guess I’ll use X” This is equivalent to selecting a car based on the amount of horsepower shown on the window sticker. Theoretical maximum performance is merely one dimension of what should be a more nuanced evaluation.

Consider your own choices: what does your language choice and technology stack optimize for? Are its priorities your priorities? Find a set of technologies whose priorities match your own and you’ll be that much closer to a sustainable career.

“Look at all the things I’m not doing!”

The original Ruby on Rails screencast, circa 2004.