Adam Keys from LivingSocial joins the Rogues to talk about the tradeoffs between working for a company on their product and being a freelancer or consultant.

Special Guest: Adam Keys.

 

How is your tattoo feeling there, James?

It kind of hurts. Thanks!

Hey everybody and welcome to episode 121 of the Ruby Rogues podcast. This week on our panel, we have Avdi Grimm.

Hello!

Josh Susser.

Good morning.

Katrina Owen.

Hello.

James Edward Gray.

Good morning.

I’m Charles Max Wood from DevChat.TV. And this week, we have a special guest, Adam Keys.

Hello there.

You’ve been on the show before, Adam. Do you want to introduce your self anyway?

Sure. I'm Adam, I'm from Texas. I currently work at LivingSocial and work on Sifter app on the side. I've only been a consultant for like four months of my life. So, there.

[Laughs] Is that a good thing or a bad thing?

It was a discovery process. I learned that I liked just working on a product more than doing all the other things that consulting work entails.

That’s kind of funny actually. I was wondering if you were going to say it was the worst four months of your life. But for me, I think it’s almost backwards, like I love the constantly seeing new things and stuff like that. So, I never feel like I'm bored and stuff.

Hey, maybe we can start with a definition. Like, what is a consultant?

What is a consultant? Yes.

What do you mean by ‘consultant’? It could mean a lot of things. You know, Sherlock Holmes was a consulting detective. [Chuckles]

And of course, when you compare that to the Enterprise Scotland Yard, you can see who was the more effective at getting the job done.

Yeah, but let’s face it. Sherlock Holmes was lame compared to Morty Yardy who was basically a consulting bad guy. I mean, that’s so much cooler.

[Chuckles] Okay, fair point. But Adam, what do you mean when you say consultant?

A consultant to me, having only been a consultant for a few months, is someone who’s moving between projects somewhat regularly. Usually, with a smaller scope of work to do and often is broadened based on their previous work, what they're known for, and kind of sometimes, with a scope that they're there to rub off on the people around at the place where they're consulting.

So, some examples of -- you can consult freelance but there are also companies who basically provide teams of consultants such as Thoughtbot, Pivotal Labs, Hashrocket.

Yeah. When I started thinking about trying to break this down in my head like working on products versus doing consulting work, it occurred to me that there's build shops like Thoughbot, like Pivotal, et cetera. And then there's two or three person outfits that are closer to consulting. I might not even write codes sometimes. I just come in and say, “Your code is great. Keep going.” Or, “Your code is terrible. You need to change these things.” CHUCK: Is there a distinction between a consultant and a contractor? Are we making that distinction?

I'm actually probably not a great person to make that distinction because like I said, I've only done it for five months.

I would say that contractor is a wider set of which consultants are a part of.

I think they are usually used synonymously in our segment of the industry.

Yeah.

Mostly. It seems like the only real distinctions made is if you call it like an agile consultant who’s coming to help you with your process or your team as opposed to a contractor who’s going to come in and actually bang out some code.

As far as I can tell, contractors are those people who tear up your dining room floor and then dunk shot for work for two weeks.

Have you met my father in law?

I swear you're talking about the same person.

Adam, what you're saying is there's differences between these people that do consulting work, largely us Rogues, and people who do these other kinds of work that you're talking about like product work and stuff, right?

Yeah. There's a difference in perspective and goals when you're working on a contract versus when you're working on a product or set of products. Not too much on the long term, but until you start working on another set of products, a more open-ended time scope.

What are some of the main differences?

I think the crux of the biscuit is that with product work, there's always more to do. There's always something that needs to be fixed, something that needs to be improved, a report that needs to be written. And with consulting work, it’s kind of the scope is smaller and a lot of the goals, I think, are more focused around ‘can we get paid’. I can, Adam Keys Incorporated, invoice this guy now that I've written this amount of software. Does that make sense?

Yeah. It sounds like you're talking about the difference between, are you writing to make the product great in the long run or are you writing to solve the immediate problem that’s in front of you.

Which is cash flow.

Good point.

Yes or no.

That’s a really good point. A consultant is a business and a product person is not so much a business. And so, like I said, I didn’t like having to do all the hassle stuff of promoting myself, nailing down contracts, meeting people, scaring up new business, and that’s all business stuff. Whereas when I'm doing product work, I only have to think about the product. I might think about how the product fits in the business but I don’t have to think so much about sales, marketing, stuff like that.

That middle ground of working for a consulting firm though is, I think, in a lot of ways the best of both worlds there. When I worked for Pivotal, I never have to deal with the business acquisition; you're bringing in clients, negotiating contracts, dealing with lawyers, any of that stuff. I just show up at work one day and there would be a new project for me to work on. And I’d sit down and start writing code.

I want to jump in here though because everybody kind of has a different thing that they really enjoy about whatever it is that they do. So, Adam was pointing out that he really didn’t enjoy a lot of the marketing and business running things. And it’s really interesting to talk to him about that because I kind of do it as far as the marketing goes. Now, doing my books, yeah, there are things I would much rather do. But for the most part, running the business is an interesting challenge in the same way for me at least, the writing code isn't. So, I think it really depends on what you want to get out of your job and whether or not you want to own it as to whether one or the other, or something in the middle makes sense.

Black, can I just say black?

I second.

Which black? Black what?

[Chuckles] I hate that business stuff, yuck!

So, did someone handle that for you?

No, I do it. [Laughter]

So, I feel qualified in saying ‘I hate it’. But the good thing is I guess I’ve just gotten to the point where it’s not much of a hassle anymore. It’s fairly easy for me to get clients now. I guess I just have enough experience and word of mouth. And I get much longer contracts these days so I work on bigger things for longer periods of time.

One other thing I want to talk about is the point that you made about making the product better versus trying to get paid. And to be perfectly honest, yes, they are two different problems. But I found that it’s much easier to stay in business if you are trying to make the product as good as you can.

[Laughs] Okay, good point.

Because the client is more likely to engage you for longer. And the other reason is you're more likely to get referrals if you do the best you can.

Okay. So, Katrina had a good point that as a consultant, you want to get paid and that’s really the problem that you're dealing with most of the time.

