Ruby

In Conversation: Russ Olsen

by Andy Borsz on August 12, 2013

For the past two years I've noticed a trend when I've gone out to Ruby user groups in various parts of the country: beginning Rubyists who appear the most equipped and well on their way to Ruby proficiency all have seemed to have a copy of the same book with them: Eloquent Ruby. Further back in time I recall Design Patterns in Ruby occupying a similar place in the Ruby infosphere. Last month I got the chance to talk with a person who has literally been shaping the minds of learning Rubyists for the past several years, Russ Olsen.

AB: Russ, what have you been up to lately?

RO: Oh, I've been on the road quite a bit – it's been kind of a blur. I was in North Carolina twice and in Boston once in the last month, so I'm now reacquainting myself with my family and house, that kind of thing. I did a conference in Boston last week, and then there was some job related travel, and RubyNation was tucked in there – that's the local Ruby conference that I help organize.

AB: You've been involved with RubyNation since the first one, right?

RO: Yeah I actually helped organize it from the very beginning. We were all doing the NOVARUG – the Ruby user group. RubyNation started out as a way to finance our pizzas.

AB: [laughing] I expect that there's a lot of work that goes in to setting up a new conference just for pizza financing.

RO: Our original idea was since there was no conference in Northern Virginia, we'd just use our company's big conference room – we could fit seventy or eighty people, and it would just be very low key and very simple. About two weeks in, it just mushroomed into something else. I did set a record this year – I'm now the only person who has spoken at every RubyNation. I finally outlasted the competition.

AB: Does setting up a conference give you some insight when you're speaking at another conference? Does seeing the inside-track and doing that work give some different perspective as a speaker?

RO: Oh, God yes! I never complain at conferences. It doesn't matter what goes wrong – I just think "Oh, those poor people. Those poor, poor people."

AB: Do you have advice for speakers – besides not complaining?

RO: Show up on time and then get off the stage on time. The funny thing is that a lot people will finish on time or even finish with no time for questions, but then they'll just plant themselves there, and people naturally want to come up and say hello, and they're so happy to be talking to people, and next thing you know you need a big old vaudeville hook to pull them off.

AB: So it's really about logistics then? Show up, do your thing.

RO: Yes, but mostly the speakers are just great – they come, spend their own time, they spend their own money, and it takes a long time to put these talks together, so who can complain? So there you go – I said I don't complain, but I just complained!

AB: Well I goaded you, really.

RO: Yes!

AB: You're one of the early adopters of Ruby and started working with Ruby several years before Rails.

RO: I don't know how serious I was, but I actually picked it up sometime in late 2000 or early 2001. I've used versions of Ruby that probably no longer exist or that exist only for archeological purposes now.

AB: What was it like coming through that and seeing the the Ruby ecosystem change with Rails?

RO: Well, if there was any place that there was a Ruby community outside of maybe Tokyo it was Northern Virginia where I was living at the time. But I picked up this obscure language and I just didn't think I'd there was ever going to be anyone else using it who I'd actually meet in the flesh. I didn't even go out and look for other people or anything because I figured, "you know, there's probably this guy in Japan and this guy's in Europe, so what's the point?" So I was pretty surprised when 2004 rolled around and inside of a week I had a couple of people send me emails, and my coworkers were pestering me – they were all saying "hey, you know something about this Ruby thing, don't you?"

AB: Curiosity ramped up so quickly that you can think about a particular week?

RO: Yeah I honestly don't remember when that was specifically, but the curve really ramped up in that week. There were people chasing me around saying "oh, Ruby, Ruby, Ruby", and it was only then that I looked around and found the screencast showing you how to make a blog in 10 minutes or whatever. Everybody knew about that before me because I wasn't looking, you know? Just was not looking.

AB: So was Java your primary language before that?

RO: Yeah, I started doing Java in maybe '97 or so, so I had done a lot of Python and Java for a while. Eventually everything was being done in Java, and I was doing a lot of Java, and then doing web applications in Java, and like everyone else I was just so frustrated with the state of web applications in Java – so certainly by 2004 it was just absolutely maddening. Then Rails came along, and it took me a couple of years to talk whoever I was working for at the time into trying it.

AB: That's funny that you say "like everyone else" – that's the first time I've ever heard of a general discontent with Java web applications. I mean, people are still using it.

