Noah Gibbs is an author, speaker, lead developer at OnLive, paid Rails expert for Carnegie Mellon, and author of lots of Ruby on Rails software. To promote his GiveGetWin deal, Noah sat down with me to share some incredible insights about working with deep knowledge, how empathy and understanding the user/customer is the path to success in business, and covering many other important insights. If you're a programmer, you'll love Noah's perspective and insights. If you're not a programmer, this might be one of the more insightful interviews you read about why people do programming, and about thriving in a technical skill and business in general.

Building Ruby Castles In The Clouds by Noah Gibbs, as told to Sebastian Marshall

I grew up in the middle of nowhere in East Texas, with nothing there but a state penitentiary. So I had a lot of time with a computer. No internet. Just my Apple II computer, and long stretches of time. They say you need long stretches of uninterrupted time to program.

I had that.

I program because… programming is building castles in the cloud. Concepts on top of concepts. Except that the computer is there to check you -- it's all mental and conceptual, until you find out whether it works or not.

It's almost an escape for me. If I grew up in the middle of nowhere and I'd built furniture, or painted, it's like that. It's a powerful mental exercise. It's competing against myself, and it always has been.

Programming has always been that self-competition. And these days, it's that, plus it's my own little personal space to be myself. I've got a family and an incredibly busy schedule, so I don't have much time or energy to do selfish things with my time. This is a way to self-express with my time, and I really deeply enjoy it.

If I play a computer game, for instance, it's something I do contemplatively. I usually play a game like Starcraft, and I play like most people would play Solitaire. I play the same levels over and over. There's only about five things you do differently every game, but beyond that you're in the flow and it's a meditative experience, where your hands make the decisions without you thinking about it.

Programming is like that. When I know what the loops and functions look like, it just flows and my hands go automatically. While my hands and the lowest levels of my mind are busy with that, I'm surfing on top of that and my mind is busy planning it out.

I'll solve the same problem different ways, and it's like playing the same Starcraft level over and over again. Sometimes they turn out exactly the same, when I don't mean them to, but by trying to solve it different ways it comes to the same end place. I've got a couple things on my Github profile where they look exactly the same, and that wasn't what I was going for. 

I think going forwards everyone will learn some programming. Take spreadsheets: spreadsheets are programming, especially once you learn more of it. Spreadsheets aren't "like" programming. Spreadsheets are programming.

That quote, "Software is eating the world…" -- it's true, and so learning program lets you eat the world. Everything is going to be software soon. You should know a little bit about programming for the same reason that you should know a little bit about how an engine works when surrounded by cars.

Knowing how the spreadsheet works can give you ten times more power in a world that's programmable. You can write little things to work with an RSS feed or email. That doesn't sound exciting, but the first 10% you learn, you get immense practical benefits. With just a little effort into it, with something into it, you can do incredibly a lot.

It doesn't have to look like how I do programming. IFTTT -- If This Than That -- it's a great chunk of "a little bit of programming" that can get you way up on the game. Spreadsheets too. Programming doesn't have to look like what I do. What I do is for people with a lot of spare time.

Or who want a career, but it looks pretty similarly to what I'm doing… but if you're only "putting 40 hours per week in" and thinking of it as work, you won't get really get good at it.

There's a great fella named Michael O. Church, if you're a computer programming trying to figure out office politics. He says for every level of becoming a good programmer, there's work you need to do to get to the next level. But workplaces assign work assignments politically. To get to the next level, you need to work on very specific things with a lot of work. And you only get that work through political connection, but there aren't many good programmers who are good at sucking up to the boss. Some, but not many. So if you don't love it, you probably don't progress to the next level by obsessing and loving it in your spare time outside of work hours.

If it's not your consuming passion, you don't spend 40 hours in the workplace and then another 20 or 30 hours outside of the workplace.

If you're doing it on your own instead of for a job, you have a lot of room to define your own projects and get good in less time than if you're working. Open Source Software gives programmers the ability to work on the kind of projects that get people good. But then you don't get paid for it. Your boss doesn't have to approve it, though. That's the tradeoff.