Cash flow, yeah.

But the point that I was trying to make is that the technical challenges that are in front of you as a consultant are very often more short-term focused than someone who is a product owner, they're going to be at a company working on a product for two, three, four years or more sometimes. And I think that that gives you a different outlook on how you write code.

Yes, that’s true. They're also usually a little more specialized. Anyway, go ahead.

I mean, there's like a lot of stories like one of the things that consultants are infamous for is coming in and writing code and just like banging something out and then writing off into the sunset and leaving a pile of un-maintainable code.

[Laughs] I've seen this. It’s true.

We all know that movie.

We’ve all been the sequel to that movie where they hired you to come in and maintain the unmaintainable code. “We don’t know what this does. We don’t know how to deal with it. We need somebody to come in and make sense of it.” Yeah.

I think the distinction to me is that when you're working as a product person, you might have short term forces that make you put a thermal exhaust port somewhere where a snubfighter can shoot at it.

That’s a very bad idea, by the way.

[Chuckles] There's a really great documentary about that.

Yeah, but you can just set up a bunch of blaster turrets to provide the impenetrable defense and then it’s not a problem.

Right. And you send your own snubfighters in to pick them off if all else fails, right?

So, what we’re talking about is technical debt, not the product.

But when you're a consultant, someone’s just like, “Fix the problem. The reactor’s too hot. Put a thermal port on the outside and we’ll put some guns around it.” When you're a product person, (a) you can take a longer-term vision and work that person over and be like, “Yo! We can do this.” But it’s really a bad idea and do that once a week for five or six weeks until they give in. Whereas with, my take on consulting was yeah, the tight rope to walk on that was a lot trickier because you're walking, you're like, “I want to get paid but I also want to tell this guy it’s a terrible idea.”

So, that’s an interesting point you just made there. There is like, I've worked with lots of different consultants and actually some that I think are really good. Actually, the ones who do go back to them and say, “You know, you don’t want to do that because…” And here's a better idea that gives you 80% of what you want with way less energy or whatever. And I actually am particularly bad at this, not because I'm looking at the money or anything like that, but because I hear somebody say, “Let’s build a thermal exhaust port.” And I'm like, “Oh! That sounds awesome, I want to do that.” Like the technical challenge, “I have no idea how we’re going to do that but I also want to try it.” And so, I don’t think to analyze well, “Is this a good idea, should we put this in here?” And I think that makes me not as good as some of those things as other people who do go back in there and you really don’t want to do this. So, I guess my question to you is, are we sure that is the definition of a consultant? Are we sure that the consultant who doesn’t push back, like the product guys would push back, doesn’t that make a better consultant?

I totally think that makes a better developer for sure. It just seemed to me when I was doing it, pick your battles even more wisely, at least the first one, to figure out if this is a thing that you're welcome to do or not institutionally.

I talk about this stuff every week on another show.

[Chuckles] Yeah.

And there's something about this conversation that is just driving me up the wall. And I really want to make the distinction between good consultants and bad consultants. Because the good consultants are the ones that are going to go in, they're going to do the job, they're going to do it right, they're going to give the customer the most value for their money. And ultimately, the nice thing is (a) you can pick clients most of the time anyway, unless you're absolutely desperate which is a bad place to be. But you can pick clients that are going to listen to you, they're going to follow your expertise, and you're going to save them more than they spend on you. And the other thing is a good consultant really understands the fact that they have to be looking toward the next contract, not the current contract. So, the current contract is a means to an end. It is a means to get paid, and it is a means to get referrals for your next contract. So, as long as you're doing a terrific job for them, they will pay you. And as long as you're doing a terrific job for them, then they will give you referrals. And if you break either of those rules, then you are basically aiming to have to scramble for a contract and that’s a place you really don’t want to go. And so, it really depends. There's a wide range of contractors. I mean, there are guys that do Rails work for $40 an hour, and they do a crappy job. It takes them ten times as long as the guy that does it for $100 an hour. And these are the kinds of people that we’re talking about here. They're so strapped for cash that that’s all they worry about. But then you get the other guys that maybe charge a little bit more, $150 to $200 an hour. And they come in and they do incredibly good work. They're happy to train the developers in the company. They're happy to answer any questions and solve any problems and do whatever it takes as long as that company is willing to engage them.

So, let me [inaudible] in terms of not good versus bad consultants. What about if your team’s been hanging out in Camp Fire and doing their thing there, or maybe IRC is a better example since we won't have Hubot as a [inaudible] example. You’ve been hanging out in IRC, that’s how your team communicates. And you decide, “Oh, I want to whip up a quick IRC bot for this channel that does some niceties for us.” Is the product company or the firm that has you consulting more likely to say, “Yeah, go ahead. Take a few days and whip up a little IRC bot.” [Inaudible] different terms.

I’d like to continue off of that a little bit. At product companies, I feel like I'm allowed to spend ten hours experimenting something, whip something that might make the product better. Or is it when I'm doing consulting work, that’s just not an option. I have a goal. I’d have to fight to make those ten hours immediately worth the cost to them.

This goes into another area. And this is important for people who are in the career somewhere or not. But you have to communicate. And in a lot of cases, if you're going to go on experiment with something for two or three hours to figure out whether or not it’s going to pay off for the project, that can wind up saving the client some money. And so, again, if you communicate well about what you want to experiment with, why you want to experiment with it, what the payoff could be for them, a lot of times they’ll go for it.

Most of the time. In my experience, most of the time [inaudible].

Yeah. I think you're oversimplifying there, Chuck. I mean, if you’ve got a cash cow or product that exists and it’s bringing you in money, and one of the employees comes to you and says, “I have this idea about this feature we could add and it’s probably about ten hours of work on my end. And I think it might do this, this, and this for us.” If you're already comfortable in the position where you're making money and this has the potential to improve the product but neither one of you really know if it’s going to take off. Is it going to be that feature that everybody loves and uses or is it going to be that thing where one person uses it and it’s totally not worth it to maintain it or whatever. You don’t really know but it’s not too hard to take that risk. You’ve got your money coming in, you're okay. Potentially, it may make the product better. If it doesn’t, you end up [inaudible] it down the road and it’s not super big deal. Whereas in a consulting firm where you're trying to push that product and get it there and I’d say, “I've got this good idea that maybe I need about ten hours of side work,” that’s a much different scenario. That’s pushing things back and slowing things down.

