Panel Jevin Maltais (github Quickjack Solutions) Jeff Schoolcraft (twitter github blog) Eric Davis (twitter github blog) Ashe Dryden (twitter github blog) Curtis McHale (twitter github blog) Reuven Lerner (twitter github blog) Charles M...

Transcript

[clattering sound] JEVIN: Who's attacking the keyboard? [Reuven laughs] JEVIN: Who's the keyboard attacker? [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net.] CHUCK: Hey, everybody and welcome to Episode 65 of the Freelancers Show! I'm going to say Ruby -- it's been a long day! Anyway, this week on our panel, we have Jeff Schoolcraft. JEFF: Hello! CHUCK: Eric Davis. ERIC: Hey! CHUCK: Ashe Dryden. ASHE: Hi there! CHUCK: Curtis McHale. CURTIS: Hello! CHUCK: Reuven Lerner. REUVEN: Hello there! CHUCK: I'm Charles Max Wood from DevChat.tv. This week, we have a special guest. And that's -- I know I'm going to say your name wrong in the end -- it's Jevin...Maltais? JEVIN: Yeah, that's pretty good, man. It's French-Canadian. [Chuck laughs] JEVIN: So, it's Malthe or Malte. Basically, silent "S", but yes, hi! Good to be here! [laughs] CHUCK: Awesome. So, do you want to introduce yourself really quickly? JEVIN: Sure! My name is Jevin, I'm a software consultant in Ottawa, Canada, and we basically build -- well, "we" -- so whenever I talk about we, it's actually just me then you have subs and stuff. But yeah, so I build end-to-end products, but wasn't interrupt with development for clients. And I'm just coming out with a book in the next two weeks called "Next Level Freelance", designed for freelancers who want to optimize their business for happiness. It helps people take a bit of time to figure out what it is that really makes them happy. And then from there, turn those into strategic business schools and then actionable stuffs to make that happen. The actual website is "nextlevelfreelance.com". With Leanpub thing, it didn't work out; I've had some issues with it. But yeah, nextlevelfreelance.com as the long kind of intro splash plug. CHUCK: Alright. What we actually brought you on the show to talk about is, "How to handle, basically, objections based on the core technology you're using". For most of us, that's Ruby; for one of us, that's PHP. JEVIN: Brutal. I think with any technology you're bringing into that's new or kind of innovative or even disruptive in some cases, this could be the resistance for people who are used to their own colegacy system, or just older technology. And so even when it's maybe a better technology, better system that you're bringing in, people are going to have resistance to it. So they might have questions or another issues that you need to address as a freelancer trying to use the technology that you think is actually best for the client, but maybe they don't know it yet. So, kind of couple of ideas and would happy to chat with you, guys, and see what else you guys have come up with it as well. CHUCK: Cool! Well, I'm a little curious for the rest of the panel, how often do you have some kind of objection Ruby versus PHP or .NET or Java or something? ASHE: I don't have it all that rarely, mostly because people are coming to me knowing the technologies that I work with. So I do Rails work, but I also do Drupal work, which I'm kind of like phasing out. So most of the time, people are coming to me specifically looking for that stuff so I don't have to do a whole lot of talking out; sometimes, but not so much. CHUCK: Interesting. Anyone else? JEFF: I agree with Ashe. I somehow think that I'm being too technical or contacted too late on a process that means the value prop. But for the most part, the technology stack is always on an issue and it's pretty much assumed that it will be Ruby or Rails, and it's just how they have come to me in the first place, I guess. CURTIS: Yeah. I should say, such as Jevin, with my county because I do a lot of government and corporate work, and so they're kind of stuck in Microsoft land so that's where I could be it -- CHUCK: Sad for them. REUVEN: I've definitely had people sort of wonder about the technology. They're different kinds of clients. The clients who'd come to me asking to help with their existing Rails software, obviously, they're not going to argue with that; and the people who'd come and they don't know anything about technology and they just sort of come to me and maybe they've heard that Rails is this interesting cool thing and I can do that, well, they're obviously not going to object either. But I've definitely had some clients, like I had this guy I did some work for about a year and a half ago, and he came to me to continue work on a Rails project that someone else has started. And after about 2 months of me working on it, he said, "You know I like you, I like the work that you did. But, there's no one else out there who can do this, and I'm not looking to have contractors or consultants to do this forever. I want to have someone in-house. And because I want to bring an in-house, I'm just going to throw away all the software you've done and the previous people did, and we're going to move over to PHP because it's so much easier to find PHP people," and he did. JEFF: Wow. CURTIS: That's a total Cost of Ownership question for them, right? REUVEN: Right. I said to him, "Look, it's possible that we can find people..." he was based in Israel, "...find people here. It's also possible we could find people elsewhere." But he wanted people who were sort of close physically because he had bad experiences with overseas outsourcing. He said, "Well, based on the availability of people and the cost of people also, I'm just going to move over to something else," but he was convinced that Rails was great. But as you said, it's like "Cost of Ownership" thing and moving forward as a business thing. CHUCK: Well, it's interesting because I did -- it was kind of an interview -- I went to breakfast with a potential client, and we're still talking; he hasn't hired me yet. We had this conversation about the stack as far as Ruby versus PHP versus Java and things. He used to work for Omniture, which was purchased by Adobe, then he worked for Adobe for a few years, so he's much more familiar with those technologies than he is with Ruby. And so we did have the conversation. It's an interesting conversation a lot of times because, well, you could build that in PHP and it would work. So, what are the real tradeoffs? We start talking about how much time it's going to take to build and things like that, and just my perception of PHP from what I've done with it and what I do and don't know about it; it was kind of interesting. We had the same conversation about Databases; should I stick with a Relational Database or should I go with one of the NoSQL Databases? Once again, it's an interesting conversation because you could make it work with PHP and some weirdo out there Database behind it. But the question becomes, how easy is it to maintain? How easy is it to write? How does it affect my time to market and things like that? And I'm not convinced that Ruby is always the right tool, but I think a lot of times, it can be. So that's usually the conversation that I have. REUVEN: Yeah, I get that question sometimes. Because people are like, "Well, you're a Ruby guy. So under what circumstances would you not say to use Ruby?" And I'm like, "Well, for your typical web application, if you're coming to me, that's probably going to be my choice because that's what I'm most comfortable with. If you're going to someone else, you would undoubtedly hear something else. But I don't think there's any right or wrong answer for this sort of scale of thing that you're doing. If you're talking about something massive even in terms of scope or scale or number of users, then maybe there'll be something else to talk about." These are typically small to medium projects. CHUCK: I'm really curious, Curtis, do you run into these kinds of objections very often? CURTIS: Like you were saying earlier, I have a lot of people come to me for WordPress work. The biggest times that I've seen it is when someone, typically a Rails contractor, has come to me for some frontend work. And what we're really doing is just building a basic website like 5-pages and a blog, and it's getting all built on Rails, which I am not convinced it's necessarily the right option. Sometimes, there's discussions about future, like what they want to do in the future, so they're going to build them on Rails now so they could continue with the same technology through their whole stack and future application plans. But, that's about it. For me, I'd say in the WordPress, we're all this [inaudible]; someone do this certain plugin or something as opposed to something else. Or, if you don't want to pay for something that's premium as opposed to just use the free ones, which can be good and cannot be good. CHUCK: Yup! JEVIN: I was just looking, doing some research for the show here, and I found at the SharePoint, for 5 users - $1200 for the lowest license for SharePoint. So if you're looking for like a low-cost, Wiki-type collaboration tool and you already have act or directory setup, that might be a good way to go! For $1500, there's not much that I can do for 9-hours that will be able to compete with that, maybe none. But I was thinking, "Well, I might actually recommend SharePoint in some cases," which I never ever thought. CHUCK: A lot of times, though, people are coming and they don't want to spend that much for a structure. So again, you can talk about the tradeoff there and make it make sense. JEVIN: Totally. CHUCK: I'm a little curious then, Jevin, how do you usually manage objections to Ruby? JEVIN: The two big ones that I come across are .NET and SharePoint. For .NET, it's a bit tough because there's a lot more people who were developing in that so you could use your Windows environment you already have, it's free to use .NET, you already have a database probably, [inaudible] it's free, so that's free. And then SharePoint we'll say, "Oh, what can be the custom that I can't do in SharePoint?" the answer is really, there's quite a lot that you can't do in SharePoint - for custom work in SharePoint. So there's a couple of things that I'll bring across and ask them. First of all, price. If you're doing a fixed-price or even if you're doing kind of an estimate for a project, I've always come under half-priced of a .NET project, either from an agency or on a personal level. I think because it's just so much faster to develop in Rails and maybe some of these rapid development frameworks, like maybe Cake (I don't know), just to do a PHP throwdown and maybe even .MVC, which is still pretty new and actually really inspired by Rails. So cost is a big factor; there's some other things, too. When you can show that, "I can iterate and I can deploy to you couple of times a day so you can actually see the features that come out," people are pretty impressed with that. Those are two off the top. I have more, but maybe I have those two points for initial discussion. What do you guys think? CHUCK: I think part of what you said has to do with your tools, and part of you has to, what you said, has to do with your process and who you are. I think that's an interesting aspect; that a lot of these systems have deployment frameworks that make it easy to deploy and things. But what you're saying is, "I've got these tools, I've got it really easy, we can put it up there and make it available to you immediately," and things like that; that lands more to process and understanding of your tools. Where, when you talk about like the speed of development and things that you can do in Rails, you're talking about both your knowledge of the framework and the fact that the framework gets a lot of stuff out of your way. CURTIS: I deploy multiple times a day, often to clients, as well on my WordPress-based projects. JEVIN: And you should do that with any framework, really. As they said, it's just part of the Rails culture. CURTIS: Yeah, it certainly a way bigger mentality than it is in what I do at all. I am one of the fewer people that do that regularly. REUVEN: I'm sort of curious to Jevin and maybe the others, if someone comes to me and they want, let's say Rails work or Postgres work or something, then fine they come to me for that sort of thing. But if someone comes to me and says, "What technology do you think is appropriate?" is this sort of obvious to them that -- maybe not -- that programmers have sort of their personal preferences and strong preferences often, and they're willing to say, "Well, you want to use the language that I know best, not because I know it best, but because it really is best." That's not only so convincing for clients; they didn't see this as sort of self-promotion. So, I'm wondering how you get around that feeling that potential clients might have? ERIC: I think it depends. I've done WordPress work and I've had clients come to me saying, "We want to do this and that," like they wanted to integrate a form stuff into WordPress. I was like, "I could do it in Rails because I can hack in and do stuff in the session of your cookies." But it's going to make a lot more sense to write this integration in PHP, like a stand-alone PHP app, than it would be to do it in Rails just because it's the same code base and legacy support, like if someone else wants a support that they don't have to know PHP and Rails. Whenever I talk to clients, I said, "Look, I'm going to be biased; I've been doing Rails for a long time. I've done other things, but I'll try to work with you and figure out what's going to be the best tool to use to figure out what you need. And if that's something that I can't provide you, so be it. I'll try to help you find someone else. But, I want to be a good fit all around." ASHE: I do the same thing. I definitely kind of give them the lay of the land when it comes to like, "If this is something you're going to have to be maintaining after I'm done with this project, are you going to be able to find people? Is it going to be within your price range?" All of those things are things that I discuss with the client before we decide on a new project. And sometimes, the technologies that I work with aren't the right things for them, and I'm perfectly fine with referring them to someone else that maybe work with .NET or whoever that would be a better fit for them. CHUCK: One other thing I want to add to that is that, a lot of times, it's usually in a first structure question and maintainability question. If I don't feel like I'm the right fit, then I'll refer them. But a lot of times, what I'll do is I'll also say, "Look, as far as this particular technology (PHP or WordPress or Django or whatever it is), I'm not an expert. But when it comes to programming, I know what I'm doing. And when it comes to these other technologies that you're talking about, which database you want to use and things like that, I know quite a bit and I'm willing to help you with that." In a lot of cases, I found that they'll consult me for an hour or two here or there when they have questions and want a second opinion. It's paid off for me, but it's also paid off in a lot ways for my clients because then they get the benefit of my experience and they also realize that in the areas where I don't know what's going on, I just tell them I don't know. So they'll ask me a question about the PHP framework or the Python framework and I'll just tell them, "You know what, I don't know. I could find out if you want me to, but I don't know," and then they get what they need. And that's really what I'm about. CURTIS: I found those referrals to be actually priceless when I sent someone somewhere else for anything. Quite often, even if they've had a good work from the other developer, the first person they come back to for the next project is me because I sent them somewhere else with no [inaudible] I just said, "Go, this is the best person to talk to." JEVIN: For me, I think one of the big things that has helped is, initially, I was branding myself really as a Ruby on Rails developer. And now, I'm referring to myself as a software consultant specializing in end-to-end applications; I've really taken the technology aspect out from that. So the whole time we're talking with a client, we're talking about what they're looking to have done and the capabilities of their product, and it's only really at the end that they might ask, "Oh, what language or what framework are you going to be using?" and I'll tell them, "Rails". We've already come to this point where they're so convinced that my organization is able to do this for them that it's usually a mute point because they're just so excited to actually get it completed. So, I really try to de-emphasize the technology that we use. But of course, you can't get away from that discussion in a lot of places. REUVEN: What I found recently that this has been through more -- I don't know if "flexibility" is the word -- but more sort of issues, debate, discussion; it's actually not so much on the service stuff for all the reasons everyone have said, but actually on the client side stuff and the JavaScript stuff. And there, there's just so much going on, both good and sort of chaotic, that it seems like there's a new JavaScript framework comes out every week or two that people are saying, "Well, can you do it in this? Can you do that on that?" And then it's very hard to sort of doing apples to apples comparison, partly because there's just so much out there. Has anyone sort of encounter what people say, "Well, you MUST do this in Backbone; you MUST do this in Meteor," and you don't necessarily know it or you don't think it's the right thing for the job? ERIC: I'm about at the right thing. I've seen people come say like, "We have Backbone," and most of the time, that's because they have legacy code or they have other developers that know Backbone. They're like, "This component of the stack is non-optional. If you're going to work for us, you have to do it." But most of my clients, when I talk with them they're like, "We don't care what you use to make it work, just make it work. Do and have this interaction, have this kind of responsiveness," that's basically all they care about. CURTIS: I found the issue is with the big, I guess the people that have just a little bit of technical knowledge and have not heard of Bootstrap or anything and say, "We have to use it." When you ask them why, they have no idea, but they still want to require it. ASHE: In my experiene, those are kind of clients to shy away from. If they're making decisions without having all the knowledge behind it, that's kind of a warning sign for me for a client. CHUCK: Yeah. On the backend again, one other thing that has come up is, sometimes they're really keen on Ruby on Rails, they're really keen on Node.js. And so when we start talking about the problems, some of the problems that they want solved, then I start talking to them and say, "Okay, these problems were solved really well by the paradigm that is supported by Ruby on Rails; and these other things are, they work really well for Node.js. But we can make them work one way or the other, but you may want to look at hybrid approach and take both of them for their strength and work it out that way." Ultimately, there's no single right way to do it. I think helping people understand the tradeoffs a lot times is really where I kind of sell them ongoing with me. Most of the time, between that and just the way that I interact with them and things, they really wind up buying me; they don't wind up buying Rails. ERIC: It seems like it depends a lot on a client. If you have a very business-like client that, "I have this business problem, I need you to solve it," there are very much, "Use whatever technology you know or you think is best," talk to them about the long-term maintainability, value, all that stuff. But if you have like a lead developer of an existing team, you're not going to have a lot of flexibility and change in the stack around. You might be able to make a suggestion here or there, but it's kind of be a political-uphill-battle type thing. So I think, based on your client -- are they're technical or they're non-technical, is it a new business thing, is there a legacy code that they are already working with -- I think that's really the dynamic of convincing someone to use something different, or even if you can. CHUCK: So, Jevin, you said you had some other objections that people have to Ruby or Rails. And even if you don't do Ruby or Rails, I think some of these objections, they give you examples of ways to talk to people about them. So I'm still curious to hear about them. JEVIN: Sure! Not so much, I guess objections, because usually it's "Guilty until proven innocent", right? So it's like, "What aren't you doing this in .NET?" of course. CHUCK: Right. JEVIN:"Of course, I should be doing it in .NET! But here's why I'm not..." So some other things that have kind of shown that are useful in Rails, and maybe PHP is going this way as well, but one thing what's really cool is showing them Relish and Cucumber. I know a lot of people are skeptical about actually the usefulness of Cucumber involved in the stakeholder, but there's been multiple occasions where the client asked me for update of the documentation, I can literally just print off or email them the Cucumber feature and send it to them. They're like, "Wow! This is great; this is exactly what I was looking for," especially for API stuff where it just really shows the API call and the response that they should be receiving. They just love it because it's up to date code. So when I could tell a client, "Listen, you're going to have up to date documentation that you can pass off to your developers and I can prove to you that it's going to work exactly like this," they get pretty excited about that; actually as much as someone could get excited about documentation. The other thing that people are saying they really like is just Twitter Bootstrap in general. It's by no means a Rails-specific CSS framework, but yet, it looks amazing, and I don't know any .NET projects that have really incorporated that. That said, I don't deal too much of .NET projects. But to say, "Listen, it's going to be mobile-optimized out of the box," people are pretty excited about that as well. So a real documentation that's up to date, that's testable, and Twitter Bootstrap could be big selling features for me. CHUCK: I think that's interesting, too, that -- again, it comes back to "I can do Twitter Bootstrap" doesn't necessarily make you stand out because Twitter Bootstrap is pretty easy to set up -- but helping people understand what the benefits are and letting them know that you know how to do whatever it is that solves their problem, that's a big payoff. JEVIN: Well, even just, "Look at this web app on your cell phone right now, I did this." There's very few apps that look decent on the phone, really -- when I say apps, I mean websites. REUVEN: Well, it sounds like -- Chuck have mentioned this before also -- but it sounds like it all comes down to trust. I even say this a lot of times to clients when I'm first talking to them, the non-technical clients, where I say, "Look, I don't know how my car works really well. So when something goes wrong, I bring it to the garage and trust them that it's going to work well." And if I ever have a good relationship, if I can trust them, if it work afterwards for a good price, then I'll keep working with them. And I'd say, "That sort of what you're going to get with me where you need to be able to trust me. And when you trust me, then I'm going make decisions that you might not understand on the technical side, but the "Trust" would mean that I'm trying to do it in your best interest." Once you've get that client's trust, then everything else is way smoother. CHUCK: Yeah, so true. CURTIS: I end up getting a ton of clients that are absolutely burned. I was just yesterday looking at code for a fairly high-profile greeting cards, and they have absolutely terrible code that was written like 3 months ago and they were charged like $20,000. I'm lucky I have a personal recommendation from someone that they very much trust from years past, otherwise, they are pretty hardcore on what they want and what they will accept because they've been burned so badly. JEVIN: Possibly. REUVEN: Yes, it's always nice to have people come when they have had bad experiences with other people and they said, "Oh, it's so nice to be able to talk to someone who really understands what I need." CHUCK: The other thing that's interesting is that a lot of times, I've ran into the objection to Rails based on being burned by another Rails dev. It paints us all with that kind of brush and so they're like, "Well, people who use Ruby are just trying to scam you." It's not the case, it's a tool like any other, but it does hurt. So you have to go out of your way to make it a positive experience! JEVIN: We don't hear about those .NET people getting burnt because they just go to another .NET developer, I guess. [laughter] CURTIS: Didn't learn their lesson the first time, right? [Jevin laughs] CHUCK: I'm trying not to bash on .NET, but yeah, you spend enough money to get kind of merit into that ecosystem. REUVEN: Well, not that I do any .NET work -- as I tell people, I've heard rumors that Microsoft is a very popular maker of operating systems and languages and applications, but I'm not sort of exposed to them [inaudible], but it is true that there are plenty of people out there who are inside of the Microsoft ecosystem. And what I've heard is that, if you're willing sort of buy into that, then done that as incredibly smooth because it's built to be integrated into all of that. And so it might actually be the right choice for an organization that has Microsoft everything - Database, Web Server, Servers Clients and so forth. CURTIS: And that speaks back for the total Cost of Ownership, like contact-switching for their whole team to new languages and new framework is so expensive. CHUCK: And when they already heavily invested into the ecosystem that they have. REUVEN: That reminds me, I had this client for a few years actually, where the whole place was a .NETshop. Somehow, someone have convinced them, they've been through black boxes that went into many factoring places; it was not a web app at all, but it was a .NET application that they sort of installed in different factories, and the Database using there was Postgres. So I was brought in as the Postgres guy to help them out. [laughter] JEVIN: Wow! REUVEN: Right. So basically, they were sort of wrestling with the Postgres driver for .NET and we would sort of work in parallel. I would do the Postgres stuff on my Mac and then sort of feed it over to their .NET system, they would import it, but it was like two different worlds. And they brought in the new vice-president of development or CTO or something like that, and he said, "This is madness!" [laughs] "Why are we using this? We can't find Postgres developers, whereas, what would be SQL Server developers are sort of dime a dozen." So they've been phasing out Postgres over the last year or two and hired some [inaudible] numbers of consultants to come in and switch things over to .NET, and I think they're pretty happy as a result. CHUCK: That kind of leads me into another thing when you mentioned that those SQL Server developers are kind of a dime a dozen. There are two things that I've ran into: one is that, "You're the only Ruby guy I know so I'm not sure if you get hit by a bus, then what would I do?" though I'm getting that less and less; the other thing that I hear a lot is the argument that, "Well, I could go and hire a PHP guy in India for $20 or less an hour, so why would I go with Rails when you cost so much more?" CURTIS: [laughs] Yeah. Even though you can hire them for less in India, it's not...yeah. [laughs][crosstalk] CURTIS: I'm going to insert the general's joke about the bad Indian programmer there, but -- Although I do know a few that are really good, it by and large has not been great code I've seen. ERIC: Well, it's like, "If you need to have a heart surgery, are you going to go down in the back alley because it cost only like $50?" CHUCK: Yup! REUVEN: What typically happens with me is, if someone raises the idea of outsourcing to India or Eastern Europe or somewhere, I'll say, "Well, I heard mixed things about that." And they'll typically just say, "Mixed? Really? It's all been terrible!" [laughs] "I didn't have a good experience at all!" And I'll say, "Well, okay, I haven't heard really mixed things about it, if were only bad things. But I didn't want to make you feel that." CHUCK: Yeah. ASHE: Well, let's keep in mind, too, that if you hired a developer in the United States for $20 an hour, you're probably wouldn't be getting great work either. So I think it's kind of unfair to assume that outsourcing any work to anyone in India is going to be poor where Americans that can pay a lot more, but specifically go to a country where we know we can pay it out less. REUVEN: Maybe I'll rephrase it; the Indian engineers and programmers I met has been extraordinarily brilliant, but they tend not to be in my experience at the outsourcing firms that most people discover, especially if they're discovering them for price reasons as opposed to technology reasons. JEFF: [inaudible] evolving into something that completely shouldn't be here. Just finding quality people anywhere is a struggle end of itself. But then when you try to add in culture differences and communication lag to a project that might not necessarily have great leadership in the beginning, you're going to have a problem no matter who it is. One of my current clients outsource to Russia. There's a guy on site here in North Carolina, he was like the biz guy, then I was the project manager, another end in Russia, and they had a team of .NET people in Russia - 10 guys or something like that. So they were .NETshop and they were mostly doing .NET work, mostly outsourced to Russia. They have a couple of in-house .NET people, and somehow they got convinced to build their API and Ruby using Sinatra. And they had two guys, local to them, they were doing the Ruby. I got brought in as another rescue project; I got in and they ended up firing everybody. That covered the Russian team because it's just way too much miscommunication with the Russian team; idioms weren't getting past across, there's culture differences. You've seen a lot with Indian developers, they will go out of their way to never ever tell you "No". They would tell you "Yes" for everything and try to figure out later; it's just a cultural thing. There are ton of reasons that outsourcing won't work anymore than having smart people in your office won't work if you can't communicate with them. CHUCK: Yeah. And just to add to that, I'm kind of go along with Ashe's point. My experience is that, you basically get what you pay for. If you're paying a low-cost, you're going to have all the problems that come with that, be it communication problems or other. Every once in a while, you do get lucky, though, when you find that guy that doesn't realize that he can make a whole lot more than $30 an hour doing Rails. And so then you kind of get a steal on that. But for the most part, if they're not charging that much, they either don't have a whole lot of experience or you're going to experience some other language or other issues as you move across the culture barriers. JEFF: Since I brought up that other client and as we're talking about hardware, they've been the only client I've ever told them not to use Ruby. Like I said, some other I convince to use Ruby and Sinatra as their API. They have no Ruby experience, they're .NET shop through and through, probably classic ASP before that; SQL Server, all Windows, never touched the Linux box, and they have many direct space to access. So they want to hire another junior Russian guy to do the Ruby dev and wanted me to basically mentor him for a couple of hours a month and bring him up to spin, I was like, "There's no way that's ever going to happen. And you're paying me a lot right now to fix a problem that you already have so you guys should really consider dabbing us Ruby stuff and rewriting it in .NET," that's 95% of their expertise is so they should deal with it or they're going to have to hire somebody or stick with me or some other contractor for a long time to deal with that Ruby. JEVIN: One of the issues that those happen which we already touched on was long-term maintenance of a project. The one project that I lost recently, they were .NETshop and they said, "Okay, we really love what you're proposing. We think it makes a lot of sense. But, what happens when you're gone because we are .NETshop?" we're going to talk about this a bit. And I said, "You know what's true? I'll be around, I'm not playing or going anywhere," by the way, that's not a very strong point to start out. So since the approach that I've had  which has been good response from people, a couple of things, in the contract, I'd say, "I'm going to give you bug fixes for 60 or 90 days for free. So if it's within scope, I'm just going to go ahead and fix it for you if there's a problem. You guys are going to need to play it, we don't want to have any issues from the beginning so I'm going to cover you up with no problem." And then I'm a big fan of offering a retention package to do regular maintenance for the client. This is a great way where we can make actually a couple of hundred bucks or thousand bucks depending on the client, I guess. So not just saying, "Let's hit 5-hours to do work," which may or may not be needed, I'm going to do monitor for all security issues because lord knows we've got Rails problems coming out the past 6 months or so. But you just attach it on the code file and code file will send you an email and there's just it with Rails or any other gem that you have associated with it. And then you could also have it plugged in with your acceptance test, you can do live testing against your APIs to be sure that things are working correctly. So you could have it all set up really automated, but yet, you're the one who's kind of responsible to be sure that it's all working properly. You have like a Ping Server that just test different API calls, or just the website to make sure it's working. So you can do that as well. I've offered a trading package for people even for 5 days or 3 days and they just kind of have basic training on Rails or Ruby to their decent developer, and no one take me up on that, which has been unfortunate because it's a great way to keep your development team with new technologies. But for some reason, no one has ever take me up on that. But those are some ways that I've done already. ERIC: Well, there's another aspect, too. I had this concern of one of my clients: I was the only developer, I was the one doing Rails, they worked in another language primarily. Basically, the problem is what's called the "bus factor", it's how many people on your team or on your company can get hit by a bus to actually completely kill your company. In their case, because I was the only Rails, the only Ruby guy doing their system, the bus factor was one. If I got hurt or got sick or anything else, the project basically would die. That was the big concern they had and that comes back to the maintenance stuff of like, "What if you leave? What if you're not around? What are we going to do?" The way I help them, I'll send a lot of documentations so that if they had to bring in even a junior Rails developer, they could kind of get in and kind of keep things at least limping along until they figure out what's going on. But that's the big concern especially if it's a client that is in the different technology or in a stack that is not like through their switching stack or something like that. So that's another thing to think about even above and beyond the retainer maintenance agreement, which I use with them, too. JEVIN: Do you have success with that, though? Like actually getting them to hire or to train up their internal team, which is fantastic if you can get to do that. ERIC: One client, yeah. This one I talked about, not so much, but we got it...I can't remember, I think it ended up being a 3 or 4-year constant to kind of maintenance project going on. And it got to the point where they didn't really need anymore work so it was like, "We'll contact you if there's like emergency stuff," but basically everything is stabilized and it kept working exactly how they wanted. And it depends on the project, too. Like this app with the long-term was kind of an internal project, so if it went down for a couple of hours, it wasn't a big deal; it just would make it harder for people to do their jobs, but it wouldn't actually cause the company to lose like mines of dollars. CHUCK: Interesting. REUVEN: I've sometimes had people ask me how long I've been doing consulting, or contracting. And I say, "Basically, this has been my full-time job since 1995." And they say, "Oh! Well, that's good to hear." Because what they're sometimes worried about is that I'm sort of doing this between jobs or between startups between companies, and as soon as something really exciting and interesting coming my way, then I'll say, "Well guys, it's been fun doing the consulting. But, now I'm off to take a real job," and so they don't want to be left high and dry especially if it's a long-term relationship. So the fact that I've been doing this for a while tends to put them a bit more to ease. ERIC: I think that's like a big aspect of consulting in general. Like the client's coming to you, they have concerns, they have fears that it's not going to work out whether the technology is going to fail or you're going to flake out, a whole bunch of things. So if you've been working in Ruby or even freelancing for a long time, that's kind of a chip on your side to kind of help you say, "Look, I've been doing this for 5 years; I've been doing this for 10 years. I've seen a lot of things, you can trust me with that," anytime that can actually help kind of overcome objections that they might have. And especially, this has happened a couple of times, I did PHP before I did Ruby so I know PHP and I know Ruby. So if a client comes to me with a PHP project they're porting to Ruby, the fact that I have experience in both sides of that is actually a bonus for me versus if I came from Java into Rails. CHUCK: Interesting. Alright, well, are there any other aspects of this we haven't talked about before we get to the picks? ERIC: There's one, we mentioned it. Like I said, I do only Ruby right now and I guess JavaScript, but I always try to keep like a network open on people that do like Python System Administration, Java, all the other things, so that if a client comes to me and they like want to integrate with Java stuff, I have people to refer them to that. I either know a little bit or maybe I've worked with like maybe they did a bit of Ruby on another project. So if you're freelancing, that kind referral network is actually huge. I think it was last week or whenever, Curtis, someone mentioned me asking about the PHP thing and I just sent them your way. It took me like 2 seconds that goes like, "Oh, this guy needs PHP. I know Curtis, he's the best tip for that; I don't even know anything about the project." But having that kind of network and building that up is a pretty good asset for your business. CHUCK: Yup! Alright, well, I'm going to go ahead and wrap this up. We'll start doing the picks. Thanks for coming, Jevin, and thanks for suggesting this topic; it's been interesting to talk about. JEVIN: Right on! CHUCK: Alright. Reuven, we're going to make you go first. What are your picks? REUVEN: I've got 4 picks today. First one is, I've been playing a bit more and more with Clojure, the Lisp language. I went into MIT and there, we were brainwashed to believe that Lisp was the only language worth talking about in the world. And so it's quite a pleasure sort of come back and play with it and use it. I've only sort of start to stick my toes in it and try to do some web development with it, I've been using this thing called "Compojure", which is a simple web framework for Clojure and it has been great fun so far. Second thing is, I've been with some travelling lately and my wife is going to be doing some travelling, and so I definitely want to recommend not only the "TripAdvisor" the site and not only TripAdvisor the apps, but there are these offline apps you can use, which I found to be amazing. Because basically, they let you put your phone when you're travelling and don't want to rack up data charges for roaming, so you can use your phone in airplane mode and then use the other WiFi or GPS and it has a map built-in. And so you can find all of the things you want and sort of walk around and get lost, or get unlost. I found this to be super helpful in the bunch of cities I've visited. Third thing is, I just finished reading a series to my 7-year old son, it's called "Ordinary Boy". It's a great series for kids about the city called Superopolis where everyone has a super power - some kind of strange and some actually are sort of useful - except of course this only one person named Ordinary Boy who has no super powers and of course, he ends up saving the day. It's just righteously funny for anyone who's ever had an interest in super heroes and my son really enjoyed it as well. The final thing is, recently, I start getting into playing "Words With Friends" or, as I've start to call it, "Word with people who used to be your friends". Now, we only have been playing sort of random people online, but also my wife and my 12-year old daughter, and we've been having a huge amount of fun playing each other. And you can sort of tell like used a bit of word and you hear Bling! in the next room and you hear "Oh, no!" So, that's been fun for all of us and it also got my daughter into sort of words in playing these games in sort of in adult level. Anyway, those are my picks for this week. CHUCK: Awesome. Eric, what are your picks? ERIC: My pick, it's going to be a whole website because it's about 6 or 7 pages, but I've had a standing desk for a while, and last week, I actually got a treadmill and I'm doing kind of like the walking does thing now. I actually talked about it; it's kind of a do-it-yourself like you can get any kind of standing desk or IKEA Hack Desk or whatever. And there's this treadmill on Amazon that's relatively cheap, kind of low-profile and you can disassemble it and change some of the wiring all that stuff and you end up with like a treadmill desk. I've actually been to using it on the call and I've already burned almost 150 calories just talking and have done like 500 steps, which is .2 miles. So if you're into the standing desk or kind of like the healthy work environment stuff and looking at treadmill stuff, I'd recommend this because the treadmill is only about $250 plus the desk and you can make a desk kind of just stacking books up and stuff like that. So, it's pretty cool. CHUCK: Nice. Jeff, what are your picks? JEFF: I have two, and I've probably said this one before; it's probably been mentioned across the network many times. But "Confreaks", again, I pick them. If the Rails Conf presentations are 71 videos online, if you missed Rails Conf, it's a great way to catch up on all the talks over there. And the other one is "Karma". It's a no-contract, pay-as-you-go WiFi hotspot, but it's set up so that you make it -- you try to share your WiFi with other people so it's designed to be shared and the more you share it, the more free data you get; it's only available in like 30 cities or so. It's based on Sprint networks, too. So if you're interested and you're looking for a hotspot, it looks like a cool idea. So, those are my two picks. CHUCK: Awesome. Ashe, what are your picks? ASHE: I have two. Last week, I believe, I've got my Fitbits lesson, which I've been waiting out for a while to do. It's not in production yet, but I just got it. It's much likely, the Fitbit one, which you [inaudible] but this is actually like a bracelet, like a musical watch. It counts your steps and measures your sleep, which is something that was really important to me because I don't have really high-quality of sleep. And the nice thing is that it kind of lets you compete with your friends where like the most number of steps in the past 7 days and a bunch of my programming friends are on there, so I'm like competing with a bunch of them outstep the other one. So that's fun and I highly recommend that you like it. And then the other one, I went to a dinner and bikes thing a couple of days ago and one of the people there was selling a book called "Everyday Bicycling: How to Ride a Bike for Transportation (Whatever Your Lifestyle)". This is something that I sorted doing when I'm financing and I sold my car and I only get around on foot, on bike, or by bus, and I really like how accessible this makes it [inaudible] giving things like going grocery shopping or they have kids getting around commuting and stuff. [inaudible] CHUCK: Awesome. Curtis, have we heard your picks yet? CURTIS: No, you have not. CHUCK: There's so many people on this show, I can't keep it straight, sorry. CURTIS: I know you're not going to ask one person 3 times like in the past. [laughter] ERIC: He's never done that. CURTIS: Oh, okay. I think it was you are the victim at that time. [Chuck laughs] ERIC: He's never done that. [laughter] CURTIS: So I have two picks today. I'm going to pick "Buffer" app, but I know we talked about that last week in our social media stuff, but I've been using it, I signed up for it during the podcast, and it is excellent and I am loving it; it makes sharing things way easier. And then a couple of episodes ago, I also talked about Trello and how I use it and how to post those half-finished. So it is finished now and up on my site. CHUCK: Yay! Awesome! Alright, well, I'll go next. My first pick is another iPhone app; I picked an iPhone app last time. This one is called "Commit" and it is awesome. Basically, what it is is you put in something that you want to do everyday kind of to start a habit and then you mark it off everyday and you kind of build up this big launch streak. It's by Nathan Barry and it's kind of nice. I kind of wish that it had an option or another app for like things I want to do every week, things I want to do every month, things I need to do every 3 months, but I guess I'll just use and only focus for that for right now. Anyway, the other app that I want to pick is, I forget what it's called; it's a mini-golf for the iPhone. It's a game I've been playing with my brother, "Mini Golf MatchUp", and it's another iPhone app. Basically you take your turn and you play a hole and then the other person plays that hole and then the next hole, and you get to watch the person who played the hole first, how they did it. Anyway, you can see who wins this stuff. It's a lot of fun and there are whole bunch of different golf courses that you can play. Anyway, those are my picks! And Jevin, what are your picks? JEVIN: Right on! Two for me; "Less Accounting", I just opened up an account with these guys maybe last week, two weeks ago. My bookkeeper uses QuickBooks to track of all the stuff. The pain, though, is when I want to go and review everything, I have to go and buy QuickBooks every single year, which sucks. So he's open to using Less Accounting to do my bookkeeping, and so far it's been going great. It just sucks everything down for my bank and they just did a re-launch of it, I think, so they partly has changed how the dashboard looks so they don't have charge, but I think they're just reintroducing those again. Anyways, so far it's giving me a lot more knowledge already in terms of the quality of my cashflow. The second thing is a book I just got from the library that's rated pretty highly on Amazon called "Treat Your Own Neck" by Robin McKenzie. Basically, it's just for people who have -- their neck is sore, etcetera and how you do some simple exercises to make it better. It's strongly pushed towards people who are at dusk for a long time, maybe people who have been listening to Freelancers Show, I don’t know, just saying. Anyways, it talks a lot about posture and how you can get to good posture you'd hope for by doing these simple exercises. I've been doing it a couple of days and it's been feeling better already. So he's hard on hit the cell to go to one of his own associates where they're trained by him. But I think if you go just by the exercises itself, you'll feel better. So, those are my two picks for this week. CHUCK: Nice. Alright, well, let's go ahead and wrap up the show. Thanks for coming again, it's awesome! JEVIN: It's been my pleasure. Love to just get sometime. CHUCK: Alright! Well, we're going to end the show, thanks for listening. We'll catch you all next week!