To become a competent programmer, you can do it with almost any work. But to be what Michael O. Church calls a "multiplier," you have to coordinate other people's work and make them better. That's the nice thing about Open Source Projects, they know how to be solid multipliers and they'll teach you and tell you where you're screwing up. Where you're doing the multiplier thing wrong. And that gets you the rest of the way there.

When you want to learn good taste in most fields, you should study the 'Old Masters' -- not because there aren't people who are alive today who are excellent, but because we aren't sure who they are yet. But in programming, there are no Old Masters yet because it's too young of a discipline. 

That's why I write books around a framework. Frameworks make everyone else more effective, but it's hard to write a framework. Mostly it's hard. The next generation of guys come from there. You learn, "Here's something that's genuinely good. Let's look at the structure. Let's look at what's good about it. This is classical good design, let's look at it."

I chose to write about Ruby on Rails by taking the most beautiful code that's near me, the most tasteful and functional code near me, and I wrote a book taking it apart to really understand it.

I hope guys in other spaces do it -- I hope enterprise guys do it. I hope we see more books like it, taking apart the most beautiful frameworks people enjoy using, and understanding why they're good.

I don't think so many programmers do this, take apart codebases to really understand them, and I don't know why.

You have to learn from somebody, and the people that are good at it almost never have time to teach you. But the code is just sitting there, and you can spend as much time as you want with it. And it's a beautiful, meditative experience. It's like painting for me. I truly appreciate a good piece of code. 

I look at code like a painting. Someone put a lot of effort into a coding. And they put it down in a form where you truly can tell exactly what it is, in a way that you can't with most things. I'm glad other people share their code and you can learn from it.

On a practical level, I'm not fast enough at coding to make as many mistakes as I want to make.

The way I learned knot tying, because I'm not naturally good at that sort of thing and the instructions are usually terrible, well… I started with tying a basic square knot, and I found you'd wind up with a Granny Knot if you tied it backwards one way, and a Thief's Knot if you run the rope through it incorrectly this other way. My experience with a Square Knot is through intentionally screwing it up eight different ways, and that way you know exactly how to do it, and know exactly what you did wrong if it starts to look differently.

I'd love to write code 50 different ways, and see what it looks like. Looking at other people's code… that helps get past the slow part. I don't have time to try something 50 different ways, but I can see how other people did it with their code.

I'm a firm believer of "Follow where the code leads and see what lies there" but to get where I want to get, I have to steal other people's failures. I can't make all my own failures.

This process -- wandering through code and seeing where it leads -- is mostly not how I build practical software. This approach doesn't necessarily lead to building software that's good for real people to use. 

After I tried a few times, seriously, to build things that were worth money… I changed my approach. I know I'm good at coding, so it seems like I should be able to turn that into money ways besides getting a job.

I took Amy Hoy's 30x500 Class -- which is very good -- and it's about how to do programming to make money. To build products people want. She turned the process upside down. She had you not build the software if it doesn't help people. You need to mix talking with people and solving their problems. Sometimes writing a paragraph on a piece of paper, printing it, and making copies of that is more useful for people than a piece of programming.

So I admitted, 'I don't know what my users want' -- which was humbling. I just just know, and don't just have the right answer.

When you talk to product managers and customers, it's a bucket of water thrown on your head about what they give a damn about. Very little of it requires being a genius.

You talk to the people will use your software over and over again until you've got a sinking pit in your stomach of 'I'd love to work on this artistic coding project and it'd be beautiful and a work of art, but if I did this simple thing that takes one day, the users would like it more than if I did this beautiful genius thing that takes three months."

And then users like you better and the people that work with you like you better.

When you start with no assumptions that you've got the answer and talk to your customers regularly, and then build and build and build from that, eventually you get a pretty good answer. Over time, a really great answer. But you never start out with the right answer. 