It really depends. I've had clients that take you up on it and clients that don’t. But ultimately, if you at least communicate that and communicate the potential value of it, then they can make a decision based on whatever criteria they have.

Maybe we can try a slightly different tangent here. My impression when Adam said he wanted to come talk to us about this stuff was that we’re going to talk about being a developer and how being a developer is different if you're working in a company during a long-term product development project or if you're running around this hired gun consultant. I'm curious if there are actually differences that we’ve all seen, like how we approach writing code, what code quality is like, if there's differences there.

One thing I noticed that I thought was really great when I was consulting that I tried to carry through is like Charles touched on, you really have to turn the communication up to 11. It’s really easy especially in product teams to just go off in your cave and code, work tickets, fix bugs, write features, and never talk to anyone. And actually, people build careers on doing just that. He’s the guy in the cave who just does a bunch of good enough work and we let him do that. But mostly, people can't get away with that and have to talk to each other. I found that I had to do that even more when I was consulting, and that helps me in my product work.

That’s a great point.

I think that the approach to responsibility and accountability that you take for your work as a consultant, it’s I think a bit of a paradox where in some ways, you're more accountable and more responsible for your work because, “This is exactly what they're paying me to do and this is my [inaudible] product.” The other side of it is like if you're there at the company and it’s long-term, you have to live with it. You have to live with the results of it more so that the accountability follows you around more. I don’t know if this is making sense but it seems like what we’re talking about is basically the responsibility for writing good code and making sure we’re doing the right thing.

Putting a twist on that, are consultants and such more likely to do things like speak at conferences and form panel discussion podcasts because they’ve developed those skills necessary that they have to work on those skills? Communication is more important to them.

Or self-marketing is more important.

[Chuckles] Yeah.

I can speak to this a little bit as far as the panel podcast go. Obviously, this podcast is mostly made up of consultants. The JavaScript Jabber podcast, there is one consultant, the rest of them are all company guys. Well, they're all guys so I can say company guys, but they're all developers that work for companies. Freelancer Show, they're all freelancers. The iPhreaks Show, I think we have two developers that work for dev shops. However, those dev shops, they take contracts and work contracts.

I’ve watched a little of that Food Fight Show, the Chef one we had Nathan on awhile back. And they talk a lot about Chef. But most of those guys have steady jobs at companies like Mozilla and OpsCode and various groups. So, I would say they're more product people.

Yeah. And if you go and look at like This Week in Tech and those shows, I think it’s a good mix there too.

I think a lot of that is actually a second order effect. When I was a contractor, I had a lot more agency over my time. So, if I decided to take two hours off in the morning, I’d ask permission from no one. Whereas it’s very easy when you're a company person to think that between 9:00 and 5:00, if your butt’s not in a company chair, then you're going to get a demerit which is often not the case. But it was really hard for me to get myself out of that train of thought.

I just want to second that. I really did not feel free to do a lot of the stuff that I do now until I became a consultant.

Yeah.

I had some good jobs that were fine with me blogging from time to time. I don’t know if they knew how much of the blogging was done on company time, I think they did. And a lot of it was stuff that I discovered on the job and they were okay with the exposure. But a lot of the communication stuff, the education stuff, the conferences and podcasts and things like that, I really did not feel comfortable doing that while I was full-time employed. The thing was if I took two hours off to write a blog post or do a podcast or something like that while I was freelance, yes I was losing money. But it was my money to lose. I could say, “Okay, I'm going to eat this time.” Whereas when I was full-time, it felt more like it was somebody else’s money to lose. Plus full-time work has a tendency to sort of expand and expand into all the nooks and crannies and become a lot more than full-time.

Sure, it’s really a good point.

Let’s talk about that for a minute how they tend to expand because I've seen freelance businesses do that too.

Freelance does it in a different way. I usually don’t see the work itself expand out into more than full-time but that’s because you have all these sort of side stuff, business stuff you have to take care of in marketing and lead-finding and stuff like that tends to ensure that you actually wind up working fewer than 40 billable hours. But the thing is some of that marketing and stuff is the fun, writing a conference talk and stuff like that that you otherwise would feel, “Oh, I can't do this because I need to get that widget finished for my day job.”

That’s a fair point.

When I was doing consulting, I found that I could only do 30 billable hours a week or else I would be dead. But there was a lot more non-billable hours that were needed to keep things going to talk to people, find leads, promote myself, et cetera. And in that way, you expand it.

That’s a very good point. I hope everybody understands that. If you work in an office, just because you punch that time clock in at 8:00 and you punch it out at 5:00, that doesn’t mean you spent 40 hours sitting in front of a computer, doing programming. Last week, I did something like 44 hours of actually billed programming time. And to me, that was way too much. [Chuckles]

Oh, yeah.

That mental stack you have to build up and keep it there; maybe if it was really simple programming, but this is kind of hard stuff. Yeah, I don’t typically bill 40 hours and that seems to be the difference like us consultants, we are expected that if we bill that hour, we were [inaudible] or writing code. Whereas in the office, you'll get up and take a break and go down and talk to the person down the hall for a little while and things like that. And we end up putting in about the same amount of programming hours.

I think it might be interesting to talk a bit more about the pressures specifically on the development process, freelance versus full time.

I was just going to say I have a pretty good example there, I think.

And I suspect different people have had different experiences here. My experience is that I feel like full time, it’s a little easier to get into the rot of ‘this is the way we’ve always done it’. It’s a little easier to go down that road of technical debt where it’s like, “Well, we’ve never had a passing CI build so, we’re not going to start now.”

[Chuckles] Why is it a big deal?

And, “This method has always had 13 conditionals in it so, why does the 14th matter?” And I felt like as a consultant, I was mentally freer to bring in kind of a fresh perspective and a fresh energy to say, “No, this really isn't good. Let’s fix this and make it better.” I think most people are familiar with having that energy at the beginning when they move to a new job and they might be able to exercise it. Or if it’s one of these places that has a really engrained culture, it might be squat quickly. But the nature of consulting is that you kind of get to bring that energy to the new projects over and over. Whereas when you're just at a day job everyday for a couple of years, you stop even seeing the issues that have always been there and that nobody has had the energy to change.

