Tammer Saleh, EY’s Director of Engineering, sits down with Customer Systems Analyst Josh Hamilton for a nice long talk about test-driven development, his new book, and the secret to exuding total confidence at conferences (hint: get drunk the night before). Josh: Tell us about your role here at Engine Yard and give us an idea of what you’re currently working on.
Tammer: My official title here is Director of Engineering. I’m also the general manager for the AppCloud product, which is our flagship product. I end up wearing a lot of hats here at the office. On any given day, I bounce back and forth from spending a lot of time in meetings, to hallway discussions, to managing the developers, to setting up roadmaps. I also do some development myself.
Josh: How did you end up here at Engine Yard?
Tammer: Honestly, \"Randall\":http://evilmartini.com/ got me drunk at a bar, and the next day I had a contract in front of me.
I started out of college doing systems administration work. I worked for CitySearch and I worked for the University of Illinois doing artificial intelligence stuff. I also worked at Caltech doing the earthquake protection system. That gave me a lot of systems experience and a different point of view, so when I went back to development working at \"Thoughtbot\":http://thoughtbot.com—which is a great consultancy in the Rails world—it gave me a different perspective on things.
So I built up my Rails experience and my development experience working with them, and later independently as a consultant, which gave me more of a business point of view on things. Combined, all of that made me a perfect fit here at Engine Yard.
Josh: Besides the time you’ve been spending here at EY doing all those tests, you recently published a new book, called \"Rails Antipatterns: Best Practice Ruby on Rails Refactoring\":http://www.informit.com/store/product.aspx?isbn=0321620283. Congratulations. How did this book come about?
Tammer: Well, I was working at Thoughtbot under \"Chad Pytel\":http://chadpytel.com/, and we were at Railsconf—this must have been almost two years ago. We were watching \"Obie Fernandez\":http://obiefernandez.com/ speak about the influx of developers who are not totally immersed in the Rails world, and the kinds of challenges that they were going to face. And Obie is pretty opinionated, so he was talking mostly about “rescue missions” and how much money there was to be made doing rescue missions as your sole line of work (he was totally correct, by the way). Afterward, Chad and I, we walked up to Obie and said “As a consultancy, we know exactly what you’re talking about, we see all kinds of terrible practices.”
We had already been toying with the idea of making this idea into some kind of publication, and we decided we wanted to work with Obie to make that happen. He jumped on it faster than I could believe. Suddenly I had Debra Cauley, a friend to a lot of people in the Rails world, from Addison-Wesley, talking to us about what the book would look like. Chad had actually co-authored a book on Pro Active Record, so he had some experience in the publishing industry. I had no idea what I was doing. All I did know from reading blogs about it was that I wasn’t expecting to make any money. I just wanted to get the thoughts out on paper and get my name out there. So we went to work on it, and it took almost two years to get it published.
We had the book shipped down to Rubyconf down in New Orleans, and that was the first time I held it in my hands. It felt amazing. I should have known how long it was going to take when I talked to Josh Susser at Pivotal, and he said, “that’s great \"Tammer\":http://tammersaleh.com, but I have lots of friends who have written their first book, and no friends who have written their second book.” And he was absolutely right. It was such a trying experience, having the constant weight of this huge project above me. Any free time that I spent I kind of felt guilty about. Once we actually had it sent to the publishers, Chad and I just felt so much relief. It was great.
Josh: Is there a plan for a second book?
Tammer: No. Not unless you’re about to offer me something interesting.
Josh: Explain a little more about this book. What is an “AntiPattern?”
Tammer: There are other books that have the same structure. Basically they describe common worst practices that you see out in the field that are just horrendous. You wonder why people make this mistake, and you realize you’ve seen it ten times, so it’s clearly systemic. The book describes these AntiPatterns in very explicit detail as well as what kind of coding mistakes are happening. It also describes solutions.
The reason that I like this type of book is that during my early development career I really got a lot out of the O’Reilly recipe books, because you could focus in on one little aspect. Say you were working on Perl hashes or something like that—you could just jump straight to that chapter, to that little bit. You could immediately get some very applicable advice. We wanted to make sure that this was not a book that you had to read from beginning to end to get information out of it. You can jump to any given point, and get some really good feedback.
I went through the table of contents and pulled some of my favorite AntiPatterns. One that I hate is one we call “Spaghetti SQL,” and it’s really common. You see someone who’s new to the Rails framework who doesn’t quite trust the active record stuff, the “magic” that’s in there, all the associations and validations that are in there. So they end up writing these huge chunks of SQL code that span like ten lines. Most of the time when you dissect this string and start refactoring it, you come out with maybe one line with just a couple of chained associations and that’s it—so it’s clearly a bad practice. One of my favorite phrases is “code is a liability.” The less code you can put in your project, the better off you are.
There’s another AntiPattern solution that’s proving to be successful is dissecting your monolithic application into services, and how you can do that without increasing your incident of downtime. We called that the “Krakken codebase.” The names of the AntiPattern in the book are supposed to be tongue-in-cheek.
Josh: You’ve done some Open Source work in the past. Can you explain to us why Open Source is important to you, or why Open Source should be important to developers?
Tammer: Open source is really about passion, to me at least. I’m not so political about open source—it doesn’t really matter to me what license it’s under, or that sort of thing. Open source is really about the fact that the code is written by somebody who’s passionate about code. Otherwise, they’re just writing it for their 9-5 job, and unless you work at a place like Engine Yard that sponsors you to work on open source stuff, it’s just going to be closed source 9-5 code.
Open source code is really about those developers who are spending their nights at home hacking something interesting because they’re passionate about it. And the cool thing there is that most of the time, that passionate code is going to be higher quality code, and it’s going to come out with features faster, and bug fixes faster, and it’s going to be code that you can trust.
Even when I was a Systems Administrator, I would always trust open source software over closed source software, even from companies like Oracle. It’s also a matter of trust in terms of the political and business issues going on. One of the things that killed me when I was dealing with Cisco software was that they would put these arbitrary limits in place that they wouldn’t tell you about before you purchased it.
Open Source gives you the power to do whatever it is you want to do, because they’re not going to put stupid limitations around you.
Josh: You created the Shoulda testing framework. Last week we talked to Dr. Nic, who’s really big into CI. Could you explain to us why testing is important to you and why testing is such an important habit for new developers to cultivate?
Tammer: I should say right off the bat that the Shoulda testing framework was one of my earlier pieces of code, and I still love it for what it does, but I’m almost 100% positive that there isn’t a single line of code in it written by me anymore. Thoughtbot writes some amazing code and they have been refactoring that thing left and right, so I’m sure that it’s entirely not my baby anymore--but it’s still a great tool for testing.
Like most developers who came into Test-Driven Development, I was skeptical at first, because it seemed like a waste of time. But there was this moment when I suddenly just “got” it, and then I kind of freaked out about it. The things that it gives you are a simpler code base and a strong sense of confidence. You no longer have to worry about having done a three-hour coding session, knee-deep in this huge bundle of mess, and having to wonder, “Can I deploy this to production? What’s going to happen?”
With TDD you’ve got this great confidence that nothing majorly bad is going to explode on you. And then, of course, there’s the whole rhythm of TDD and behavior-driven development, where you know exactly what it is that you need to do next. When I first started developing, I found myself getting to this point where I didn’t even know where to go next, I didn’t even know where to start. TDD gets you into this rhythm where you’re pumping out little widgets sometimes, and that’s a good thing.
Josh: This next question is one that I’m really not sure how to ask, but everyone keeps telling me to make sure I ask it. I guess that last year you were given an honorable mention as one of the top ten sexy geeks of 2010?
Tammer: Oh boy. I don’t know how people keep hearing about that (but if you want to tell your friends, please do). I was working as a consultant at the time, and one of my clients was the boyfriend of \"Violet Blue\":http://www.tinynibbles.com/ (NSFW), who I’ve actually been a fan of for a long time. She does sex education stuff in San Francisco, and she’s pretty cool. But I’d never met her. She’d never seen me! I have no idea how this came about, and then all of a sudden I saw that on her blog and I thought, you’ve got to be freaking kidding me, did her boyfriend put her up to this? As it turns out, he didn’t put her up to it-- he didn’t know how she saw me, either. So that was a little uncomfortable.
Josh: One of the other things you’re known for is speaking at conferences. How did you get into it, and what advice do you have for new developers who might be interested in speaking at conferences in the future?
Tammer: The main piece of advice I have is that you should speak on topics that other people aren’t focusing on. The first time that I spoke at any conference was at RubyConf, and I spoke about writing daemons. That was because I had a background in systems administration, and I had never really seen any documentation about how to write daemon in ruby, and the talk actually went over really well because it was something the audience hadn’t seen before, and it was highly technical. A lot of times, the more technical talk gets the better reception, I’ve found.
I still get nervous when speaking, and the best piece of advice that I give people is that you should give your talk hungover. That is seriously the best way to deal with that. Not so much that you’re going to throw up—I’m not saying that you should go really whole hog, or anything like that. But the edge will be taken off at that point. So you’re not up there acting all nervous. You seem calm and collected, but really you just want to go home. Also focus on your audience, and all that crap.
Josh: How do you juggle all these different projects? Any last piece of advice?
Tammer: Well, I used to have more side projects, but to be honest right now I don’t have time for anything interesting. At most I’ll keep one pet project slowly going, to code on, just to have something to relax with. It’s like sitting down and reading a book. That’s how I relax—I work on something where I’m the only decision-maker.
In terms of being successful in general, the most important piece of advice I can give you is that you’ll open up a lot more opportunities if you don’t focus only on being a developer. It’s fine to try and make a long-term career out of being the best developer you can be, but that’s a lot harder than having multiple skill-sets. Being business-minded can make you successful.
