Don't Forget What's Important

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.

2 thoughts on “Don't Forget What's Important”

  1. I couldn’t agree more.
    I use Rails for APIs (ruby is awesome)
    NodeJS + Grunt + Yeoman for the web application front end. (static AngularJS site)

    Recently I’ve needed to be able to run multiple threads from a single process with eventmachine performance, multiple reactors and promises for coordination. So I built a library to do just that, uv-rays (and its core dependency libuv).

    One of the great things about the OSS model is that anyone can help improve runtime performance and ruby has been going from strength to strength in recent years.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>