Yeah. I think, to me, a lot of that is about culture in agency, like products over time develop a culture. Like you said, “We’ve never had a passing suite, so why start now?” That did also like having a feeling that you can take two hours off and do a podcast or having the feeling that you can stop and say, “Hey, I'm not going to add another method to this god object. I'm going to delegate to some other object that I want to create today. I think those are more tied to the length of the project. So, projects that is of culture, not jobs, kind of. So, a long-running project like you do with product work is going to have these problems. Does that make sense?

Yeah, it makes sense to me.

I personally have found that though I haven't done very much product work. But I personally have found that consulting wise, things can change more often. Like just recently in the job I'm working on, we were going down X path, working on many things. And then, all of a sudden, there was a media opportunity for the product we’re working on. And it was like, “Uh-oh, if this product’s going to get some media attention, then these X things we’re working on right now are not the most important thing to have done at this particular time. So, let’s shift tracks and go work on this userfacing stuff,” basically because the media event will have more users poking around with it and there's just a bunch of niceties that we could clean and make nicer for them that would be good. Whereas this infrastructure stuff can wait as we bring these new pieces online and stuff. And I find that I see that we have to react to outside forces that are happening more, I think.

Yeah.

I think a lot of that depends on who’s leading the project and what the product owner’s philosophy is, like the culture you embedded in. There's always a bigger context, no matter what level you're in. So, I find that while we can generalize about that stuff, I think the variations tend to dominate more than the generalizations. How’s that for generalization? [Laughter]

It’s mostly right.

Thank you. In Physics, we used to say that the error bars were very large.

A very specific thing that I noticed when I'm shifting from doing in-house product work to doing consulting. I was at Pivotal for about four years and worked on a lot of different projects. And I found that over time, I developed a very different kind of attitude to how I was writing code. And one of the things that was part of the culture at Pivotal was sort of the antithesis of the, what I mentioned before, consultants are infamous for leaving a pile of un-maintainable crap behind when they leave the project. The culture at Pivotal was exactly the opposite of that. It was that when you work on a product at a company, it’s going to be your job for years. Often a way to deal with technical debt is, “We don’t have to think about how to solve this problem now because I’ll be here in two or three years and if someone has an issue with that, I’ll just deal with it then.” So, you can just infinitely defer stuff into the future. Whereas our attitude at Pivotal, and this is the attitude that I carry around with me now all the time is I'm writing code that I want someone -- if they ran across this code six months from now and I'm no longer on the project, the code should speak for itself. And therefore, it should be easy to maintain even though I'm not around. And I found that that was just a really powerful perspective shift and I find that when I myself go back and look at code that I

wrote that way and it’s a year later, I can deal with that code much more easily now.

Yeah, that’s really kind of part of the point I was trying to make earlier with this is something a good consultant, somebody you want to hire, does. And it really is a terrific practice to have.

But I think that there is that sort of safety net or implied safety net when you're in a big company, you have “job security” and you're going to be there for a long time, or at least that’s assumed, that nobody pressures you to make those kinds of tradeoffs in favor of maintainability. “Okay, yeah, we’ll just deal with that one when we ran into that problem.”

I've kind of seen it cut both ways, not really dependent on product versus consultants. I've seen really good code written like [inaudible], like you're saying at Pivotal. I've seen really unrealistic code written by consultants. And I've seen just, I prefer to call it cutthroat code written by product people who are just getting stuff done as fast as they can. And I've seen people who are working on a product that have a sort of, who have resume-driven development or who have a wrap for moving slower in the cutthroat but trying to write that good Pivotal-style of Pivotal-quality code that you're talking about, Josh. If anything, I don’t think that is a determinant of product versus consultant. Although I do think there's more cutthroats in product work which would be interesting to come back to after Katrina says her thing.

Actually, that’s where I was going. I spent two and a half years at a startup where it’s definitely a product company, there's no doubt about that. But it wasn’t making money. And so, there was a really interesting dynamic. It was not in Ruby so there was also a very different culture in that sense. It was very cutthroat. Everything had to be done as quickly as possible and usually for very odd reasons. We were pleasing some random VC that was going to come into the office two days later and we had to have some feature that that person randomly wanted. Or there was a media thing that was going to happen and so, the priorities were just shifting all the time. Because everything was an experiment, most people didn’t care about how durable or how readable or how maintainable anything was which slowed us down tremendously very, very quickly.

Do you feel like that’s the reason why people are more cutthroat in product versus consulting because they're more, I don’t want to say prone, but they're more sensitive to that social pressure or business pressure from above versus consultants who are more independent and will just, “If you're not going to do this right, I'm gone.”

I don’t know. I think that in this particular case, because they were burning cash and not making money, they had a lot of pressure from sources like a company that is cash positive would not have.

Yeah, I think that’s true. I’d even had consulting contracts I worked on where the company is already making money and so, we’re good-better. These are the next things they're working and that’s definitely very different from the company that, “Alright. Here's how much money we’ve got before we run out of runway.” [Chuckles]

Here’s an experiment. When you guys have worked on contracts or consulting, if someone on your team committed code that was not a valid Ruby code like once or twice a week out of maybe 100 commits a week, would that person stay around or would they be fired or encouraged to stop doing that?

Are they consultants or are they full-time employees?

They work with you on the consultant side of the equation.

If we fired people for that, I would have been fired a long time ago. [Laughter]

The thing is I've worked at companies where people were writing bugs into the code, like explicit bugs. Like Ruby would throw exceptions and barf all over the place and yuck, yuck, yuck. The VM was unhappy with the code. And those people kept the jobs. I've seen consultants that do that once or maybe twice and they get let go. I think I'm kind of heading toward job security here. But ultimately, I think these companies are less prone to fire somebody who’s a full-time employee than a consultant even for big mistakes.

I just want to interrupt that one thing and that is, I don’t think there is such a thing as job security.

Well, yeah.