RO: Java has gotten a lot better, and at least in my opinion, Rails the reason it's gotten a lot better. Rails is a wonderful thing in Ruby, but I think it's been a wonderful thing for a lot of other language communities too, because people looked at Rails and said "oh, it's possible. It's possible to do better than we're doing." For instance, there's a web framework in Java called Play, which is actually pretty good. I don't want to say anything to be derisive – like "how can it possibly be good" – but I think from a Rails programmer's point of view, yes, it's Java – but it's really well done in that Rails-style 'trying to be as convenient as humanly possible' kind of way. And that's a direct influence of Rails. So it's funny, Rails is a wonderful thing in Ruby but I think it's spilled over into a lot of other languages. Just Google for 'the Rails framework in X' where X is another language and I think for any X you'll get a lot of hits.

AB: But you've been programming long before you were doing Java – that's not your first language.

RO: Yeah, I realized something the other day – if programming started roughly in the 1960's, I've been doing it about half the time that it's been around.

AB: [both laughing] That's awesome.

RO: Yes! But I never really wanted to do anything else.

AB: But I though you started out as a mechanical engineer, isn't that right?

RO: I was, I was. I have a degree in mechanical engineering technology, which was itself sort of a frustration with mechanical engineering as it had been taught. It was getting too theoretical. Mechanical engineering technology was supposed to be a throwback to sort of more hands on kind of stuff, and boy was I really badly suited to that.

AB: Really?

RO: It always impresses people to say I used to do mechanical engineering, but I was terrible at it. Just awful.

AB: [both laughing] That's really surprising to hear.

RO: Well you know you've got a talent for some things and not so much for other things.

AB: Well, how did that transition occur, what was that like?

RO: My specialty was heating, ventilating, and air conditioning systems. I was fascinated by heat flow and that kind of stuff. I graduated at the time when it was just about possible to – at great expense – use mainframe computers to analyze the heat flow in buildings. Engineers would run an hour by hour simulation of heating and air conditioning systems in large buildings – this was during the 1980s energy crises, so people were really interested in making buildings energy efficient.

So I graduated, and I had always been fairly computer literate and I liked to program, but anybody more than about three of four years older than me didn't know anything about computers. There were all these sort of traditional "guesstimation" techniques for designing air conditioning and heating ventilation systems, but we started doing these simulations. Specifically, we were going into existing buildings someone else had designed and saying "what can you change to make this building more energy efficient?" I can remember coming to a building that had a boiler in it that was two thousand times bigger than it needed to be. Two thousand times bigger.

AB: Whoa! Is that from people being over cautious or not having accurate data?

RO: Well, there were standard tables, literally a five volume handbook, and it was just full of all these interesting facts, like how much heat does a chicken give off and that kind of stuff –

AB: [laughing] A chicken?

RO: I'm not kidding! In fact, if I can remember correctly, I think a person gives off something like 250 BTUs of heat per minute or something. Or maybe it's per hour.

AB: Wow.

RO: It's funny the things that stick in your mind, right?

AB: [laughing] Yeah.

RO: But there were all these tables, so you could take a standard 20,000 square foot office building and estimate how big a boiler it needs. Except that this particular office building wasn't an office building at all – it was a telephone company central switching center, so essentially it was a self-heating building. It was a building that was end to end filled with electrical equipment that was never ever turned off, right? So you didn't really need much of a heater. You need a lot of air conditioning in the summer, but not much. So I was doing these really complicated simulations in FORTRAN, and I ended up being the expert on fixing simulation bugs. From there I just kind of decided that I wasn't really crazy about mechanical engineering, and I got into CAD – computer aided design – where there were more big FORTRAN programs.

AB: Automated graphics?

RO: CAD systems are built around a graphics engine, so I was doing a lot of that, and from there I spent a long time with mapping systems, GIS (geographic information) systems, and office automation.

AB: Do you mean like Microsoft Office?

RO: No, I mean like before Microsoft Office. [both laughing] This was a mini computer system with dumb terminals – I'm telling you I've been doing this a long time. It's fun to think about. You know, if you look at where I started and where we are now, the really good news, is that we're getting better at this. It's not just that the computers getting faster and the languages are getting more sophisticated – we are getting better at this.

When I started working on large systems – systems where ten people would work on it for a year – if you and I were going to work on somewhat related systems, we'd sit in a room for half a day, you and I, and we'd scratch out some interface ideas on how our pieces would work together, take a couple of pages of notes, maybe do some whiteboarding, and then we'd go down the hall to our separate offices and six months later we'd emerge and expect these two huge pieces of software to just mesh together. And if you couldn't do that, you weren't any good at it or you weren't really trying. And the funny thing was, I was never any good at it. I never knew anybody who could make that work. And now it's funny because we know it won't work and never could work.

