Ben Orenstein (@r00k) from the Giant Robots Smashing into Other Giant Robots podcast joins the Ruby Rogues to talk about adjusting and sharpening your development tools for better flow and easier development.

Special Guest: Ben Orenstein.

 

I’ll take heckling over like lack of audience attention any day.

Hey everybody and welcome to episode 129 of the Ruby Rogues podcast. This week on our panel, we have James Edward Gray.

Good morning, everyone.

Josh Susser.

Good morning from San Francisco where the visibility is about 50 feet.

Avdi Grimm.

Good morning from Pennsylvania.

Katrina Owen.

Good morning from Denver.

I’m Charles Max Wood from DevChat.TV. And this week, we have a special guest and that is Ben Orenstein.

Hello from thoughtbot in Boston.

So Ben, you’re the host of a fairly popular podcast.

Wait! Don’t say that on our show. [Laughter]

Competition, man.

From a tiny little, barely relevant podcast.

Yeah, it’s the same name as the blog, right? Giant Robots Smashing into other Giant Robots?

It is. That’s right. We only have the ability to come up with one good name after a few years.

Chuck, you have to say it with the voice.

Yeah, you have to say, ‘Giant Robots’.

Giant Robots Smashing into other Giant Robots.

There it is.

Much better.

Man, somebody’s going to take that and make it a sound bite on their phone.

[Inaudible] it’s an amazing name.

Sorry, Ben. You were saying? [Chuckles]

Oh, we have the ability to come with one good name per decade or so. So, we just use it for all our things.

So, you’re about due? Is that what you’re saying?

No. Giant Robots was the name of the blog for a long time. And so, when the podcast came around, we’re like, “Eh, we’ll call it that, too.”

Yeah.

I beg to differ, because you come up with good names for every single one of your podcast episodes.

Well, thank you.

Very good.

We’re fortunate to have people listening as we record and they sort of jot down different quotes from the episode and then we snag one of those and make that the title. Whatever the weirdest thing that gets said during the hour, is generally what ends up as the title.

We tried to come up with an interesting title two weeks ago for an episode. We were all joking around and throwing out random ideas. And Mandy couldn’t tell if we were serious or not, so she just went with a tame title. So, that tells you how bad we are at coming up with interesting titles. [Chuckles]

The problem with pulling those quotes though is that it’s hard to tell what the episode is about. And people complain about that every once in a while.

Yeah, good point.

So anyway, by way of introduction, you host the Giant Robots Smashing into other Giant Robots podcast. You’ve also spoken at various conferences about refactoring and those talks have been excellent. I know I’m missing something. [Chuckles] So, go ahead and fill in for what I missed.

Those are the big things. So, I work at thoughtbot in Boston. I run our Learn program, which is us turning around and taking the things we’ve learned as professional Rails consultants and teaching it to other people, mostly sort of intermediate and advanced Rails programmers or people that are looking to get their first Rails jobs or build an app on the side. So, I started off as one of our consultants and now I’m running that side of the business.

Oh, cool.

So, I’d like to add a few things. Ben is one of the few people who are able to do live coding well and entertain the audience at the same time. And so, if you ever get a chance to see Ben live code, you should go do that. Drop everything and go see it. Another thing that Ben does is that he’s very good at Vim and he helps other people become better at Vim.

Thank you. That’s much nicer than me having to brag about those things. It’s better to have you say them.

That’s actually one of the reasons I asked Ben to come on the show today. I have seen Ben live code in two talks now. Also, I watched your PeepCode episode that you did.

Cool.

And both your GoGaRuCo talk and the PeepCode episode, you gave hints of this underlying strategy you have of tool sharpening. And I found it really fascinating. So, that’s why I asked you to come on. In the GoGaRuCo talk, you didn’t go into it as much. But one of the things you did was you showed us this long list of history in your show. Then we were talking about the various items, because it’s obvious from your history that a good portion of it, maybe 90% or so, are these shortcuts you’ve built. You want to talk about what you do there and how you do that?

Yeah, I’d love to. I’m a huge believer in the power of habits. I think the things you can manage to make yourself do regularly can have incredible results. And so, a few years ago, I’d say five years ago, I decided to get kind of serious about making my environment really excellent and improving my efficiency that way. And so, I got in this habit of spending the first ten or 15 minutes of my day on tool sharpening. And so, what I started was I started a little text file that I would add to during the day. So, when I was doing something that felt inefficient or felt like whenever I had that inkling, “There must be a better way of doing this,” I’d add it to the list. And then I’d pull one of them off in the morning. And so, I started most mornings by just doing something simple like making an alias for a command I use in the shell a lot. Or something like, I finally need to research how the Vim expression register works and go do some diving on a readme or something like that. And I thought of it as sort of slowly sanding down the rough edges of my environment. So, anything that kind of like irked me, I would try to spend a little time on every morning. And what I found was not very long of this, I was noticeably faster at the things I needed to do every day. And it was starting to have a huge impact on my productivity. And so, I started talking about that. Even in my first talk I

ever gave, which is at RailsConf about Vim, I started talking about, and I recommended that people keep a tool sharpening list. In a little text file is fine, in a little thing next you your computer, but just something where you jot down the annoyances, the rough edges that bother you. And then try to build a habit of tackling a little bit of that every day.

That’s awesome. I do that too, a lot. And I really love it, too. Interestingly, when I talk to other people about it, a lot of times they seem ho-hum about the idea. And the complaint that gets thrown back at me a lot, and perhaps you’ve heard this one is, “I like to leave my environment just the way it is so that when I go to another environment, Vim will be exactly like that without my leader keys changed or anything like that.” They’ll be comfortable on any stock environment. Have you heard that?