So, we can talk about this a little bit. I think you're generally correct. However, if you let a consultant go, there are no repercussions on the business. If you let a full-time employee go, you have to pay unemployment and you have to blah, blah, blah, blah. It’s a little bit more of a hassle which is I think why they give them a little bit more leeway. But ultimately, yeah, if the company can’t afford to keep you, they’ll let you go. Some companies, if you really are screwing up, they’ll let you go.

And even though there's no real job security because [inaudible], they can fire you anytime they want. I think the big difference in attitude for ‘I'm working on a contract that has a three-month contract, so I'm only going to be working on this three months’ versus ‘I'm working at a full-time permanent position where basically I can stay in this job as long as we’re both happy’.

Yeah.

And so, I think it’s not like, “No, I can never lose this job.” It’s the, “if things go well, I can stay at this job as long as I want.”

[Inaudible] it’s the difference between The Prisoner’s Dilemma and the Iterated Prisoner’s Dilemma.

You really need to explain that.

Right, go.

No, I want to hear it.

Yes, go ahead.

In the Prisoner’s Dilemma, you have two players and they can choose to cooperate or they can choose to defect. If both players cooperate, they get say three points. If both players defect, they get one point each. However, if one of the players defects and the other cooperates, the defecting player gets five points called the temptation. And the player who cooperates is known as the sucker’s payoff which is zero points. So, if you're playing The Prisoner’s Dilemma and you know that the other player is going to defect, it is in your best interest to defect. You both will get one point. Now, if you know that the other player is going to cooperate, it is in your best interest to defect because you're going to have five points and the other person is going to get zero points. In other words, it’s always in your own personal best interest to defect. However, if both players had cooperated, you would collectively do better. You get a mutual path that is higher. But this only holds if you know exactly how long you are playing, if you're playing one iteration or if you're playing unknown number of iterations. If you are going to be playing against the same player over and over again and you don’t know how often or how many times, if you defect, the other player can retaliate in the next round. And so, the motivation changes and you will be more likely to cooperate if you don’t know how long this is going to last.

Genius. I love it.

Interesting.

Doesn’t that kind of get into team building a little too? Are there interesting things about teams that you think you're going to work with for a short period of time versus teams you're going to work with for a long period of time?

Absolutely. If you want to maximize the potential for cooperation, you want to have people interact more frequently and closer in the future. You don’t want it to be a year off. You want it to be tomorrow or next week.

This got me thinking about technology choices too. Often, people or a company will hire consultants to come in and help them solve a particular problem. And sometimes, that’s a technical problem. Very often, I think it’s a technical problem. They want recommendations about technology choices, “Should I use my SQL or Postgres or MongoDB?” I think some of the time when you're part of the permanent team -- I used the term ‘permanent’ advisedly here. But when you're doing product work, you're on the thing for the long haul, you can advocate technology choices because maybe you're an expert in it and you can stay around and own that piece of technology. But if you're a consultant and coming in spending a couple of months on the project and recommending a technology choice, I want to make sure that this is something that if I leave, no one’s going to be confused about how it works. If I were a Haskell expert, I'm coming into a team and saying, “Oh, yeah. I'm just going to write this piece in Haskell and then walk off and no one even knows how it works. Yes, there's definitely a bad consulting thing to do. I'm not saying that that’s something consultants should be doing but I'm saying that it changes how, at least, I think about the kind of technology choices that I make.

That happens in product teams too.

Well, sure. I know but I'm wondering if there are substantial differences between how that works out, or if you should be doing things differently, consulting versus product. Anyway, sorry, keep going.

I think part of that gets to risk like when you're doing product work, is how you measure risk and reward different from how you do it on consulting work?

That’s an interesting thing. And the reason is because it seems like there are a lot of full-time jobs out there that are open. So, when you're measuring risk, really if you're in the mindset of ‘I'm going to work for a product company’, you're measuring it as ‘can I go find another full-time job’. Whereas with consulting, it’s really measured by how well you can sell your product which is effectively your ability to write good code to the next client. And so, I think the risk is measured. It depends a whole lot more on you in both cases. But in the case of a consultant, it really boils down to a specific set of skills that isn't necessarily a technical set of skills.

Yeah. It’s a social set of skills, is what you're saying.

Where getting another job, yes it does boil down some to that. But it doesn’t seem to be as critical because the companies and individuals view consultants and employees differently. And so, they measure the risk differently as well. And so, if they bring somebody in as an employee, then that just goes on payroll. Whereas if they're hiring a consultant, then that’s an expense they have to justify.

So, how about this. Let’s try hitting it in one more direction before we say we’ve exhausted [inaudible]. Adam, what things do you think consultants do regularly that have no place on the product team or vice versa? Or what things do one side do all the time that you think would be great to infect the other side, or whatever?

That is a good question. One of the things I'm really interested in is a distinction between iteration and long-term thinking and long-term architecture and design. And I think that product teams are probably a little better at iteration or skilled iteration and solving problems through iteration. And consultants are maybe a little better at longer term thinking. Or thinking in terms of, “Let’s just introduce a new component that will solve these three problems.” Does that make sense?

I'm trying to decide if I agree with that. [Chuckles]

Keep going. [Chuckles]

Could you iterate that argument?

The original question was, is there something that one side should be doing that the other is not doing.

Or is there no place for something on the other side?

Right.

I think everybody should be turning their communication up to 11.

I'm 100% agreeing with that. It’s actually like the killer skill of the programmer.

On a scale from one to ten, don’t you mean 110% in agreement?

[Chuckles] Yes.

When people ask me what I like about my job, I’d say, “Because it’s a people job.”

Yup.

Yeah.

That’s why great software turns out to be more about people than it is about [inaudible]. You eventually forget that out, hopefully.

[Inaudible] terribly frustrating. [Laughter]

On both sides of the coin that we’re talking about here, both in the product area and consulting area. It really is about people.

Most of the problems that we have in software is mis-communicated requirements. The more that you can communicate well and effectively, the fewer problems you have in your project.

Glenn Vanderburg pointed out to me that most projects that fail do so because of social reasons, because of people reasons not because of technical reasons. Sometimes, that’s requirements that weren’t understood. But oftentimes, especially in product teams, it’s longer term things where you have clicks that are interacting with each other properly or just people who are interacting with each other properly, people not telling each other important things. Yeah, people - can't live with them, can't live without them.

