#37 The Matz Bookshelf: part 2―Chad Fowler, author and VP of Engineering, LivingSocial
初出：Software Design 2012年5月号（2012年4月18日発売）
When Ruby inventor Matsumoto “Matz” Yukihiro talks to programmers, he sometimes mentions two books: From Java To Ruby: Things Every Manager Should Know by Bruce Tate and The Passionate Programmer by Chad Fowler. We met Tate last month. Now, it’
Most American programmers would not be happy to be sent by their employers to India. But when General Electric transferred Chad Fowler to Bangalore to run an off-shore development center, he didn’
As a developer, Fowler is largely self-taught. He was born in Little Rock, Arkansas, and attended college in Memphis, where he became a professional saxophonist. While playing gigs, he also played video games, including Doom, which led him to learn to program in C--a study he typically began at 3AM.
The musician-turned-developer says he has been a student of human happiness since age 18. “I’
- How did you come to write The Passionate Programmer?
Because of my involvement in the Ruby community, I got to know publisher and programmer Dave Thomas of The Pragmatic Programmers. Dave knew my history, and suggested I should write a book about it. I think he was interested in how I had managed to find a way to both excel at my job and have fun doing stuff I was passionate about, whereas many people with a lot more training and credentials hadn’
t been able to do that. Dave asked me if I could explain what I did to get to the point that I was at in my career.
I was amazed that he thought that my story was interesting. For a while it was even difficult to write, because I kept imagining him and other high-profile author types reading it. What could I possibly have to teach them? At my core, I don’
t think of myself as a programmer, but as a people person. I’ ve lately realized I express that predilection through programming projects.
- But you are a programmer. So are you saying it’
s just not part of your central identity?
Exactly. I have been writing code for many years, but I don’
t identify myself as a programmer or a saxophone player. I don’ t think that is a healthy way to be because it’ s too static to define yourself by the job you are doing. It boxes you in and affects how you think. And it shouldn’ t.
- In your book, you seem to give developers contradictory advice. You tell them to be generalists. But you also tell them to be specialists.
m being contradictory on purpose, because there should be a constant conflict between those two opposing ideas. You’ ll probably head more down one path than the other, but that is something you should always do with intention. I’ ve always been a generalist, and it frustrates me, because I would love to do something like the Rubinius project--a new virtual machine mostly written in Ruby. It’ s a really cool, deep technology project. I look at stuff like that and I think: I understand all the concepts, why can’ t I do that kind of thing? The answer is that I’ m just not that specialized. I don’ t give myself the focus because I’ m doing a bunch of other stuff.
- You describe of a hiring search you conducted some years ago. You were looking for a Java programmer with Smalltalk experience: someone with two skill-sets that don’
t normally intersect.
I was thinking back then of a way of finding people who have expanded their own boundaries. Today, if you are trying to hire a Python or Ruby programmer, you might look for someone who also has a bunch of Java experience. Because the languages are related, a developer wouldn’
t have to go through the mental shifts of moving from one development environment to a totally different one. In the situation I described in the book, I was looking for real good Java programmers, but only found a bunch of shallow ones. When I expanded the search to include the requirement for Smalltalk, I found people who had either had been forced, or--even better--had willingly made the leap back and forth between these two very different environments.
- And once you found them, you couldn’
t afford them.
They were certainly more expensive, and they didn’
t want to work on our stuff because it wasn’ t interesting enough.
- You advise developers who are thinking about their career not to listen to their parents.
Older generations tend to value jobs that are stable, rather than ones you are passionate about. Of course, that’
s not always the case. My parents approved of my choice to be a professional musician. And as it turned out, being a professional musician, at least if you’ re good at it, isn’ t all that risky. Maybe the real risk is in doing something stupidly. If you are careful, focused, and smart about your decisions, you can take calculated risks that aren’ t so risky.
- You talk about “programming by coincidence.” What does that mean?
s programming by tweaking instead of by mastery. Beginners tend to do this a lot, but even today if I run into something that doesn’ t work, I’ ll sometimes be tempted just to find some code online, paste it in, and see if it works. If it does, I go onto something else, without actually understanding the fundamentals.
I think most people program their careers by coincidence, as well. They pick something to study--maybe influenced by a good teacher. They don’
t really know what the job market looks like or what a career in that field would be like. They go to work, the decades pass, and they look back and realize they never actually made a decision about where they were headed.
- You use the term “technology hospice” for people who specialize in dying languages. You argue that developers can sometimes make a decent living doing that.
Definitely. For example, not much is being developed in COBOL. People are no longer learning the language. But how many billions of lines of COBOL exist? The answer is scary, and those billions of lines of working COBOL must be maintained--just like traffic lights and other mundane but indispensable things. So there’
s still an opportunity for bright people to go into a technology like RPG and COBOL, and find ways to help either retire the systems or continue to keep them alive.
- Along those lines, you cite the Buddhist monk Thich Nhat Hanh, who wrote that dishwashing by hand requires still requires mindful practice.
That principle applies to everything you do in your work. You can strive to do a perfect job with every task you have to do, no matter how much you would normally hate doing it.
At LivingSocial, I again manage a large team and must decide what person to put on what project. Who should develop new code and who should be put on maintenance? And then I think: we are all getting paid to come here and get stuff done. So should it really matter whether I am maintaining code or writing new code? That’
s a strange, unnecessary division, which has more to with how you choose to perceive the task that you are doing. The key is to be mindful about everything, even if it’ s just cleaning out your email inbox, which is stressing me out me out right now.
ve been at work for six hours today already and will be here for a few more hours, and I do that every day of the week. If I don’ t like what I am doing, then I am just wasting that time. There have been times in my past where I made a really good salary. But I hated my job, and I felt stuck. That is silly. I felt stuck because I thought I couldn’ t get that salary elsewhere. But if I took half as much money and was three times happier, isn’ t that really the measure that matters? So my advice is: either find work that makes you happy, or find a way for the work you have to make you happy.
- Matz stresses programmer happiness. How do your ideas compare?
We agree, tech-wise, on what contributes to programmer happiness. I’
ve been doing Ruby since 2000, which is before most people who don’ t speak Japanese ever knew what it was. I could hardly describe what it was about Ruby that I loved―it just made me happy. That’ s a hard way to sell something to technologists. But happy people do better work.
- What is it about Ruby that contributes to programmer happiness?
Ruby removes a bunch of the crap that you normally have to do in a programming language, like declaring variables and type safety, semicolons at the end of lines, and braces all over the place. We just assumed this stuff was necessary, but Ruby proved you don’
t need them. The Rails community took this to the next level. They removed stuff from Web development that we all took for granted. Rails and Ruby are so important to the industry because they erased a bunch of meaningless work from our lives.
At the same time, Ruby still allows you to be expressive. You can program Ruby like a Java programmer or like a Perl programmer or a Lisp programmer. You can do crazy Ruby stuff that nobody except for a Ruby master would even understand. Yet all of these approaches could achieve the same result.
- I want to ask about two pictures on your site: they almost look almost like two different people. What happened?
I lost about 90 pounds. Tim Ferris wrote about me in his book, The 4-hour body. He called the turning point my “Harajuku moment.” I was in Harajuku, and was fat and unfashionable. Frankly, I was slowly dying because my health was so bad. I was telling a friend that it really didn’
t matter if I bought nice clothes, because I wasn’ t going to look good anyway.
At that moment, I had what felt like an out-of-body experience, as if someone else had said it. I thought: that was the laziest, most defeatist thing I’
ve ever heard anyone say. The person who said that has written two books, organized two international conferences, been an executive at a large company, and is fairly well known in his field. He has done all these things, and yet he still thinks he can’ t lose weight? That’ s ridiculous. At that moment, sitting on the street at Harajuku, I realized there was a huge, gaping hole in me as a human person. I had allowed myself to be incomplete in this way. That experience forced me to take action and plug that hole.