I’ve heard that a million times. Pretty much every time I bring this up, someone says that. And I guess you have to weigh the pros and cons, the benefits. To me, I spend a lot of my time on my own machine. And the changes and optimizations I’ve made have sped me up substantially. In a way, it’s some of my secret sauce, I think. It’s probably why I’m so fast at certain things. My vimrc at this point is almost ten years old. It’s got ten years of improvements in there. And that’s actually pretty huge. And so, if you are constantly on other machines and constantly pairing with other people and you really, really value that portability, then maybe it is worth more to you to stay on a completely stock setup. But I doubt it. I think for most people, it’s just an unwillingness to start doing these customizations. I think most people would be net better off by working on improving their environment more. But I will say that I do pay the penalty, which is I’m lousy to pair with. Everything is remapped. I have all these custom things that are now completely burned into muscle memory. So, when I jump on someone else’s setup, it is really hard for me. It takes me a long time to kind of get into the groove on their system. So, there is a small downside there.

Have you been competing in the national competitions? [Laughter]

There is a Vim derby, isn’t there?

Is there? I didn’t know about this.

I don’t know, but this is amazing. Keep talking. [Chuckles]

I found that the Internet rarely lets me down. So, I bet if we Google for something like ‘Vim competition’, we could find people who are racing their Vim setups.

There could be. Although for me, I don’t claim to be the fastest person in Vim period. It’s just that for the way I work and the order I typically open files and the way I jump between them and the edits I typically make, I am pretty fast. And that’s really what it’s all about. It’s about customizing your own workflow, not just sort of a general workflow.

Yeah. And I think it’s good to point out this isn’t always about speed, too. A good example I ran into just the other day is I have this Rails app where it’s meant to be started up with Foreman because Foreman brings up the app itself but it also brings up memcached, which it uses for some caching and stuff like that. But I always forget that when I go into it and I’ll just use a shortcut to fire up the Rails server and then I’ll start using the app and I’ll realize memcached isn’t there and that’s why it’s behaving weird or something. So then, I got smart the other day and I realized my shortcut for firing up Rails could be smarter. So, I went in and tweaked it and now it looks for the presence of a procfile when I fire it off and if there is one then it starts up Foreman and if there is not, then it does the standard start up the Rails server thing. And now, I just don’t make that mistake anymore.

Absolutely.

So, one of the really interesting things here is, to riff on what James said, it’s not about speed. It’s going back to what you said earlier Ben about anything that irked you. It’s the rough edges. It’s the annoyances. It’s the thing that takes your mind off of what you’re doing.

Right, exactly.

I was actually going to say that a different way and that is it’s about flow. And if you can stay in the flow, in the groove, while you’re working, then you get more done. You feel more satisfied with what you did as opposed to when you have those interruptions. Even if they’re small ones, it breaks that flow and it interrupts the way that you work. And that’s really what it boils down to usually for me, when I optimize something like that.

Totally.

So Ben, do you actually choose which tools you use based on how easy they are to customize?

Hmm. I don’t know if I explicitly set out with that goal. I got lucky in picking Vim a long while back and finding out that it’s insanely customizable. But I haven’t thought about that for new tools so much, except to think that I almost could never leave Vim because of how great it is for me now.

Josh, I was going to say no, because he would have picked Emacs. [Chuckles]

I do envy Emacs for certain things. If I could program my editor with Lisp, I’d be really happy.

Well, there’s a way to do that. [Laughter]

Yeah right, if I could program my Vim editor with Lisp.

You can do that, too. You just go into Emacs and then turn on eval mode, I think it is, [inaudible] it’s basically.

Okay. So Ben, I asked that question because I remember when I used to program all the time in Smalltalk, all of Smalltalk is there within Smalltalk, including the development tools and the compiler and all that. So, you can go in there and change almost anything you want about the development environment. I used to build custom extensions to the development environment to help me do whatever programming task I was doing. And I’m curious if you ever do anything like that in Vim where you have some programming task that you keep doing over and over again on a project and you just put together some extensions or some tools, basically build a custom tool to help you do your work.

I don’t know if I’ve ever done that to a level where I would call it a tool. But I do make small customizations in my vimrc for things I’m doing a lot on projects. One thing I do is I embrace my typos. Sometimes I come across a variable that shows up in my app a lot that I just cannot type correctly and I’ll just do an alias for the incorrectly typed version to the correctly typed version. [Laughter]

I actually do this a lot. So, I’ll make little things like that. And if I have one-off tasks for a project, I’m pretty good at writing macros. I’m usually reasonably aggressive about using them when I have to make a bunch of changes. There’s a little bit of an art to writing a macro that you can just replay a bunch of times. It’s like writing a little generalized procedure for text editing. But once you get the hang of it, you can use them to do some pretty impressive things.

Gary Bernhardt is pretty big on this particular point. If you watch his Destroy All Software videos and stuff, he talks about it some in there. But in a project, he will just map leader keys in Vim on the fly. Like I’m doing this thing a lot where I bounce over and run this test or something and so he will just define that as leader key there while he’s working.

Yeah, I do that to save myself during pairing, because I have a few leader commands that I use constantly. So, when I jump on someone else’s setup, I’ll often map a couple of leader commands right there, just for my favorite couple of things that are almost impossible for me to get out of the habit of using. It’s like a little shim.

[Inaudible] inspired me to finally bite the bullet and enter an automatic spelling correction for intialize.

So, I can’t type initialize either. I have a thing that expands to that entire method, actually.

Yeah. I think I should do that.

So, I can’t type initialize so I spent an hour and a half practicing. [Laughter]

So, that’s interesting.

All valid approaches.

Two different approaches to the same problem. The difference is Katrina’s approach actually makes her a better person. [Laughter]

There’s a meditation in practicing typing. But that gets down to flow. So if you want to stay in flow, you can eliminate your mistakes or you can embrace your mistakes. So when you practice typing something correctly, you can eliminate that mistake. I sort of embrace that, “Hey, my fingers want to type initialize incorrectly all the time.” So, let’s just say that’s okay and figure out a way to get around it.

And think of all the time you’re saving by not practicing. [Laughter]

You could use that time to make yourself a better person in other ways.

By not becoming a better person yet. [Chuckles]

I know another thing you do Ben that I’ve seen in your talks and PeepCode and stuff. When you have something that you want to re-train, you will define the alias for the wrong version and make it not do that thing but tell you what you should do instead.

