Interview With David Heinemeier Hansson – Creator Of Ruby on Rails

A Small Intro..

As much as learning is a continuous process, it’s also important to learn from different people. Going a step further, it’s insightful to learn from people that are doing different stuffs than you. As a software engineer, I see a programming language as a tool; but the concept and principles of software programming are fundamentally generic across most (if not all) languages. Keeping this in mind, this time I step forward to interview someone who is more bounded to another language, namely Ruby. And this person is none other than David Heinemeier Hansson, aka D.H.H, who is the father (creator) of the famous Ruby-on-Rails (the Ruby framework).

Even though I’m not a Ruby guy, I really appreciate DHH’s way of thinking and his achievements. His thrust to go forward and achieve things in his style, is really inspirational.

Who Is David Heinemeier Hansson aka D.H.H

David Heinemeier Hansson The Creator Of Ruby on Rails

• The Creator Of Ruby on rails
• Partner of the successful & dynamic 37signals.com
• Best-Selling author of the book REWORK
• Want to know more? See: DHH’s About on his personal website

And Now The Interview

>> what does it take to build a framework and your advice to learn building one?

The best way to build a framework is to not even try. Instead, extract it from a working application. That’s how Rails came to be. I didn’t sit down to think “Oh, let me design a framework“. No, I sat down to write an application and then extracted the reusable pieces from it.

>> What would be the Top advice to someone who wants to be
>>> i) A good programmer

Become a good writer.

>>> ii) a good software architect

Please don’t. Anyone actually calling themselves a “software architect” is a pompous fool. It implies that they can just sit back and think up what others need to do without getting their hands dirty. Hogwash. You need to implement to design.

>> Could you tell us what are some of the best practices you believe in and would strongly preach to anyone

Convention over configuration is the corner stone of Rails and a principle I hold dear. Stop wasting time configuring things where the differences do not matter.

Writing code at the same level of abstraction within a given scope, like a method. I hate seeing code that mixes high level and low level concerns in the same scope. Kent Beck calls this pattern Composed Method.

>> Every software architect has a set of basic guiding principles that helps them make the right decisions when it comes to software design. What are your most important guiding principles?

I don’t call myself an architect, as mentioned above, but I design code using the before/after approach. First you write the code with the tools and how things work today. Then you propose an addition or simplification that’ll produce the after code. Then you compare the two.

This has to be done from real code in a real project and preferably at least three times across different situations. You’ll find that your great ideas often aren’t so great as it fails to simplify the code.

>> Building a framework entails a lot of decision at different levels, could you share with us what are some of those decisions and the factors affecting those decisions

My guiding principle for making decisions for Rails is that we’re building something for people to aspire to. We’re not trying to dumb things down or protect the beginner from himself for its own right. Those are auxiliary benefits that come from just designing something that’s good and simple for everyone.

DHH, thank you so much for your time!

Now Do Your Part!

1) LIKE 7PHP dot COM on FaceBook – if you appreciate what I do

2) Help diffuse this interview – Share, tweet and spread the word to your audience ==> That would be a FREE way to thank me 😉

3) Make a comment below using the comment form – I’m sure you can at least say 1 word about this interview

{I’m thankful to your response(s)!}