This summer I had the chance to sit down and talk with Noel Rappin about Ruby on Rails, Ember.js, self-publishing, and the benefits of public speaking.
Noel's latest offerings of self-published technical books has brought us Mastering Space and Time With JavaScript and the upcoming Trust-Driven Development.
AB: How long have you been working with Rails, and what got you into it?
NR: Well, I'd been a web developer on and off since about 1998, starting with ColdFusion as my first tool. I got out of web consulting for a while and started hearing about Rails around 2007. I was managing a remote team split between Chicago and Poland, and I started building up a couple of tools that we could use to collaborate. The first Rails program I ever built was a little task tracker that you could think of as a very, very, stupid version of Pivotal Tracker.
AB: There are a lot of versions of Pivotal to be built out there.
NR: Yes! Yes, it was something I needed that could be built quickly, and Rails turned out to be really good at it. I was already a little bit familiar with Ruby, so it was nice to be able to write Ruby in a real context. It wasn't long after that when I moved back into web consulting and started working with Rails professionally – and started writing about it too.
AB: You bring up writing about Rails – one could say that you wrote the book on testing Rails apps.
NR: [laughing] You're just saying that because it's called that.
AB: Therefore it is! Right?
NR: Okay. Yeah.
AB: So how has the way that we test Rails apps changed since when you started working with Rails?
NR: Well, Rails has always had a very strong culture of testing, and one of the things that attracted me was that the core team put in a lot of great testing tools. So it had already started from a good foundation, and there's always been a sense in the community that testing is the right thing to do. What's changed over the last few years is that the tools have all gotten so much better – and there are more of them. We talk more specifically about unit tests versus integration tests in a more separated way than we did when I started working with Rails. I came to Test::Unit first, and then later to RSpec – after being kind of skeptical about it – and have started using other tools that didn't exist when I started, like Cucumber and Capybara.
AB: Is the Rails testing culture stronger now?
NR: I don't think that the community's attitude has changed about it, but I do think that more people in the community are really signing on to what what we like to believe that we all do.
AB: I remember as a beginner feeling aware of a strong test culture, but I think it's a common tendency to take for granted the things that you already know. You can grow comfortable with the TDD process and forget that some of this can be really tough for beginners – I remember that phase as a beginner. I go to meetups and there are a lot of questions about testing. Are we taking it for granted that we've gotten used to testing? Is it hard to test a Rails app?
NR: Well, it is hard to test certain things. I think one of the things I can't say that we've done is gotten a lot better at explaining how to do this to newcomers in the community, and I'm probably as much to blame for that as anybody –
AB: Ha!
NR: – but I think that there are two aspects that are difficult. One is that certain parts of a real application are just challenging to test, and they often tend to be important parts, like security and third-party tool integration. Also, for some things there are tricks for how to test them that you just need to learn, and it's not the natural red/green/refactor process; that can only take you so far. Figuring out how to write a good red test for dealing with a billing system is not trivial, and I think that that's one of the problems.
I also think that the message of why you do this kind of thing sometimes gets a little muddied – this has always been true about TDD since the term was invented. There's always been this ongoing conflict between testing as a tool for driving design and testing as a tool for validating your application, and I think people who are new to testing can get confused because they're actually doing one of those things and they think they're doing the other. They're writing tests as though they're driving design and they're surprised it's not validating their app and catching all their errors, or they're writing tests because they're validating their app, and the design part of it feels really tedious. But those are two separate activities.
AB: Absolutely. I think that that's a very good reflection on the kinds of confusion I've seen with newcomers, where they're writing a test but they're not sure exactly why.
NR: One thing that I think has changed in the community – and I think this is an outgrowth of now having longer lived applications – is that there's a lot more attention to dealing with legacy test suites and a lot more attention to object-oriented structure. In the last year and a half or so, a lot of discussions in the Rails comment have come down to the fact that we have to maintain older applications – codebases that we may wish we architected differently when they started.
AB: In mentioning Rails Test Prescriptions compared to what you're doing now, you have experience on both sides of the publishing spectrum. You've done the traditional publishing company route and also the DIY self-publishing approach.
NR: Yes. I've also gone in both directions in that I had a DIY book that became a traditionally published book and a traditionally published book that became a DIY book. [both laughing] Yeah, it's a little weird.
AB: So how and why did you get started self-publishing?
NR: I actually started with self-publishing. Rails Test Prescriptions was originally self-published for a specific reason: I wanted to write about testing because I wanted to write about something I felt I really knew and didn't need to research. At the same time, I knew the publisher I wanted to work with, Pragmatic, was working on an RSpec book – so I just assumed they wouldn't be interested in another testing book. So I decided to self-publish, which I did for about six months, even though the tools for self-publishing and distributing books when I started doing this in 2009 weren't as good as they are now.
It was very, very hard at the time to come up with a place that would easily distribute digital media and allow you to send updates. In fact, I actually wound up having to hack my own because there wasn't a service that provided that at the time. A few months in, Brian Hogan actually suggested that I submit the book to Pragmatic, which I did, and they bought it – so then it became a traditionally published book.
There's an immediacy to self-publshing that you don't get from a traditional publisher – even a really agile company like Pragmatic. I see every time an order comes in. I see the name of the person – [laughing] – which also tells you that I'm not getting so many orders that it's an avalanche distracting me from everything else I'm doing – but there's a connection there. Self-publishing is enough of a novelty that a lot of the people that buy the book become very invested in its success, and that doesn't really happen with traditional publishing. People have gone well beyond sending me corrections and actually do copy edits. It's really gratifying to have people donate some time to help in that way. You gain a lot of control over your distribution, your layout, things like that – and you give up some resources in terms of having access to professional designers and editors and marketing – so everything is a tradeoff, but I have a lot of fun doing it myself.
AB: Do you have any advice for prospective authors whether they're pursuing self-publishing or another medium to get their work out?
NR: You don't need to be an expert in a topic to start something. It helps, but it actually helps less than you might think. If you come to something already as an expert, a lot of times you've kind of lost touch with the process of learning something new, and that can make it harder to get in the mindset of explaining something to someone coming in cold. Now, the topic does need to be something that you become an expert in over the course of working on a book. Writing a book is a long process, and if it's not something you're really excited about learning more of then the process will be really, really long.
I recommend if you've never really done anything like that to start with something shorter. Blogs are great for this kind of thing – if you set yourself the goal of doing regular blogging, like "every Wednesday I'll write about a gem that I use" or "every Thursday I'll write something new I learned while working on my Ember app." That's a good way to start easing into the rhythm of working on something regularly, and it's also a really good way to build traffic. One of the best ways to build traffic is to just be there consistently and get people in the habit of finding content in a particular place.
AB: I really enjoyed your talk at RailsConf this year where you were going over some of your experiences with Javascript frameworks. When did you start giving talks and throwing your hat into the ring at conferences – was it before or after your writing career?
NR: I had done a couple of talks in grad school at SIGCHI (the computer human interactions conference), so speaking came really naturally for me when I joined the Ruby community. My first talk submission, I think, was contemporaneous with the first thing I published in the Rails community. That's something that I really like. You know there really aren't very many technical communities that have the kind of consistent regional get-togethers that Ruby communities have, and to be able to go and meet people doing the same things and facing the same problems is really great. When they occasionally let me get in front of a bunch of them and try to explain something, it's even better.
AB: I think, for most people, 'natural' and 'public speaking' are not words that they put together in the same part of their vocabulary. You should probably consider yourself lucky in that regard.
NR: You know, it's a skill like anything else. And if you've done it a few times, you get better at it and are less nervous. Merlin Mann, the podcaster and writer, talks about really thinking about the worst things that's going to happen – nobody's going to eat you.
AB: [laughing]
NR: I also was in a lot of theater and that kind of stuff when I was in high school, and that was deliberately because it was something that made me nervous. I wanted it to not make me nervous, because it's a really useful skill to be comfortable with that kind of thing, in part because so many people aren't. Just showing up is a big part of success, and if you're the person who's comfortable getting in front of a group of people, you become associated with being knowledgeable because you're communicating that.
NR: With Mastering Space and Time you've been writing not just about Javascript but about a lot of frameworks as well. Are you using some frameworks that you haven't written about? Is your writing about a framework kind of a 'Noel Rappin Endorsement' of that framework?
NR: [laughing] It's an endorsement in that it's something I found interesting enough at the time to write about it. I was actually using Ember as I was writing about it. I was not writing a large-scale Backbone application at the time, although I was doing some smaller projects with it. At the time that I started writing about Ember there was a huge gap in documentation and that's much, much less true now eight months later. There's Ember content all over the place now. I've been asked a couple of times if I'm going to add something on Angular, and I'm resistant in part because I don't really know much about it yet, and I'm not sure that that's where I want to spend time next – but there does seem to be some interest, so that might be something that I look at.
If it's an endorsement, then it will usually pretty explicitly say that in what I write. It will come through pretty clearly what parts I'm endorsing and what parts I'm not. I don't think I'm at all shy when I talk about parts of Javascript that that absolutely make no sense, and that carries through to frameworks too.
AB: I've been getting really into Ember and finding that I like it a lot; you stay pretty partial in the books in talking about Backbone and Ember – but would it be fair to ask for your Ember pitch? What excites you about Ember?
NR: I'm actually really excited about Ember. I think that it's very powerful, and Yehuda has gone on record talking about how their goal was to try and pull the best practices from a lot of different frameworks in and opinionated kind of way, and I think that they've been pretty successful with that.
One of the things that really encourages me about it is that they've been very, very good at listening to the community that's forming around them. Their original router syntax was really, really hard to work with, and they got a lot of feedback on it and came up with another one that was better – and got a lot of feedback on that and came out with another one that was actually even better. They've made a lot of updates to the framework that have been motivated by people's experience using the it. They started from a place of trying to do something really powerful and ambitious, but they've admitted in cases where they were wrong, and they've taken things that were maybe more difficult than they needed to be and put a lot of effort into improving them. You see that happening right now with Ember Data, which has some very well-documented limitations and problems, and they're really making a concerted effort to polish that up right now.
AB: I was not one of the people who had tried Ember or SproutCore early on, but in combination with Yehuda's talk and your talk at RailsConf, I got the sense that this is definitely a time to try Ember if you're remotely interested in Javascript frameworks.
NR: Yeah, it seems like it needs about a year of thousands of developers building apps on it to really get to where it needs to be. Rails was the same way. Rails in the 1.0 and pre-1.0 times was obviously trying to do a lot of things that frameworks hadn't done very well in the past. It succeeded at some of them and didn't succeed at others – and they were also open (for the most part) to improvements based on the actual community's experiences using it. There's a lot of that process going on with Ember right now.
AB: I don't want to lead you into any topic that you don't wish to discuss, so let me know if it's okay – but for a while in the Rails community, there was an undeniably massive topic: there were these two very large companies, these deal sites –
NR: [laughing]
AB: – huge Rails companies that were hiring, from the outside perspective, practically all Rails developers. This has died down somewhat as an issue, but a couple of years ago this was the hot topic.
NR: Now it's just GitHub hiring them all, right?
AB: [laughing] Yes. So for people who don't have that experience, what is it like to work in a massive Rails company that was basically competing with another massive Rails company?
NR: I actually feel like I am pretty comfortable talking about this, because I can be completely up front and say that my experience at Groupon was really idiosyncratic. I can speak with perfect authority on something that has nothing to do with anybody else's experience, and with intermittent authority on stuff that has nothing to do with me at all.
AB: [laughing]
NR: I joined Groupon as part of a group of developers that came in when Groupon purchased the consulting company Obtiva, and I went straight into a role at Groupon that largely involved internal developer training, so I never had the experience of being a normal part of a regular development team at Groupon.
I think that one of the things about the way that Groupon was organized – at least the Rails side of it, and again I'm speaking from a somewhat outsider perspective – is that they tended towards smaller autonomous teams. Teams tended to have their own structures and way of doing things, so experiences there tended to vary quite widely. Some teams were really committed to testing and agile practices like pairing, and some other teams just weren't.
So there was a very, very wide range in Groupon. The company – I think for reasons that made sense – was not really interested in mandating stuff from the top, and for whatever reason there was never (at least in the time that I was there) a really strong push for a unification of that kind of stuff. There were some common tools being used – there was a continuous integration set of tools built on a Jenkins core that they'd built up that was well suited to having 250 Rails developers hitting the same codebase, which Jenkins just is not suited for out of the box. That aspect of it was interesting, but in practice it tended to be a lot of small teams sort of pointed in the same direction more than it felt like one really big team.
AB: That's probably the healthiest way for something like that to work. I couldn't imagine feeling like there were 250 Rails developers on my team.
NR: Yeah, and that's unsustainable. But what's tricky about that is that a lot of those teams really were sharing a codebase, and probably sharing a codebase more efficiently than they were sharing knowledge about that codebase. Again, I can speak with no authority whatsoever on what actually happened on the internals of these teams. But it was very interesting to see what Rails development looks like with that many people throwing code in the same codebase, and throwing tests in the same test suite, and how you start to control the sizes of those, and how you deal with situations that the framework really wasn't designed to handle.
AB: You have a new book in the works, right?
NR: Yes. Trust Driven Development It's currently available at an introductory price, which means that you get the introduction and nothing else yet. [laughing] The idea to write about software projects is something that I've wanted to do for a long time. We talk a lot about craft as it applies to how we put our code together, and how we put our applications together – but there's another side to that craft, in terms of how we put projects together, and how we relate to the people that we're building software for, whether they're an internal client or an external client or customer. There are right and wrong things to do, and there's a professionalism inherent there too – and I have opinions about that. It's something that I've wanted to write down for a while. Right now my biggest worry is that it's going to come out as series of huge angry rants –
AB: [laughing]
NR: I'm taking care to mold it into something that is more appropriately structured as a book and less like a cranky guy telling everyone to get off his lawn. A lot of it is about the relationship between development teams and either the management or the customers, and how you can build trust. It's tricky to write about that and not make it sound like one side or the other is always right, because of course it's complicated – and as much as developers have issues making themselves understood to the teams that are depending on them, those teams also have difficulty making themselves understood to developers.
It can become a frustrating exercise on both sides, so a lot of this is about techniques and processes to try and improve the way these teams work together. A lot of is Agile based. I think that among the reasons Agile processes work is that they give you a lot of small opportunities to build trust. The Agile community describes it as feedback, and what that turns out to be is a lot of situations where you have a chance to say "I told you I was going to do this, I did it", "I told you this was going to be difficult, it was difficult", "I told you that this would be easier if you did something a certain way, and it turns out that that's true."
At some point in the project, you as the developer are going to have to go to somebody and say "something went wrong," "this is a lot more complicated than we thought", or "we just made a mistake." I talk in the introduction of the book – which is also available online for free right now – about this being the moment when you're at the auto mechanic and the mechanic comes to you and says "you need new brakes, it'll cost $2000". Is that a good price? Do I need new brakes? I have to trust that this person understands what's happening and is communicating that to me effectively, because I don't understand it myself. It's incumbent on the mechanic to be right, and also to explain the problem to me in a way that leads me to that same understanding.
As developers, when we're working with people that are outside the development team, we have to have that same ability. We need to be able to explain what we're doing, and when things go wrong we need to be able to say so – and what happens when you say something has gone wrong depends on how much trust you've built up to that point. If you've built up a lot of credibility by doing things well and meeting commitments, then ideally you have a certain amount of leeway when you need to say "oh, this is actually more complicated that we thought and it's going to take some extra time." The boy who cried wolf becomes a real issue here. If you always say that then the one time you really need it you have less credibility when you ask.
AB: Absolutely. I think those are very good topics for consultants as well as in-house developers – all of that applies regardless of your customer.
NR: Yeah, I hope so. It's a mix of theoretical stuff about process and practical stuff – like how to have an IPM that actually is effective. I'm enjoying writing it, and I'm hoping to structure it into something that other people will find useful.
--
Noel Rappin is a developer at Table XI. He is the author of Rails Test Prescriptions, Trust-Driven Development, and Mastering Space and Time With JavaScript.