That’s right. So, I have one of these typo situations where instead of git push I would type git pusa over and over again. So I said, “Okay, well this is dumb. Let me just map git pusa to git push.” So I did that for a while. And I was like, “Why am I typing such a long thing all the time?” So, I re-aliased that to g push. No, so I wanted to go to gp eventually. It was my final destination. I was like, “Okay, let’s do two characters.” Only I kept typing my old alias which was gpush, one word. So then, when I realized I wasn’t using gp, I had gpush just echo “Use gp” and then actually call gp itself. So, I got a little reminder every time I use my wrong slightly longer alias.

This is actually a really good habit. When teaching other people, when they do the long version, I try to make them do the short version afterwards three times in a row. And one of the things that I

do in Vim is I disable the commands that I don’t want to be using anymore. So, if people come on my computer, I’ve disabled escape, I’ve disabled backspace, and I’ve disabled the arrow keys. And I’m working on maybe disabling hjkl.

Wow, nice.

There’s big value in that. And this is something I recommend in basically all my Vim talks, which is when I’m trying to learn a new command, if I realized I’ve missed an opportunity to use it, I’ll back up and then redo it using the correct command. Because the thing you’re trying to build is that muscle memory. You’re trying to build that automatic, “I want this to happen therefore my fingers just do the right thing.” And you don’t get that if you don’t actually think, “Hey, I need this to do this,” and then experience it happening with the right command.

I’m going to stress the value of disabling things. I don’t know why, but for a long time I was like, “I shouldn’t be turning things off,” but I’m way over that now. And I realized it is so great, especially if you’re an Emacs user or something. In Emacs, absolutely every single key does 50 things depending on which modifiers you hit it with. So, if you ever mistype something, it actually does something and it’s horrible. So, I run into that all the time. And I’ve just gotten in the habit of now if I mistype it and I do something, I’m like, “I would never want to do that,” I’d just go shut that off.

Right after this call, I’m going to go disable capital Q in vim.

Oh yeah. I actually did that probably a couple of years ago and it was a great decision. Are you talking about the capital Q in normal mode or in command mode, like :Q?

No, just capital Q.

Okay, I don’t even remember what that does anymore. I think I killed it [inaudible] long ago.

I have no idea what it does. All I know is I have to type out the word visual to get out of it.

That’s right. It switches to x mode.

Nice.

Yeah, I got rid of that. That was one of those eliminate mistakes ideas.

There was something I hit in org mode one day in Emacs that literally means something like, “Take half my file and go hide it on my hard drive somewhere.” [Inaudible] [Laughter]

When I give Vim talks, I always tell people don’t use the arrow keys. That’s one of the main commandments of Vim and people will call to me afterwards and say, “But how do I stop using the arrow keys?” And my first reaction is, “Well just stop doing it and don’t ever do it again starting right now.” I sometimes don’t understand why people need extra help on that. But what I say is, “Hey, if you really can’t get yourself out of the habit, then just re-map them.” So, some people I know will map them to nothing, will map them to no ops. And other more trollish friends of mine will map them to random directions. [Laughter]

The last time I tried to use Vim pairing with someone, hitting the arrow keys would say, “Oh, hit the j key. Hit the K,” which made me furious.

I’m like, “You know what I want to do. You won’t just do it. Shut up.” [Laughter]

Okay, so Ben, serious question. Do you have any way of prioritizing the things that you’re working on? Like you said, every day you just work on some stuff to improve your environment. I look at the field of things that I don’t know and determining the things that I want to level up on can be really daunting sometimes. There’s so much out there.

It’s basically sorted by agony.

Okay. [Laughter]

Like on Hipmunk, yeah.

Exactly, exactly. If you haven’t used Hipmunk before, it’s a service for searching flights and their default sort is agony, which I think is great. And agony is a combination of how long your layovers are, how long the total travel time is, how much it costs, and it folds in a bunch of different factors. And that’s what my sorting is by. It’s just this general sense of what’s going to give me a good payoff because I do it a lot versus how painful is it when I have to do it manually. It’s a combination of a few different things.

So, you’ve talked a lot about aliases, bash type aliases or shell aliases and also improving your Vim configuration. What other type of tool sharpening activities do you do?

Not enough is the answer. I’m trying to get better about this. I’ve written a lot of Ruby over the last couple of years and I’m okay at it. I’ve written a lot of Rails apps in particular, so I’m getting the hang of Rails in general, but I haven’t forced myself into a wildly new programming paradigm in a little while. So I’m trying to be better about this. I’ve been dabbling around with Clojure and a little bit of Elixir and I have this goal of giving myself a couple of different projects that are wildly outside the realm of web programming. So I want to build a little interpreter or compiler or something, maybe some sort of graphics programming and just peel off one or two projects that are really different than what I do every day to force myself out of my comfort zone. I’ve actually planned a retreat for myself in February. I was on Twitter lamenting that I haven’t read all of SICP, the Structure and Interpretation of Computer Programs, which is what MIT uses to teach its computation classes. And I was lamenting. I was like, “I can’t believe I haven’t read this whole thing. It’s like the bible for writing programs.” And Chris Hunt who’s someone I know from some conferences, works at GitHub, was saying, “Oh man, I had to Google what that was.” So I was like, “We should totally just get a cabin and go read that book for a couple of weeks,” and he’s like, “I’m in.” So in February, I’m going. We actually ended up choosing Costa Rica. And we got a place near the beach and we’re going to basically bring the book and not come out until we’ve read the whole thing and done a bunch of exercises.

That’s awesome.

And I’m hoping that will jump start my learning.

So, we’ve moved from sharpening tools to sharpening skills. Do you find that that is a graduated scale?

I don’t know if I understand what you’re asking?

When we talk about sharpening tools, I think about the tools that I use to write code but not my understanding of programming or my ability to write different languages. I think of those as two different things. Do you think of them more as the same thing?

That’s a good question. I don’t know. I haven’t pondered it actively. At the end of the day, it’s like how good are you at getting things done with code when you want to? So I think the tools are part of that and if you improve the tools, you’ll be a little faster for certain reasons. And if you improve the wetware of your brain by becoming a better programmer and having knowledge of more techniques and things to try, that probably also helps. So, I think if you consider it as you have one end goal which is working software that does something, I think it is just a continuum.

