The Long Road is the shortest route

Years ago Ruby on Rails was all the rage - anybody who was anybody was talking about using it, or founding some startup or another with it. I’d been doing a lot of freelance work and hackdays so being able to spin something up quickly that could stand up in production was attractive. So too was being a part of the in-crowd of rails devs who seemed to know where all the exciting work was at. 

My first experience of sitting down to learn Rails was terrible. I got a couple of chapters through “The Rails 3 Way” before feeling an almost magnetic repulsion from it. This wasn’t a reflection on the excellent book - the further I got the more Rails felt like magic, and not the good kind. I had very little understanding of what was being done and to what end. It was a feeling not unlike being blindfolded and arriving at a destination with no knowledge of exactly where I was or how I got there, other than hearing the ocean somewhere on the way.

This lack of understanding turned quickly to dislike, which turned to objection and finally dismissal of Rails as bullshit. It must be, I reasoned, one of those hype frameworks I’d been warned about, all mouth and no trousers. This is a distressingly easy argument to make from a position of little understanding, and makes for easy dismissal of future advocates as foolish, having already personally determined it to be a waste of time.

I settled on Sinatra as an alternative and quickly became enamored. In contrast to Rails, Sinatra felt like I was in control of the machine, I could see the oil temperature fine-tune things to keep it humming along. I built a great number of projects with Sinatra, picking up additional tools and reusing code for common tasks like user management, routing and auth, and found myself quite naturally falling into an MVC pattern without a solid understanding of what an MVC pattern actually was.

It was about this time a freelance project had me looking at Ruby on Rails again, and it made a disconcerting amount more sense. Implementation that would’ve taken half a day in my Sinatra bootstrap project took an hour in Rails. Enjoyment slowly replaced the disorientation I’d felt before, so much so that I began using it to bootstrap hackday projects. It was a gift, like I’d fallen in love with an enemy.

Why the about-face? Rails had remained largely unchanged, the projects I was working on were similar. The primary difference was my understanding of exactly what problems Rails was meant to solve. In the beginning Rails was a sledgehammer to crack a walnut, a much more unwieldy tool than I needed, dismissing it was the correct course. But over time as the nature of my problems changed, cracking 1000 walnuts a minute rather than one a day, Rails looked much more reasonable a tool. I had to experience those problems before I had an appreciation for the ease Rails afforded me, to take the long road there before taking the highway back. 

I’ve come across similar problems with teams frequently as a contract engineer. With the benefit of experience it’s easy for myself or a colleague to put forward a tool, but nonetheless find general disagreement from the rest of a team. Telling a skeptical team why a tool is great is seldom an argument winner and, time permitting, I’ve found it to be a valuable exercise to let the team go down what you believe to be the wrong road for a while. 

Given time to see where this route leads, it either transpires the team were right and you simply backed the wrong horse, or more often, a team begin to feel the pain of the problems the tool you suggested solves, changing their mind about the tool in the process. 

First-hand experience is generally more powerful than vicarious experience. While on the surface its more time-efficient to tell engineers why something is better, taking the time to allow a team to feel the pain and understand it pays dividends in the long run - if not in your own organization than in neighboring ones. And in the cases where you’re wrong? All the better, the team has gained a superior tool to tackle a problem and you’ve learned a better way to solve the problem - nobody’s right about everything.