To build great things, always look at it from the user's point of view as much as you can. That's a "weightlifting skill" -- almost everyone starts bad at it, flatfooted, and there's no shame in that. You have to do it, and do it, and do it again. Do your reps. That's what you have to do to get good at it.

Seeing things this way, from the user's point of view, requires immense practice. It takes a lot of time, and you'll have a long way to go once you start.

But one you can see it from the user's point of view, you stop having to say "even if it's not software." You stop having to say, "even if it's not what I want." Those statements go away. You just think, "I'm the user, what do I want?" Sometimes it's software, sometimes it's sitting down and talking with someone, sometimes it's a piece of writing or a book. But you must stop thinking about the solutions you have in mind. That part should become purely unspoken, and should just be natural.

Most people don't do that, partly because most people are terrible at delayed gratification. Like the Marshmellow test -- you make it clear with a toddler that if they can hold on to a mashmellow without eating it for five minutes, you get a second marshmallow. That's a pretty good deal. But most people can't stop themselves from eating it right away.

But the people who can wait until getting another marshmallow do incredibly well. Willpower is hard; discipline is hard.

Empathy is hard too. It doesn't come especially natural to me, which probably helps me. I don't expect it to come easy to me. But sitting and empathizing with people is hard work.

And it doesn't always pay off immediately. You often don't get much out of it instantly. If you're looking to make money out of it, it takes months and years. Empathizing with people takes hard work, but most people don't even realize it's hard work. So you don't even get to feel good about it! If you dig a ditch, you can say, "Hey, I dug a deep ditch. Nice." But you don't naturally get that sense of accomplish from empathizing with people.

Delayed gratification is hard. When I wrote the book, I had a lot of moments of "I'm spending months on this, and I don't know if anything will come out of it."

The studies show that most people can do it. Studies have shown that women are better than men at empathy. But if you pay people and find the right bribe, men turn out to be as good as women. Once there's something that's worth it, people can do the hard work of empathizing. If it's worth it to you.

To master something, my experience is that you need a layer of the deep thinking to know your own capabilities. Pick something, and get good enough at it to know you're good at it. Pick a hard subject, and get competent at it. Once you can do that, the hard part of the subject can never steer your ship. You know you can go where you want to go.

After that, knowing other people, empathizing with other people, and helping other people with their problems gets you there faster.

Deep knowledge for its own sake is like anything else for its own sake. I do lots of it for its own sake, for myself.

But to really get what you want, you then need to layer on that empathy, to understand other people, and use that deep knowledge to help others get what they want.

That's not necessarily software. The deep knowledge is a means to an end. Treat it that way. Unless you're doing it purely for yourself because you're in love with doing it, but don't be confused or blur it. If it's a means to an end, you treat it that way.

Think: "Here's what I want. Here's how others can help me. Here's what I need to do for them so they'll help me. And here's the method that will let me do that." Deep Knowledge is around the fourth step, not the first.

If you're doing it right, the first step is being driven by what you want. Step 1 is figuring out what you want, and most people skip that step. And everything goes to hell if you skip that step.

My little four steps are what you get when you extrapolate from, "Here's what I want, how do I get it?"

Get the Deep Knowledge. Master the hard problems. That's absolutely on the list of things you want. It's like money -- it can be a great way to accomplish a goal. But just like you want to lead money instead of following it, make sure you're leading your Deep Knowledge instead of following it. And that starts with figuring out what you want.

You can get a copy of Noah's book, "Rebuilding Rails: Understand Rails by Building a Ruby Web Framework," for only $15 -- whereas the regular price is $40 -- through GiveGetWin by clicking here. The book is for intermediate Ruby programmers to gain a greater grasp of the programming language. You can find Noah Gibbs' contact details, portfolio, and a link to his blog here. There's only 15 copies of Rebuilding Rails available at Noah's generous price for charity; if you missed it at this rate, you can still grab a copy of the book at rebuilding-rails.com to take your Ruby understanding to a deeper level.

Finally, if you're interested in offering your product or service through GiveGetWin or volunteering, send a message to support@givegetwin.com or sebastian@sebastianmarshall.com