That makes sense.

It really adds to your understanding of things, too. just whipping open an editor and making it do something different, once you’ve done that you get a new appreciation for how does this thing work and what can I make it do when I really want to, or things like that. And that information, you go forward with that information. In the future you may decide, “Well this is a new little mini-language I’m using, so maybe it makes sense to write a grammar for my particular editor so that it can syntax highlight it correctly,” or things like that. It expands your thinking a bit. I did an automation one time. I have it tab complete when I’m doing ssh commands or scp commands when I’m copying a file off of a server. I went through and made it work so that I can start typing a directory name and I can tab complete it on the remote server. And it was neat to figure out what was involved in that. Obviously, I have to make some kind of connection and get a listing of the files at that point and filter it out. It was cool.

Yeah.

I think that this process of beginning to make the world around you conform to what you would like expands in a grand way where you start seeing yourself as someone who can affect the world. And it becomes a lot more than about your tools or about your skills or about figuring out how to write a script. But seeing that, “Oh, this thing out there in the world doesn’t work the way it should or it’s too painful or it’s too complicated, and I can fix that.”

Hmm. That’s interesting. I think I’ve always had a healthy disregard for the way things are “supposed to work”. I’ve always been a little bit of a disruptive force in the organizations I’ve been a part of. When people are like, “Well, we don’t do it that way,” or, “No, it has to be like this. You need permission from that person,” or something, I disregard that pretty wildly and frequently. So, I guess it’s not shocking that I feel that way in my tools. I feel that way in my code. I feel that way in organizations I’m in. That’s just a general mentality, I suppose.

So growing up, the world seemed completely random and arbitrary and accidental to me. And it’s only in the past, I don’t know, since maybe I was about 30 that I feel more in control. So, it’s completely new to me.

You talked a little bit about the organizations you’re in and things like that. Do you find that you do some of this tool sharpening, not necessarily with the tools that they’re using but with the organization itself, with the team or things like that?

Oh, yeah. I try to. I don’t have a lot of patience for things that seem foolish or slow or just could be improved. I’m very fortunate to be at thoughtbot which is a company that really, really embraces changing processes for the better. There’s almost no resistance towards change. If you can make a reasonable case for why it will be better, which is really an amazing thing. But I’m reasonably frequently a person that will try to make some change happen when it seems like something is broken.

Have you ever been in a situation where you need to make a change happen when the organization around you doesn’t really encourage that?

Absolutely. I had a nightmare of a first programming job. It was a wonderful job in the sense that they took me with no experience and were willing to train me and gave me that first credential of has worked professionally as a programmer before to get me on my way. But in pretty much every other sense, it was awful. So for instance, they gave everybody 15-inch monitors or 13-inch or some tiny screen. And being a developer, if I have more screen real estate, I will really be faster. I will make you more money if you buy me a bigger monitor. So, I made this case and was turned down. I said, “Okay, well you’re making the completely wrong decision but fine. What I’m going to do is go out and buy my own.” So, I went out and bought my own and said, “Okay, I just want to let you guys know I bought my own monitor and I’m going to be bringing this in.” And they said, “No, you can’t do that because if you do and it catches on fire, our building isn’t covered by that insurance policy so you can’t even fix this yourself.” And there were a lot of other examples like this where the process was what the process was and they really, really didn’t want anyone to disrupt it. And I was completely miserable. And I almost got fired from this job. And I thought at the time it was because I was a really bad worker or I was really lazy or something. I felt really bad about it. But when I think back on it now and I look at what I’m able to do today, I think it was really just that I was extremely unhappy because I had no ability to shape my environment and it just completely sapped all my motivation and happiness.

So, was the right solution to leave the job?

Absolutely.

Do you think there’s a middle ground somewhere?

I think in companies that aren’t so pathologically averse to change, then absolutely. I wouldn’t tell everyone as a blanket statement that if you’re unhappy because your job has some bad processes, you should quit. But sometimes, that is the right answer. I think maybe on average, people are a little too afraid to try to change processes where they work. I have a lot of friends that will tell me, “I can’t go over there and get this promotion because this VP hasn’t approved it,” or something. And my experience with the corporate world has been if you know the right people and you push in the right way and you make enough noise and you’re valuable, you can often get what you want even when it’s not officially allowed. And I think a lot of people don’t quite realize that. And they don’t try to challenge quite hard enough.

I’d like to push back a little bit on that. I think that this thing that you said that was if you know the right people and know the right buttons to push, I think that’s absolutely valid and absolutely true. And I think that you might instinctively or not or somehow through your training know those things. And for people who don’t understand, like I don’t understand people very well at all and I tried to change the first organization I worked at and it was a disaster. I probably used all the wrong techniques and I ended up begging and crying basically and throwing fits on the floor practically trying to get this place to change. Of course, in hindsight, of course it didn’t work because I didn’t know the leaders to push. How do you get better at pushing the right leaders?

I think you just start small. It’s harder to change certain things. So I think you start with little stuff.

And then you work your way up to the bigger things you want to ask for. I think that’s probably the best way to do it. For instance, the one I think a lot of people screw up is it starts with your salary negotiation. So it starts before your first day at the job. I know a lot of people that are offered X and they say, “Great, sounds good,” and then they sign and that’s it. And if I could convince every person in the world that ever takes a job to just answer that with one thing, it’s, “Well, I was really hoping for X plus whatever,” anything that you feel comfortable with, and just see what they say, I think people on average could be making a lot more money. And so it starts with little things like that, just being willing to negotiate and push back just a hair every once in a while. And then you build up to the bigger things.

I’ve seen that some organizations have a higher tolerance to that kind of behavior than others. It’s like you said, that first nightmare job where they just couldn’t deal with that at all, and I’ve worked at places like that, too. I find that in general, the smaller the place, the higher the tolerance they have for people wanting to change things.

Yes.

So, it’s one of the reasons I like small places. Much easier…

Yes, I found that as well, for sure. And again, like you, I prefer smaller companies, primarily for that reason I think.

One of the things with smaller companies is that they’re not getting everything they want done anyway, so if you’re finding a way to get something done, they’re just going to thank you for it.