That’s a good point, people. I think that’s why I was hesitating earlier is I wonder if you're a good consultant and the best consultant you can be, then I think you're still planning for the future in a similar way that hopefully product people are planning for the future. And if you're a good product company, I hope you're still remembering to adjust to changes and [inaudible] stuff like the good consultants do when things happen. I think if you're the best you can be at those things, and then hopefully, you're bringing those things to the table from either side. Am I crazy there in thinking that?

One of the things I thought would be the big point of contention when we talked about this was that consulting work is a business, right? And you agree upfront that I'm going to implement X or Y for you. A lot of times, it’s a fixed contract. And Cucumber is a tool for fixed contracts. Cucumber is basically a tool where you get together with the customer, they write some stuff; you write some code that makes things turn green. And once everything is green, you can get paid. Thinking along those lines, I've been thin king, “Consultants are much less agile, lower case agile, in that respect.” And they're like, “Okay, I need to just get this thing done so I can get paid and move along.” Maybe you all write the best code of my life, but my goal is to get all these Cucumber tests green and then finish. Whereas the product team, it would be like, “Those Cucumber tests are stupid.” First off, product teams I find usually don’t need Cucumber. And second of all, teams would be like, “Those tests or those assumptions are all wrong now, or we found out they're stupid. So, we’re going to do something else.”

That’s interesting because I would almost predict the other way around.

First of all, I'm a consultant and I freaking hate Cucumber for starters. And second is like, in the consulting thing where we’re doing our thing, I feel like because we do things agile and iteratively, not necessarily because I see it as ‘if I get these to turn green, I get paid’. In fact, that almost seemed silly. I mean, wouldn’t my ultimate goal of solving the cash flow problem be, how many weeks can I get these people to keep me on board to pay me for the maximum amount before I have to go do those non-billable hours to get new clients? I'm not trying to do it that way. I'm trying to do it because people always have this grand vision and given this 500 programmers an infinite time will go build that. Since you don’t have that, we have to be realistic. And what we’re trying to do is limit scope to a manageable scale, in my opinion. And so then, we have to make those choices and react, I feel like more agilely and say, “Yeah, that doesn’t apply so we’re shifting this way.” That would be my response to that.

So, there's James Consulting and there's like the Lloyd Consulting. The Lloyd is just trying to milk, in many cases, say, company X that is a contractor for the CIA. They're just trying to get the CIA to spend as much money as possible. And say, “Okay, we did this thing. Pay us. We did this other thing, pay us.” So, it could be that we’re talking less about the differences between the product and consulting and know where the difference is between business models.

Yeah, I bought that. I think Katrina hit one good point is funded versus non-funded or things like that. There are many axes at play here as far as how people make their decisions and what their ultimate aims are. But I think we also have to be careful not to straw them in the other side and assume the best possible case of consultant the best they can and the best possible case a product company doing the best they can.

It’s interesting because usually, when I talk to people, it comes from a place of, “This has been my experience working for companies and this has been my experience working for myself.” And I find that talking to a lot of other consultants, it’s a lot the same. And so, there were certain things that really worked out well that they liked working for a company and there were certain things that they found unacceptable. And so, for one reason or another, they wound up moving into consulting.

I think that there's a different access to look at things on there and Adam talked about this before too in terms of, I think he used the term ‘agency’. When I've been an independent consultant and I was literally my own boss, they was nobody I reported to. I had to serve my clients as my customers but I was my own boss. That’s like a really easy way for developers to become their own boss. It’s a lot easier than going out and forming a startup company and raising funding and doing all that rigmarole. There's a certain type of person, it’s actually many people, it’s not uncommon, who don’t like working for somebody else and they want to be their own boss and make their own decisions about what they're going to work on and have their own philosophy about how they solve their problems and all that stuff. It’s so easy to just go freelance and be your own boss. And I'm not saying there are not challenges there. But it’s so much easier to make that happen than founding a whole company so that you can work for yourself. And I love that part of being a consultant, just like I love that part of running a startup company.

Yup. There's always the flip side though, and that is if you are your own boss, you have to do your boss’s job too.

Well, sure. I'm not saying there's no downside to that. I'm saying that if you want to be your own boss, that’s a really easy avenue to get into it. But the other thing is if you're one of those people who don’t want to deal with all that business stuff like James, then there's ways to do that as either working for a company on product or working as a consultant. You could go work for Pivotal and then they’ll take care of the business for you.

Yup.

I wanted to take on one more straw man.

Alright, let’s do it.

Light them on fire.

One of the reasons I brought this notion of product versus consulting up with James was that sometimes I notice people who write blogs and sometimes on this podcast, an assumption that everyone can be refactoring or ones that always do refactoring in TDD and whatnot. So, there's a straw man of the Ruby Rogues cohort, right?

You're not straw manning this time, I really believe that.

I've noticed that there's kind of the opposite kind of developer who’s also very valuable. Like for every Rogue on the team, I want this other kind of developer who I've started calling a grinder. And this is a person who is not up-to-date on all the TDD and mocking and distributed systems and whatnot. But they know enough Ruby and they know enough Rails to get work done and just blow through features, respond really well to deadlines. They basically get a lot done. But they are terrifying to someone on the other end of the fence, or on the other side of the fence because they don’t write tests, they work very fast, they deploy very often. And often, they deploy broken or syntactically invalid code. But they do it fast enough unless it’s like in the part of the system that launches nuclear missiles or accepts payments, you don’t really notice. And those sorts of people are really, really valuable. And I kind of wondered if those sorts of people end up in consulting jobs ever or if they're only ever in product companies because I've noticed them in several product companies. So yeah, there's the opposite straw man.

I find that grinders tend to be very productive at the expense of the rest of the team. So, the rest of the team doesn’t look productive because they are spending a lot of time cleaning up after the grinder.

So true. I've seen grinders being negative producers more than once because exactly that. The team isn't dealing with the problem that the grinder just caused a lot of time. A lot of times, they're dealing with the problem the grinder caused a year ago, this massive, massive monolith of code that they’ve turned out in an insane marathon session and nobody was looking over their shoulder at all. Then, the rest of the team spent months untangling it with management saying, “Why are you developers so slow?”