AB: It seems like a reasonable idea on paper.

RO: Yeah, but that's the kind of thing you have to learn – that we as a profession had to learn. I can remember people talking about "source control Nazis" who were making us check in our work once a week.

AB: Oh my goodness...

RO: I'm not kidding, you know. "You want me to check it in? Well what if it's not right? I only had a week to work on it."

AB: [both laughing] That's amazing.

RO: But the good news is we're getting better at it.

AB: How and when did you make the decision to start writing technical books?

RO: I was working at a company that had one of lunchtime speaking events the way you guys do, and I had actually given a talk about the Apollo moon landings. At the time, I was terrified of public speaking, but people really liked that talk and it got me to thinking that maybe I could turn it into writing – so I developed this two or three year plan where I would write a blog for about a year, and then I'd graduate from that and start submitting articles to websites or maybe actual paper magazines, and then after a year of that I'd put together a book. It was a very long term thing. Well, I started blogging, and a couple of months into blogging I wrote this article that got sixty or seventy thousand hits in a day. And not too long after that, I wrote about three hundred words on design patterns in Ruby – the article is actually on the design patterns in Ruby site somewhere. I'd written that article on a Monday, and on Friday afternoon I was just coming back from the company happy hour feeling pretty good and my phone rang – it was this guy from Addison Wesley, and basically he said, "I see you've written three hundred words on this; can you write a hundred thousand?"

AB: That's great! It must feel awesome to get approached cold like that.

RO: Yeah, I think people who are interested in writing but haven't been published have this feeling that there's fierce competition – you're holding your manuscript up above the crowd trying to get it in publishers' hands, but in fact, they're just looking for content. I think they're desperate for content.

AB: So I know that you're doing some programming with Clojure now. I doubt this is your first experience with a functional programming language, so what initially drew you to Lisp languages?

RO: I'll put it to you this way: an old Internet joke is that every large program has a half-implemented, buggy version of Common Lisp embedded in it somewhere. Back when I was working on CAD systems I actually wrote a buggy, half-implemented version of Common Lisp and embedded it in the program I was working on. I actually wrote it in FORTRAN, God help me, because that's what that system was written in.

I like the simplicity of Lisp. I'm not going to go all mystical and tell you the universe is constructed in Lisp – in fact according to the XKCD guy it was hacked together in Perl, right? – but it was never really practical for my career, never ran in the right environment, was never fast enough ... and then Clojure came along, runs in the JVM, is reasonably fast and it's got this laser focus on being practical, so there you go.

It's also got some cool things that a lot of other Lisps don't have. I think people have this idea of Lisps as being functional; I think Scheme is reasonably functional but with Javascript or with Scheme or Common Lisp you can be down in the bowels of some pure function twenty-nine levels deep and simply plug something into a data structure, change something, mutate something and then suddenly it's not functional at all. So in most of the functional languages the functionality is voluntary, but in Clojure most of the native structures are immutable – you just can't change anything. The Lisp is simply immutable, there's no changing it. You can make a new one that looks a lot like the old one, but you can't just go in and change the fourth element to twenty-four in place; it's just not possible. It's a purity thing with some really deep implications if you're trying to write functional programs.

AB: What kinds of things do you think that programmers using object-oriented languages can learn from languages like Clojure or Scala or from functional programming in general?

RO: In object-oriented programming the objects tend to be accretions of data. You've got the first name, last name, employee number, salary, all of that stuff in your employee object, and it's all typically mutable. You know the problem in testing where you have to somehow build a shell around the object you're testing to give it an environment context? A functional programmer or someone who's used to functional programming languages looks at that and it just seems wrong from the beginning. So even when I'm writing in an object-oriented language I have a respect for isolating objects so that they're not tangled to other things, because then you can make it sort of functional and you can get some of those functional advantages.

My default position now if I'm just writing some object, some class, is that I tend to start with a class that's immutable. I make an instance of this thing and I cannot change it. And then grudgingly I will let you mutate things if I absolutely, positively have to. And it's funny, people tend to think "Oh, you're going to write some functional style and you're going to have these long chains of method calls" and that kind of stuff – and there's some of that too – but it's mostly focused around how much is changing, who has control of it, and when does it change.