Yeah, that’s a good point.

They also tend to have fewer codified policies and procedures. If there’s an employee handbook that officially spells out something, once they’re like, “Okay, we’re a grownup company now and we need an HR department and we need to have policies in place to handle all the scenarios that come up,” that’s when I think you tend to find the most resistance to change because it’s like, “Well it says right here in the employee handbook that no, you can’t take a month off.” But when you’re in a smaller company, they haven’t had that parental oversight come in and so you just go talk to the CEO who’s one level removed from you, or maybe two, and say, “Hey, I want to do this thing,” and they say, “Well, okay. We haven’t done this before but that’s fine.”

I saw it on TV, so it must be true. [Laughter]

I’ve found that there are just companies where maybe they have their own process and whatever, but it just doesn’t fit me. I just do it a different way. In one particular case, I tried to adapt to that system and really just couldn’t. It was just a bad thing. They had their way of doing things and I just couldn’t make my system fit that way. So, we ended up parting ways, which was fine.

Right. And it’s important that that was fine. I think people, they tend to not try to improve things enough. I think they also tend to not quit enough. There are so many jobs out there and there are so many different companies that have different cultures and different ways of doing things that I often see people struggling to try to make something work that is probably never going to work when the company and you would both be happier if you went and did your thing somewhere else.

I think a lot of people have a fear of letting go of that job and they probably shouldn’t.

So Ben, I want to tie what you’re saying to how Katrina was approaching it earlier. When you’re in a tough situation, you can either move to a different situation (improve the situation) or improve yourself. So when you’re stuck in a job you don’t like, you can either fix what’s wrong with the job, you can quit and go take a different job, or you can change something about yourself, maybe it’s learning a new skill or what have you. And I think depending on what’s up in the whole situation, one of those choices is going to be better than the other sometimes. So I think that quitting is a great thing to do in a lot of cases, but it’s not like the, “Oh yeah, I just want to quit this job.” [Chuckles]

But I agree, people don’t consider it as an option as often as they should. But there’s that whole, “Okay, do I work on this situation or do I work on myself?”

Yeah, that’s a good question.

[inaudible] choice there. And I’ve been in job situations where it’s like, “Okay, I’m having a real hard time working things out with this coworker or this department or whatever,” and find that if I just adjust how I do things a little bit, it removes all the friction and we can just go forward. So I think that the tool sharpening, it’s great at the technical and the scripting and the tool use level. But there’s also stuff you could do at the organizational level and process and interpersonal. Even things like, “Hey, let’s use something like Pivotal Tracker in this project,” which can change the focus of what you’re doing from, “Oh, I’m trying to bang on JIRA to get it to work right,” to, “Oh, now I’m not wasting all the time on that. We can actually spend more time talking about the issues that we’re trying to solve.”

Absolutely.

I like it.

It was a little rambling, but [Chuckles]

I want to go back to sharpening tools, as in software tools. We talked a lot about the command line. We talked about text editors. We didn’t really talk about your operating system or graphical tools that you use and things like that. So do you find that you’re sharpening those tools as well? Or is it mostly focused around your programming tools?

That’s a good question. I do a little bit of operating system sharpening. It is honestly mostly focused around my editor and shell because that’s where I spend a lot of the time. But as a web developer, I do also flip over to the browser. So I use a tool called Alfred which I like a lot which lets me keyboardize more of OS X. It’s like Spotlight on steroids, so there’s just more things you can do from the keyboard. You can program a lot of shortcuts into there. You can add some sort of macro capabilities in there that are pretty fancy. So that’s a big thing. That was a nice win for me. I also use something called SizeUp which lets me manage windows with the keyboard, like bounce them around and resize them. And I also use Vimium when I’m in Chrome. Is it Vimium? I think it’s Vimium, yeah, that lets me basically use Vim keyboard shortcuts for moving around. I guess this is all around the keyboard. This is my one guiding mantras is I hate the mouse.

It’s just pretty much always

Must be a Vim user.

Exactly. And if you don’t hate the mouse, that’s fine. Btu you’re definitely wrong because it’s just so much slower than almost anything else for almost every, it seems slower than the keyboard for almost every single task.

[Laughter] That’s fine, but you’re wrong. I love that.

[It’d be] okay to be wrong.

Yeah, I use tools like that. I use LaunchBar instead of Alfred and things like that.

Yeah, so Ben, I have one example of something where the mouse totally beats the keyboard. One of the things I love on the Mac is I can go into a terminal window and I can start typing. So I can type some command like wc, word count, and then I can go into the window for the document and drag the icon from the title bar into the terminal window and it will type out the full path to that file so that it can operate on that within the terminal. CHUCK: Neat trick.

That is a neat trick, but can you imagine a much faster workflow for that with an Alfred shortcut, like two keys kind of thing?

Yeah, there might be something like go find the topmost window and pull the title out of it. Yeah, you could do something like that. I could see that. But that doesn’t exist out of the box. So it’s very much like, “Okay, am I going to go with the flow or am I going to build something?”

Right.

I think that there are a lot of people who have your kind of mindset of, “Oh my god, the keyboard is great. I’m just going to power on and that’s going to be my approach.” And that’s totally fine. But I’ve been using the Mac since 1984 and I’m extremely good at using the graphical UI in the Mac. And there are a lot of very subtle things in there that you can explore and level up on much the same way that you can on Vim key bindings. And I can do some pretty surprising stuff to a lot of people. Wait, that didn’t parse right. [Laughter]

Can I quote you on that?

Apparently, yes. No, I do stuff [inaudible] course using the Mac that a lot of people find surprising, just because I worked at Apple for many years and learned all this stuff and how to do it. I wish there were better guides for doing it because some of that stuff is really slick. But enough of that. [Chuckles]

Yeah, there definitely are some mouse tricks. The thing for me is I view going to the mouse as a [cache miss]. It’s like my hands are already on the keyboard and now I have to move them all the way over to the slow part of the world. Like I’ve gone down to disk-[Laughter]

That’s awesome.

And actually physically grab another thing and move it around. [Chuckles]

But my hands were already on the keyboard. So if I could have done this with the keyboard then this would have been faster. I would have saved that travel time.