I have to say the only way I've seen this actually work where you have a grinder or two on your team is if you can put up a few fences and get them to mind the fences. And so, basically you put up the CI and it’s unacceptable for the CI to go red and it won't deploy of the CI is red, things like that.

So, they delete tests.

Yeah.

I'm not talking about a cowboy coder. I'm talking about something like a cowboy coder but a little different. A cowboy coder just doesn’t care. They're like, “If I introduce this feature, I get my bonus, I get my BMW. Life is good. So, I don’t care about your TDD, I don’t care about your CI.” This is different. This is someone who means well but maybe doesn’t necessarily understand the benefits. So, when I talk to grinders and I say, “Hey, you should write a test for that.” They're like, “Oh, I tried to but it has to talk to this web service and it’s going to always return different things. I didn’t know how to so I did.” And so he’s like, “Oh, you should use VCR and mock and stub classes to your own.” And they just look at you with glass eyes. And it’s really hard for me to explain to them all of these things that are second nature to us. So, they mean well but it’s like we can't communicate about code at nearly the same high level. But they're still extremely valuable to the team. If you tell me that I have to finish this feature by tomorrow, I can completely panic and can't think rationally. But a grinder is just like, “Okay. Maybe I’ll cut some corners or maybe I’ll just type this out.”

I would still pose it that their productivity comes at the expense of the rest of the team.

Yeah. Eventually, somebody else is going to have to pay that technical debt.

Sometimes, that grinder is good enough that what they contribute is worth the negative impact they have on the rest of the team. Being able to tell when that’s the case is really hard.

I think there are some programmers out there, I'm not sure -- I have to come up with a good name for them. But they are just really, really good. And they breathe the code and particularly, they are the rare programmer who is capable of holding the entire very large program in their head at once. I am not one of them. I have always said I am a programmer of very little brain. There are these coders out there that just can do a really good job really fast because they can hold the whole program in their heads. And they really can be a benefit to the team. Unfortunately, there are a lot more programmers out there who think they are that programmer and they are not.

I think Charles, he got through the thing that I think is the trick here. And that’s to give the nonRogues a system in which they can work. Like a fenced-off area in which they can do whatever they need to do to get user-visible features out the door quickly and iterate on them quickly while maintaining the stability of the core system. Though I'm still curious if these sorts of people turn up in build shops like Thoughtbot or Pivotal or if you see them about in the consulting community or if it’s just in the product world.

I have run into at least one in the consulting world. He was doing consulting thing and we both just ended up working on the same project. I've definitely seen one that way. I’ll reiterate pretty much about everyone you said that that person was effective, they built lots of features very fast, they can make changes and stuff like that. At the same time, there came a point when I had to go in and touch that code and then that was hard. Because first of all, I had to spend a big amount of effort to understand it because I didn’t have anything like tests or anything to guide me. And second of all, when I needed to make changes on it, I was just super afraid, “If I pull up this string, what else do I [inaudible]?” And I just didn’t have any kind of insurance and stuff like that so I worry about the net overall game. But yeah, I see what you're saying. Can we give them just this project and say, “You work on this project and that’s your baby.” But is that less for everyone? I mean, in my experience, one person working on one project forever in software, I don’t see that very often at all.

In consulting, I've seen a few as well. Usually, they fall into one of two categories, in my experience. One is the kind of the Cowboy Coder. Let me talk a little bit about that. So, they don’t really care. They just want to push something up and as long as the client doesn’t scream bloody murder, then they get paid. The other kind that I've seen is they usually work with somebody at the higher level that you're talking about. And that’s the person that can check them. So, they’ll come in and they’ll say, “Dude, you got the feature basically working but this here and this here and this other thing are unacceptable.” So, it’s interesting where they wind up but yeah, I feel like most consultants are more along the lines of the high level people.

I want to say that I run into them as consultants as well maybe I think usually as a Cut Rate Consultant. That comes in and charges half of other people do so they get hired and the boss just keeps throwing work at them and they just keep working late nights and getting it done. Which brings me to one other thing I wanted to say about the Grinder as it were. I also feel like they get kind of abused by companies whether as consultants, probably more commonly in full-time positions. I feel like they get kind of pigeon-holed and abused a bit because some boss at the company finds out that they can go around the team and go to this Grinder and say, “Can you get this done for me, this special feature that will wow some investors or something.” And the Grinder will do it and they will stay up all night doing it and they keep doing this. And there's almost a negative incentive for the business or at least for the boss to take advantage of this to socialize that Grinder, so to speak, to kind of bring them in. Maybe they don’t want to be that person or maybe they just haven't really thought of there being another way of doing things. I've talked to many programmers who work for years and years as programmer before they had an awakening moment when they realized that they wanted to do it. It could be a craft rather than just a grind. And that was a huge deal for them but they spent years as a Grinder. And I feel like there's this incentive in business to keep the Grinders as grinders and keep paying them crap and just relying on the fact that they will work their fingers to the bone without complaining.

I've noticed that Grinders are really bad at life balance as well. But sometimes, they're known secret weapons like several ones I've worked with. Management knew that this guy was your skunk works project guy when there's a short deadline or when everything was crumbling. They have this pretty strong sense of duty.

Alright. Well, I think we’ve pretty well exhausted most of the points that we could make about this.

There is a whole another podcast that I do about freelancing and that’s over at FreelancerShow.com. Let’s go ahead and get into the picks. James, do you want to start us off with picks?

Sure. I've got three [inaudible] and it’s all about chruby today. I use the RVM for a long time and I like RVM and I'm glad that it exists and I appreciate all the efforts that have gone into it. But it’s kind of gone in some directions that I haven't liked as much and I wanted to try something new by doing it smaller. chruby has a very different idea of how we should do Ruby switching. So, I went into a good blog post that kind of explains the differences on why they are important. And then, just chruby itself, it’s so easy to install. If you're a Homebrew user, you can just brew install chruby. And then, chruby just does the switching basically to install Ruby in directories and it sets up the environment such that you'll be using that Ruby at a particular time. So, you'll also need a tool to install Ruby into directories. And some people use ruby-build, I think, which comes out of the Ruby rbenv project. I have no experience with that and can't speak to it. But the creator of chruby also has a project called ruby-install which just does that, installs Ruby into directories. And so, I switched over to these a couple of months back now and I've been using it and loving it. I deployed a server this weekend and tried chruby in the deploying for the first time and that was great too. So, really liking it and if you want to see kind of some small, simple Ruby switching like a lot of us, I think chruby is worth the look.