Take the classic problem where you've got two threads and the one thread is changing some object – maybe it's the a bank account and you're running a money transfer, or there's an employee and you change their title but then you change their salary later and somebody looks at the object and they've got the new title and the old salary, that kind of stuff -- let me just plug Closure and say that just can't happen with it. You've got the old version and you've got the new version, and that inconsistency just cannot happen, which is pretty cool. It's generally something you worry about in other languages, through – you start that second thread and suddenly you're looking over your shoulder.

AB: It seems you've spent a lot of time embedded in companies on software teams doing internal projects. How has the change to consulting been for you? What do you enjoy or find frustrating about the differences?

RO: It can be a challenge – I'll put it to you that way. When you work for a product company, you can build tools that stand on top of the tools that you just built. There's a lot of time to work up a set of things that make your life easier, and we do a lot of that at Relevance too, but you just can't build like that on the same scale for clients because things are changing so fast. I'm on this project, I'm on that project, that's the part – if any – that can be kind of frustrating.

The fun part of it is things change so fast! It's hard to get bored. In the last six months or so I have worked on everything from very, very high level system designs to situations where we have this little Rails application and we need three new features and we need them right away. My title at Relevance is "architect", and I guess I have as much right to that title as anybody else, but it's a title I've always avoided because I always have this vision of an architect as the guy down the hall in the corner office who never really does anything, but is always wanting to take credit for anything good that happens. I never want to be that guy. So the range of things I do at Relevance means every so often I'm down there adding the next feature to some little Rails application. That keeps you grounded, you know? It keeps you from saying [in a stuffy voice] "Well, in my extensive experience..."

AB: I saw someone online kind of somewhat humorously applying some pressure on you to write a Clojure book, or implied that you had already had written a Clojure book.

RO: I remember, yeah – that was much to my surprise.

AB: Is there any plan for that?

RO: I am writing about Clojure; it's not in book form, and it will see the light of day soon, but I can't actually talk about how it's going to come out. I'm trying to do the Eloquent Ruby thing to Clojure, and we'll see how successful I am – I'm trying to at least get close. It's hard for you and me to see the world from the point of view of a beginning Ruby programmer, right? So for all these assumptions that we have and things that we know, there's all these moments of learning that we've forgotten, and we've lost touch with the fact that it took some time to know what we know now. So I've been really wanting to do this Clojure thing because I'm still new enough at it that I still have that feeling of what it's like to be a beginner.

AB: What's next in the works besides this Clojure writing?

RO: I actually spent the last year going around and giving this talk about explaining technical things, I called the talk Eloquent Explanations.

AB: Yes! I love that one.

RO: Thank you. That was actually based on lots and lots of notes that I have for a book about explaining things. I think it's one of the things that we as a community can improve. It's gotten better in the last few years – there are some spectacular examples of good explainers, our friend Sandi Metz, for example – but in the mean, in the average, we are the people in the world that have the most things to explain and are the worst at it.

Part of the problem is that we tend to be introverts, so public speaking doesn't exactly come naturally, but I also think we've actually been trained to do it badly. As a writer of technical books, I've read a lot of them and some of them have wonderful things to say and they don't say them very well. But if you think about conferences like Ancient City Ruby a few months ago, you go out in the hallway and you'll just see people literally in each others' faces telling them what they're doing and what they're thinking about, and you just stand there in the hallway and listen – and they're explaining themselves so much more clearly than if you put them up on a stage or asked them to write an article.

And so it's there. We can do it – I just think a lot of natural communication has been trained out of us. I also think that programmers overgeneralize – there are lessons we've learned about programming that we overgeneralize into trying to explain things. Like DRY – Don't Repeat Yourself is a marvelous principle of programming, but is the worst possible thing to do in an explanation.

So that's one of the books that's kind of been on my back burner for a long time. It's something close to my heart, because I think that if we can get better at explaining things, we can move the ball forward rapidly. If everyone gets 5% better at explaining things, that means everyone gets better in something that they're not very good at, and that's pretty cool. If I could make something like that happen, I will really have done something.

Russ Olsen is a programmer, writer and occasional teacher. The author of two books on Ruby, Design Patterns in Ruby and Eloquent Ruby, Russ lives outside of Washington DC with his wife Karen, his son Jackson and one very moody turtle.

Twitter: @russolsen

Website: http://russolsen.com