Yeah. Well I’ve got to say, the moment when I can get two extra arms installed, so I have two hands on the keyboard, one on the mouse, and one holding the phone, then I’m great.

What if you use your toes on a track pad?

So back in the day when [Southerland] was doing all this research and stuff, they experimented with a device called a foot rat. And it was like a mouse but for your foot. And they found the precision was not great enough.

So I use a very fancy keyboard called the Kinesis Advantage which is actually great. I totally recommend it. It’s a split keyboard. It’s got some interesting design decisions in it that make it more comfortable to use. Most notably, it moves things like backspace and escape and enter all down to your thumbs and that’s really handy. But it also has an option to add on foot pedals, which is awesome. So you can plugin optional pedals and put those on the ground. I haven’t actually done that yet, but I really want to. And you can map macros to them. So I really want something that’s like I just stomp on a pedal and it pushes to production. [Laughter]

Some alarm goes off and a siren flashes.

I was working with David Brady on a contract and he broke his arm and he’s a pretty avid Emacs user and he was trying to find ways of – he got some foot pedals, basically, to compensate for that so that he could use them as control and whatever so that he could get his work done.

Yeah, I think we haven’t hit the limits of human ability to control these things. Foot pedals plus a little voice control plus both hands, I think we can be folding this all together into something pretty awesome.

Yeah, we should put a steering wheel on the computer, too.

Why not?

It’s got an accelerometer. Just pick up your laptop and twist it around.

There you go.

So we’re talking about hardware. Do you have any other hardware or physical tool hacks that you do? Ways that you sharpen your tools in the real world?

The most important one is I work at a standing desk at home and we have standing desks here at thoughtbot. I think the best tool sharpening is not sitting all day, because sitting is the slow death. Anything that gets you moving more is better. So when I’m sitting, I sit in the Aeron which I like, has nice support, has a keyboard tray to get my hands a little bit lower so they’re in a comfortable position and that keyboard is easy on my hands. I had some RSI issues a few years ago, which was really scary. And I actually delayed taking my job at thoughtbot because I was battling these issues and I was worried I was going to start my first day and be, “Oh, I can’t program for a couple of weeks, you guys.” So I started getting really serious about my setup. And that’s when I made those changes. Keyboard tray, Aeron chair, good keyboard. Recently added in the standing desk routine. And those have all been really good. Because the most important tool is your health. You’ve got to keep that sharp. If you’re sick or hurting, in pain, you’re not going to be able to do good work. So you’ve got to really stay on top of that stuff. And it’s so much easier to instill good habits and to try to be healthy now than to try to erase some nasty damage you’ve done by a few years of bad habits. So even if you’re not feeling these pains or worried about those right now because you’re 20 and it doesn’t seem like a big deal, I’d encourage you to try to get in good habits early and never have to worry about it.

What kind of a standing desk do you have?

I use a GeekDesk.

Okay.

Which is great because it goes up and down. Because standing all day isn’t awesome either. You want to be able to alternate between the two. Or at least I do. That’s what works best for me. So I mix between bouts of each. Very happy with the GeekDesk.

Yeah, I just ordered the Lifehacker IKEA $25 deal. [Chuckles]

Yeah, I’m sure that will work, too.

I figured I should try it at $25 before I go spend several hundred dollars on a standing desk.

Yeah, that is the – yeah, go ahead.

I was just going to say I totally agree though, that if you don’t feel good, if you’re not taking care of yourself, it really makes a big difference.

It’s amazing how nothing else matters to you once you are not healthy. You don’t think about your health when you are healthy. It’s just almost completely invisible because you just wake up every morning and feel okay. But when you wake up every morning in pain, suddenly almost nothing else is relevant. And you have to get that emergency solved. So it’s totally worth being proactive about. Because it completely eclipses almost everything else. [Chuckles]

What shoes do you wear at your standing desk? [Chuckles]

Oh, that’s actually an awesome question. So one of my picks is actually a pair of shoes. Can I talk about it now?

Yeah, go.

Okay. So I recently bought a pair of shoes. The brand is VIVOBAREFOOT. JOSH: Dude.

I love them.

Oh my god. I searched your pick page and no one has mentioned this before. So I’m going to claim that I’m bringing this to your audience first, even if you have talked about it before. So basically, imagine if you live in, if you live in San Francisco, you can wear those Vibram FiveFingers and people will not think you’re completely crazy.

Not true.

Okay. Fewer people will think you’re crazy. You can pull it off a little bit more in San Francisco. If you live in Boston and you wear those five finger things, it’s like, “Eh, okay. That guy’s clearly a programmer. Probably writes Lisp.” [Laughter]

So if you want that similar idea of a low profile sole and no arch support and a very flat heel, then you can get them. But you can get them in things that look like normal dress shoes. And that’s what VIVOBAREFOOT does. They make sneakers, but more interestingly to me, they make nice looking shoes that have incredibly thin soles. So I switched to these a couple of weeks ago and I am totally in love. The theory is, look, you are an incredible machine that has been evolved over billions of years and you are designed to have your heel flat on the ground and your foot already has shock absorption, and it already has balance structures and it has support for your arch. It has everything you need and all the stuff that modern shoes give you is wrong and should be avoided. And so it’s like a seven millimeter patch of rubber that you stand on and nothing else. And it just lets your foot do its thing. And it’s already changed how I walk, which is crazy to me. I didn’t realize I was doing what they call heel striking. It’s not normal to drop all your weight on your heel as your stride moves forward. It’s more natural to place your foot down in a more balanced position and spread the weight out. But when you have shoes with thick heels on like sneakers or dress shoes, that’s the position you take. You start heel striking. So I have this as part of my gait. And I switched to these shoes and suddenly I’m slamming my heels on the ground and I can suddenly feel it for the first time. I’m like, “Wow, this is all messed up.” So I’ve been relearning how to walk, which is not something I thought I’d say at 30. But I’m totally happy with them. I feel better after wearing them. And when I stand all day in dress shoes versus when I stand all day in these shoes, it’s marked difference. It’s vastly better.

