I really enjoyed DHH’s articulation of the Rails Doctrine. He does a fantastic job of reflecting and clearly explaining where he stands on issues.
I savored the entire piece, thinking about where I may agree or disagree. By going up a level, as this piece does, to articulate the 8 pillars, resets the mission in some ways.
Rails was born in a time where many of us were building CRUD web applications. I fell in love with it in a similar way to DHH, in that ruby fit my brain. I care about the nuances and being able to choose my language. I enjoy the poetry of code, and Java was never a love, but rather felt like a language for the masses (which has a lot of pros, but didn’t fit my preferences).
Fast forward to today and we are thinking about all of the platforms and reach that we can get to our users. We are thinking about services, and although I share the disdain to premature-micro-servicification, we often serve multiple clients and need to cater to that world.
Rails can work well in this new world, but the price of the opinions don’t pay off as much as it may have back then. Other options have improved, and there are more choices to be made (messaging, database options, etc).
Art and Service
The other item that jumped out from the piece was the talk about art and its intrinsic importance. It is framed that building something to get a job done is beneath the art. This is where I disagree the strongest.
“It was the event that marked my own personal transition from ‘doing programming because I needed programs’ to ‘doing programming because I fell in love with it as a mode of intellectual exercise and expression’.” — DHH
I think that it can be a privilege to serve, and service can include building a tool or something of use for your users and even your business.
DHH can argue that this will happen naturally, and that the best work comes out of the art, but I am not sure that this is always the right correlation.
It is perfectly noble to be focused on how best to make your users awesome, and make choices that could even go against The Art and certain purity. You are constantly working within trade offs. Performance is a great example here. I think that we often prematurely optimize and the developer experience can take a hit. However, we should be striving for the best user experience even if we have to do some ugly hacks to make that work. Ideally we can put those hacks in a box so that most don’t have to see it, but it is OK, albeit not ideal, for it to be there.
Earlier in my career I was more focused on the technology, for technologies sake. As time went on I have gotten closer to “what am I doing for my users” and I think a user-centric approach is a great one.
Rails itself is very very user (developer) centric, I just want to make the point that ‘doing programs because I want to impact X’ isn’t lesser.
Thanks again, @DHH, for not only giving us a fantastic toolbox, but laying out a higher story. I know that the post is one that I will revisit and reflect on in the future, and it will cause me to ask myself… what is my guiding doctrine for X?