Hey, James. I got a follow-up question for that. I noticed that RVM has like a mini RVM version of the project that is meant only to install Rubies, not to switch them. And the RVM site recommends that as one potential way to handle installing Rubies that you can then switch to chruby. I'm curious if you check that out or evaluated that versus this other options you talked about.

I didn’t. Now, I didn’t know it existed until just now. So, I don’t know if that’s another option. I do know a lot of people use ruby-build from rbenv. So, chruby definitely doesn’t care. If you just install Ruby in the directory, that’s really all it means as far as its switching. So, you’re totally free to try the ruby and mini-RVM installer thing you just mentioned or ruby-build or whatever. This ruby-install though, I can see it’s pretty great. I mean, like you just say which version of Ruby you want, many just did dependencies in installing things from Homebrew. I really thought it was cool, just right out of the box. I think it’s worth the look. But yeah, you can use any installer you want. You can build them by hand.

Nice. Avdi, what are your picks?

Let me quickly burn through a little of my backlog here. First of all, for years, I went through a WiFi router, a year it seemed like. They would just peter out and stops connections after a while. I don’t know why these pieces of hardware degrade faster than any kind of hardware I had considering that they're solid state, but whatever. Anyway, I asked around and I read the Wirecutter recommendation and I asked around and they all kind of agreed that the ASUS RT-N66u, otherwise known as the Dark Knight router was the one to get. So, I picked one up. It’s not the cheapest router. It’s like $150 or something but I have not had any trouble with it since. It’s been several months and everything in the house connects to it and it has great range. I'm finally not cursing at my router and having to reset it everyday. Next up. The other day, I needed to find out what the heck font somebody had used in some art that they did for me. And I used a tool called WhatTheFont and you can basically give it an image. You can give it a little bit of assistance in finding the glyphs in the image and it will try to identify what font they are. And it totally worked. So, that’s pretty cool. I will also say that you have to go and watch a video series called Ruby Ramen.

That is awesome.

Nice. Josh, what are your picks?

I have an oldie but goodie I'm going to start with. So, we had Tom Stuart on and we’re talking cellular automata as part of the Understanding Computation book we’re reading. I found a relatively old web page when I was reading the book and poking around looking for stuff. It’s all about doing The Game of Life in 140 Characters in a tweet and the blog post is by Phil Trelford, started off with the Game of Life in Ruby in 140 Characters in a tweet. I just found it really awesome. So, that’s a little mind-bending. What else do I have here? Kongregate, I still play games on Kongregate. I was [inaudible], I still play games on it. I found this amazing little game which is basically you debate the great philosophers of the ages to discover the meaning of life, or the basis of morality I guess is what it is. It’s a Socrates Jones: Pro Philosopher. It was actually super educational. There was a lot of stuff that I sort of knew about philosophy that this helped me get actually more reasonable view of things. So, it’s not a real quick play but it’ pretty fun, I liked it. And then, my last pick is data is awesome is basically how I'm characterizing this. Wired.com had a posting last week that took processing census data from the most recent census and turned every individual into a single pixel on a map of whatever area you're in, colored by their race. You look at these maps and it’s completely apparent, racial segregation by geography. And they have all the big cities of the [inaudible] and all the regions. It’s just amazing. Go find your city in it and take a look at it and you'll be surprised. Or maybe you will be confirmed. [Chuckles]

That’s it for me.

Awesome. Katrina, what are your picks?

I have no picks.

Alright. Well, I've got a couple. The first is a blog post by this guy I now named David Brady. It was Loyalty and Layoffs, really identified with it. Of course, I know most of the circumstances behind why he wrote it. And it was really, really interesting. So, if you're in a full-time job or not, you go read it. It talks about company loyalty and how it works and why it doesn’t make sense. At the same time, it did make me think about what [inaudible] all the company. And so, I'm kind of curious as to what people think about that. And you're welcome to Email me or tweet me or whatever and let me know what you think.

That is a fantastic post.

It really was. I don’t think I have any other picks right now. So, I’ll hand it off to Adam. What are your picks?

My pick is a website called Grantland. It’s an ESPN spinoff. It’s kind of sports and pop culture for people who like to read longer things like analyses. And so, they tend to cover in-depth about sports like they run a bunch of things on NFL play calling which I find intriguing. But also, they have recaps of shows like Breaking Bad or Mad Men. And then right now, they’re doing pop culture thing where they have the best songs of the millennium in a bracket format. So like, ‘Hit Me Baby One More Time’ versus ’99 Problems’. Who wins? And then, they’ll, by bracket format, determine what is the best song in the past ten years. So, that’s really cool. And a spinoff for that, I am ready for Professional NFL Football. And that’s it.

Awesome. Alright, we’ll go ahead and wrap up the show. Before we do, I want to just kind of announce and remind people of our next Book Club. We’re going to be reading Confident Ruby by Avdi Grimm. It took us a little bit…

By who?

Avdi Grimm, he was a real pain to book on to the podcast.

Describe him for me.

We talked to his assistant but that’s almost all I know about him.

She said he would do it?

Yeah, she said he would do it. We’re going to be reading it or we will be doing it…

I'm going to have to talk to her. [Laughter]

We’ll be reviewing it on October 16th. So, that’s plenty of time to read it. So, go pick it up.

And he gave a discount too.

He did?

I did.

Yes.

Oh, he’s here.

[Laughs] It is ROGUESCLUB, all one word, all caps.

Awesome. Anyway, we’re really excited. Several of us have already read it. And it’s an excellent book. So, we’re looking forward to talking about it. Alright. Well, sounds like that’s all we’ve got. So, we’ll wrap it up. We’ll catch you all next week.