I think you actually hit on a key point there. How you changed your shoe and that is actually changing how you walk. I view that with the whole tool sharpening thing, that as I dig into these processes and stuff and it has that trying these automations that I find new ways of leveraging things. I realize I no longer have to make this mistake where I forget to fire up Foreman instead of the Rails server because I have a habit to just go through this automation anyway. So if I just make that automation smart enough to make the right decision, then it just changes how things work.

Totally. So yeah, get those shoes. They’re awesome. And no one will know. That’s the most important thing. [Laughter]

You look completely normal, which is great. Although I keep hoping someone will notice how nice my stride looks now and comment on it like, “Wow.” [Laughter]

“That’s a really nice stride you have.” But that hasn’t happened today.

So Ben, I did actually notice that. [Chuckles] But I got training to actually pay attention to that. When I learned massage therapy, I suddenly started noticing how everybody walked. It’s a very weird thing. Yeah, so you start with your shoes and you end up with your programming. [Chuckles]

Little things. We had a whole episode on coding environments where we talked about the things that weren’t writing code but the stuff that was in support of them. So I think that there’s a fair amount of overlap between that episode and what we’ve been talking about today.

Glad I could duplicate your previous content. [Laughter]

Expand on, expand on.

Okay, yes.

Yeah.

Okay, so Ben, what is the most terrible hack that you’re most proud of in your tool sharpening business?

You can [inaudible] but it might get him in trouble with the law. [Laughter]

I’m going to be a bit of a politician. I’m going to rephrase that question to a question that I’d rather answer, which is what’s the lamest thing I’ve done that I’m most proud of, which is my favorite remapping is I had mapped ctrl+S to the escape :w enter. So I basically gave myself a little save shortcut in vim. Leave insert mode, write the file, hit enter. And I calculated that one time. I think this saved me about a million keystrokes per programming career. And I use it, I don’t know, probably 500 times a day, maybe more. And it’s a stupid thing where it goes from escape :w enter, four keystrokes to two. But those two keystrokes get repeated so often that the savings is actually monstrous. And when you’re thinking about RSI like I am, saving a million keystrokes is a pretty big deal if you want to be programming when you’re old and gray. So that’s one of my things that I remap instantly when I’m on someone else’s computer. I just say, “I’m sorry but I have to have this command,” and then I just map C+S to that. And they’re usually okay with that.

Yeah, I think we determined before that you’re the kind of guy who comes over to visit and turns the toilet paper roll over.

Yes. Somebody heckled me with that during my talk.

I think that was probably me.

Yeah. [Chuckles]

But that’s accurate. The problem is you’re doing it wrong so I will help you. [Laughter]

The cool thing in this process is that you’re always measuring. You talked about how that keystroke felt natural to you, but then you’re like, “So how many keystrokes will that save me?” And I noticed in your GoGaRuCo talk you’re like, “Let’s sort my history by occurrence and stuff to see how often am I using these commands,” and stuff like that. I think that’s awesome that you have this built-in metrics analysis system.

Wow. Somebody should write a profiling tool. Like we have the profiling tools, statistical profiling where they’re just checking where your code is every millisecond or something. We could do the same thing for what we’re doing with our tools and see where we’re spending the majority of our time so that we know where to focus on.

Totally.

As opposed to just being a gut feel.

Absolutely. So I have a command I run in my shell that basically pipes history and does some awking on it and does some sorting and things like that and shows me my 10 or 15 most-used shell commands. And I use that to see what I need to be more aggressive about aliasing. Like what am I typing out fully often that I don’t need to be? I don’t know of a thing like this for vim. I think Drew Neil who’s the creator of Vimcasts has started to work on this. I don’t know if he’s released it. But something that watches what you’re doing in Vim and records it and tells you, suggests optimizations that way. Because that would be handy to know.

Yeah.

That is cool. It’s a neat idea. So you just use that command and if you have something that’s sneaking into the top ten that’s a command you’re manually typing out, then that gives you the hint that you should automate that.

That’s right. Because that’s where the most value is, in things you’re doing a lot and are annoying to type, are clearly the biggest wins.

Yeah, Josh made a pick recently for this program called Dash, a documentation viewer. And it has all these different modules you can get. Say you can have your Rails, your Ruby, your jQuery, your JavaScript documentations all in this one search bar and then you mentioned Alfred and you can install the Alfred plugins so you can literally just call up Alfred and I have it map to just an m in front of it for man. So it can just do that. And I picked it up after Josh mentioned it and was playing around with it. I can’t believe how quickly that changed things for me, just having all that documentation in one place and not having to Google it or go to the particular site that I cared about or whatever.

Yeah. That’s actually right at the top of my list. I’ve had a thing on that for a while saying I need to get better local documentation. Because I realized I couldn’t believe I was tabbing to my browser and starting a new thing and doing a search. I was shocked that I had done this for so long and then someone has recommended Dash just like Josh did. So that’s on my list of things to get going.

Check it out.

I just love it for if I’m somewhere without internet, I can actually still program because my documentation is accessible.

Yeah, totally.

Alright, well I think we’re pretty close to the end of our time. Is there anything else that we didn’t talk about that we should?

Ben, if we’re wrapping up, maybe you can say if you have any appearances coming up soon. Are you speaking at conferences?

Yes. Well I’m going to be at RubyConf. I’m not speaking. But I believe we’re going to be lugging our competing podcast equipment down there and hopefully recording some folks down there.

Whoa, whoa. Edit this out. [Chuckles]

I’m just kidding.

So if you write Ruby and are an interesting person and want to be on the podcast, then we should record you while we’re there. And then I’m giving my first keynote ever, which I’m really excited about, at Garden City Ruby in Bangalore, India in early January next year.

Awesome.

How exciting.

Yeah. So that should be fun.

That’s really cool. You definitely need to see Ben’s talks, especially the one you write live codes. I can’t agree with Katrina more. I fall apart when it comes to typing and talking at the same time, but Ben, you just do it so naturally.

Well, thank you. My last couple of talks have not been live coding and I really miss it. I’m just not as happy giving a talk that’s not live coding. So I’m going to be going back to that. I’m almost certain my talk in Bangalore is going to be live coding.

That’s awesome.

Cool. Alright. Well let’s go ahead and do the picks. Katrina, what are your picks?

I have no picks.

James, what are your picks?

I’ve got a couple. First, we recently realized that we were just doing a JSON parse and a JSON, like two JSON in an app and it actually turned out to be a significant portion of time that we were spending in the app which lead us to looking to these other options. And it turns out there’s this pretty cool JSON parser and serializer for Ruby called Oj. And it’s crazy, crazy fast. So like I said, I wouldn’t say this is a normal case, but in our particular case, it turned out that the amount of time we were spending serializing JSON was turning out to be significant. If that’s the case, you can move to this sucker and it’s wicked quick. So that’s one. And then I have some picks for the parents out there. I read this cool article a while back about a parent who started their kid off on Linux in the terminal. It was really interesting. And then eventually they gave them startx and how they worked through that and their process and how it was very natural. I found it to be cool to read because it just made me think about introducing people to computers and what that can look like in maybe a non-traditional way, which I liked. And then we do this thing at my house where we trade off who gets to pick the movie that night when we’re doing a movie night. And my three-year-old gets to take turns and recently she picked ‘Cloudy with a Chance of Meatballs’. And I was surprised. It’s a really fun movie. I see lots of kid movies because I do have a three-year-old. But there were a couple of points in this one where I was actually cracking up and laughing out loud. So I would say it’s more enjoyable than most. So if you have kids, it’s a great watch. Those are my picks.

Alright. Avdi, what are your picks?

Well, I’ll start out with a topical pick. I was just poking through the picks and I noticed that I don’t think thoughtbot Learn is actually on our list yet. And I know Ben mentioned it a little bit earlier, but I just wanted to second that their learn service has some really, really great material on it. They’ve got, I don’t know, articles, books, videos, and I’ve been lucky enough, they gave me access a while back to poke around and stuff. And everything that I’ve come across has been really top notch. They’ve got some great stuff on just like OO design in Rails and stuff like that. So learn.thoughtbot.com. Ben did not pay me to say this.

It really is good stuff. He’s doing some great work there.

Thanks Avdi.

I’ll give another topical pick. We’ve been talking about standing desks. My new standing desk arrived I guess about a week ago. I got the Kangaroo Hybrid Pro, I think it’s called, or the Kangaroo Hybrid. Basically the Kangaroo desks, they’re not full standing desks. They are desk toppers. So you put this big contraption on top of your desk and you mount your monitor on it, or in my case with the one that I got, you mount your monitor and your laptop on it. And it gives you two surfaces. It gives you a desktop surface and then a separate level for the monitor and laptop and you can adjust the whole thing up and down. and it’s pretty easy to adjust up and down so you just unscrew a big chunky screw thing and then you lift it up and it’s I guess pneumatically balanced so that it’s easy to lift up and then easy to push back down again. I’ve been using that for about a week now and I’m really, really liking it. there are a few nitpicks I have about it, but all in all I’ve found that I’ve been just naturally raising it up when I’m tired of sitting and pushing it back down when I’m tired of standing up and not really thinking about it that much. So once I got it set up, it integrated into my life pretty quickly and I’m really, really happy to have a desk setup that I can stand up at now very easily. So yeah, I recommend it.

Alright, Josh, what are your picks?

Okay. So I have some reading picks. One is years ago, Richard Feynman gave a talk called ‘There’s Plenty of Room at the Bottom’ where he basically put the idea out there of something that turned into what we now call nanotechnology. So he pretty much created the whole field in this talk. But based on that, a science fiction writer named Hal Draper wrote this very clever short story, It’s only a couple of pages long, entitled ‘MS Fnd in a Lbry’. And it’s a cautionary, hilarious tale of what can happen when your internet search technology gets out of control and the dangers of corruption, index corruption. I guess we’ll leave it at that. So fun reading. It’s amazing how many people still talk about ‘MS Fnd in a Lbry’. And it was written a really long time ago. So that’s it for me.

Alright. I’ve got a pick. It’s something I’ve been trying lately. It’s called The Secret Weapon and you can find it at TheSecretWeapon.org. Basically it’s a GTD or getting things done system using Evernote and your email. And so far, I’m really liking it. There are a few things that I’m probably going to tweak on it. But for the most part, it’s been really interesting to give it a shot. So I’ve actually been sticking with it longer than I’ve stuck with any of the other systems that I’ve tried to use. So I’m excited to see where things go from here. But anyway, that’s a pick. I know we’ve picked Evernote before, but I’m just going to mention that again because it is such an awesome tool. Ben, what are your picks?

So I have one more pick to share. Last night I started assembling a bookcase that I had bought from IKEA and to keep me entertained while I was doing this, I started watching a talk called Narcissistic Design by Stuart Halloway who works on Clojure and Datomic, their database. And the talk was so good that I got so absorbed in it that I actually build the bookcase wrong and had to destroy it, taking it apart, and I’m now waiting on replacement parts from IKEA. [Laughter]

That’s awesome.

Yeah. It is basically a backing that goes on that I installed completely flipped and nailed it in with about 20 nails and then stood it up and was like, “Oh, okay. Well that was a waste of time.”

Best endorsement for a talk ever. It’s so good I ruined my furniture.

Yeah, really good talk, really good talk.

Awesome. Alright. Well, we’ll go ahead and start wrapping up the show. One thing that I do want to mention. We have a silver sponsor and that is Elixir Sips and you can find that at ElixirSips.com. Basically it’s like Ruby Tapas, short videos on Elixir instead of Ruby. So, if you’re interested in learning Elixir, it’s a good way to go. And with that we’ll wrap up the show. Thanks for coming.

Absolutely.

What’s our book club book next time or in a few months?

Functional Programming for the Object-Oriented Programmer by Brian Marick. And I think we’re going to do the episode on December 18th and there is a code to get you $5 off. And I don’t remember it off the top of my head. It’s something like please remember the starving artist. But we will get it in the show notes. So, take a look there.

Alright. Thanks for coming, Ben.

Yeah, absolutely. It’s my pleasure.

Alright. Well, we’ll wrap this up. We’ll catch you all next week.