The Ruby Freelancers Show 056 – Learning on the Job

00:00
Download MP3

Panel Ashe Dryden (twitter github blog) Jim Gay (twitter github blog) Eric Davis (twitter github blog) Evan Light (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:20 - Finding Projects 04:50 - Being up front with clients about what you do and don’t know 06:14 - People who don’t know as much as they think they do Dunning-Kruger effect 08:21 - “Fake it til you make it” Honesty 11:23 - Offering a technology before you know it can be done Referring someone else instead Contract Specifics 15:59 - Lowering your rate to take a project to break into a new market Value Discounts/Comping Time 22:37 - Getting stuck and taking time to figure things out Time Tracking Reaching out for help in exchange for ____ (temporary mentorship) Velocity Subcontracting 28:35 - Taking a project because you want to learn a specific skill 30:02 - Refactoring Convincing a client that it’s good to refactor Showing good code vs bad good Is it code that you’re proud of? Client budget 34:45 - Educating clients on technology Episode 1 - Mongo DB Is Web Scale (NSFW) Technical Risk 37:05 - Panelist New Technology Interest Picks xkcd: Password Strength (Eric) GRC's | Password Haystacks: How Well Hidden is Your Needle? (Eric) Diceware Passphrase (Eric) SaneBox (Eric) Mailbox (Evan) Flexibits | Fantastical for Mac (Evan) How much sleep do we really need to work productively? - The Buffer Blog (Jim) The Visual Display of Quantitative Information by Edward Tufte (Jim) Most Productive Vim Shortcuts (Ashe) UX Apprentice (Ashe) Wool by Hugh Howey (Ashe) Robocalypse (Chuck) The iPhreaks Show (Chuck) Next Week Fixed Bids Transcript [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net] CHUCK: Hey everybody and welcome to Episode 56 of the Ruby Freelancers Show! This week on our panel, we have Ashe Dryden. ASHE: Hi there! CHUCK: Jim Gay. JIM: Hello from Sauna in Virginia Beach! CHUCK: Eric Davis. ERIC: Hello! CHUCK: Evan Light. EVAN: I'm truly confused [inaudible] CHUCK: Is there an order? JIM: Yeah, we had an order? EVAN: I'd do Eric, and then you do me, and then you do whoever else up in a Shell Bluff. CHUCK: Oh! I'm Charles Max Wood from devchat.tv, and I'm doing it wrong...So this week we're going to be talking about "Taking a Project to Learn Something". I think Ashe said it better, so I'm going to let her explain what we're talking about. ASHE: Sure! So basically, the concept of taking on a project specifically say "you can learn something new and expand upon what you already know", so learning on the job kind of thing. CHUCK: You mean like speaking coherently when you didn't sleep last night? ASHE: Exactly like that! [laughs] CHUCK: [laughs] Awesome! JIM: I'm curious then right off of that, because I haven't done a whole lot of that. How do you find these projects? It's one thing to think or I'm going to work on this new technology, but then actually finding somebody who needs it and convincing them that you're the person for the job. ASHE: Well for me, most of the time it's people coming to me asking if I know how to do a certain thing or if I've done a certain thing before. That gives me an idea that that's something that people are looking for, or it's maybe something that I should look into more and maybe think about learning. I don't generally go out of my way to find projects that are for something that I haven't been learning or haven't wanting to learn. EVAN: Yeah, same here. My current projects -- I'm doing a lot more JavaScripts than I normally do and I've been doing JavaScript off and on for a long time, but I haven't play with Backbone, my friends expect this project has a little bit. So what I told the client, because he'd ask if I knew that the other contractor,

Transcript

[Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net] CHUCK: Hey everybody and welcome to Episode 56 of the Ruby Freelancers Show! This week on our panel, we have Ashe Dryden. ASHE: Hi there! CHUCK: Jim Gay. JIM: Hello from Sauna in Virginia Beach! CHUCK: Eric Davis. ERIC: Hello! CHUCK: Evan Light. EVAN: I'm truly confused [inaudible] CHUCK: Is there an order? JIM: Yeah, we had an order? EVAN: I'd do Eric, and then you do me, and then you do whoever else up in a Shell Bluff. CHUCK: Oh! I'm Charles Max Wood from devchat.tv, and I'm doing it wrong...So this week we're going to be talking about "Taking a Project to Learn Something". I think Ashe said it better, so I'm going to let her explain what we're talking about. ASHE: Sure! So basically, the concept of taking on a project specifically say "you can learn something new and expand upon what you already know", so learning on the job kind of thing. CHUCK: You mean like speaking coherently when you didn't sleep last night? ASHE: Exactly like that! [laughs] CHUCK: [laughs] Awesome! JIM: I'm curious then right off of that, because I haven't done a whole lot of that. How do you find these projects? It's one thing to think or I'm going to work on this new technology, but then actually finding somebody who needs it and convincing them that you're the person for the job. ASHE: Well for me, most of the time it's people coming to me asking if I know how to do a certain thing or if I've done a certain thing before. That gives me an idea that that's something that people are looking for, or it's maybe something that I should look into more and maybe think about learning. I don't generally go out of my way to find projects that are for something that I haven't been learning or haven't wanting to learn. EVAN: Yeah, same here. My current projects -- I'm doing a lot more JavaScripts than I normally do and I've been doing JavaScript off and on for a long time, but I haven't play with Backbone, my friends expect this project has a little bit. So what I told the client, because he'd ask if I knew that the other contractor, he was often, when I negotiate with the client is I said, "If I find myself beating my head against the wall because there's something I feel like I should know but I don't, then I just won't believe it that done". CHUCK: The idea of finding a client that has something that I'm not familiar with versus having them find me, it's usually the latter. EVAN: Yeah, exactly the same thing. They approached you because of something that they know you already know how to do, and then they are also looking for people who can do some other X, Y, and Z things and ask if you can do it. CHUCK: Yeah. I've also found that in most projects that I pick up. There's some aspect of it that I haven't done before, but at the same time, a lot of it really isn't outside of the realm of something that I know I can figure out. On occasion, there are things where it's like "Oh gee! I really just don't know what it's going to take to do it." For example, yesterday I went to lunch with a referral that I got from a friend of mine, and he went through the list of things that he needed. I could do everything except for the 'wire transfers' (he needs to be able to do wire transfers for some of his employees), and I've never heard and do an API that did that. So, I just said "Well, here's the kind of information we need", and I'm excited to learn how to do it if it's possible to do through an API call or something. JIM: For some of that stuff, I think your level of experience and how much they believe you can solve problems quickly has a lot to do with it as well because I've seen myself projects where they expect a lot out of me and I will say flat out, "Well, I've never used Backbone before, but I've written JavaScript and I know it well, so I have to spend some time getting up to speed on it", whereas I've seen new developers who have no experience with barely anything say "Well, I don't really know it". And for someone who's experienced in programming in general, I found that my clients will be okay with you getting up to speed, but then I've seen the junior developers being told "Well, learn it on your own time; go home and watch videos or something like that. But while you here, you're going to work." EVAN: But if you a have a decent breath of experience, then it makes it a lot easier to pick up new skills I found. What I've seen at Backbone, for instance, I found pretty easy to pick up; I was just able to [intrude a few things and develop some hypothesis, tested them rapidly, and figured out how some things work very quickly. ASHE: Yeah, having like context to begin with definitely helps, and I think, where a lot of clients may be shy away from taking out on contract or is it taking on employees that don't know specific technology; that one of their projects is focusing and burned in the past by people mapping upfront about them about "Hey, I don't know this, but I do have this other context", or "I don't know this, but I'll take the time and learn on my own time", or "I'll charge you less", or just as long as they know upfront that "Hey, I don't label myself an expert in this technology, but I am going learn it". CHUCK: Can I tackle that real quickly? Is it -- I don't know what the right word is -- is it unethical? Or is it wrong? Is it dishonest to say "Yes, I can work in that technology" if you really don't know anything about it? EVAN: I think it's dishonest to say that without caveating your degree of experience and that you'll be learning it as you go, yes. CHUCK: I have to agree and that's the approach that I usually take. "I haven't done a lot with X or I don't know anything about X", but at the same time I usually represent it as "I'm a smart person and I can figure it out, and I've dealt with things that are similar or likely similar" to give them an idea of how much it's going to take me to ramp up on it. But yeah, I usually tell people, if I don't know it, then I'll tell them I just don't know it. EVAN: I keep trying to figure out if the clients who'd come to us because they've had bad experiences with another contractor (if the other contractor was operating from just a point of naivety where they thought "Yeah, I can actually learn this", and then they just don't and they perform badly), or if the contractor was just a bad actor. Because I've heard some people over the years say "Yeah, I'm doing X, and I really don't know what I'm doing, but I'm learning it as I go", how do you get that project? How did they get that project? How do they make the mess that we end up inheriting? ERIC: Well if you look at the different levels of a skill, the beginner basically knows they don't know anything and they're free to admit that they're beginner. The intermediate level is where you start getting into someone might think that they know something (we'd just say Rails); they might think they know Rails really good, but in practical matters, they only know the beginner and a little bit of intermediate. It's once you get to the advanced and expert level that you know the thing, but you also know what you don't know so you can have that more thing like "Yeah, I've used Rails, but I haven't used Rails for something, for instance". So I think the problem, at least what I see a lot of is, you have some developers who are actually intermediate developers, but they think they're experts because there's things that they DON'T know that they don't know. And so they tell the clients, "Yeah, I've been using Rails for a long time, I know this", but they actually don't really know it as well as they think they do. EVAN: I'm going to provide a link for it, but this to me sounds exactly like the Dunning-Kruger effect. CHUCK: I want to jump in and just point out that I've also heard people basically say -- I don't know where this idea comes from, but they talk like they can get away with basically be yessing their way through "Yes, I can do everything that you want me to do", and then on the back end, then they go figure it out and sell it. It's just...[sigh] I don't know, I have a really hard time representing things other than the way they are. But I'm interested because I know that some people do get away with it; they say "Yes, I can do whatever it is" and then they fudge it, they do it! ASHE: Yeah, and I think that a lot of people get away with this "Fake it 'til you make it" for a long time until they get backed into a corner. And other people are starting to realize that they don't know as much as they do. So maybe at the beginning of your career, it helps to do the "Fake it 'til you make it". But once you get to a point where an entire project is rusting on your shoulders, that's not the time to say that you know something that you don't. [laughs][crosstalk] EVAN: I'd say, you shouldn't say you know something when you don't. Again, you really should say, I believe at least, "Here is what I do know, here is what I don't know, but I believe I can learn it". JIM: Here's the one thing that I'm going to jump in and say is that, depends on if you're just representing yourself, so if you are working with or have worked with people -- for example, I've never done the Android development -- but if I knew my friend was already available who does Android all the time and I was ready to work with him, I might go and say, "Yes, we can do that". (If) I don't know all the technical details, or something like that, I wouldn't say that I'm necessarily the one who can answer the questions. But if I'm going to sub-contract the work, I think it's perfectly fine to say "Yes, we can tackle this issues", as long as you come back to it with good response later. ERIC: Well, you can also say that you yourself don't know it or aren't as skilled as you'd like to be with it, but you have a network or you have associates, depending on if you're subbing out or if you just have people that you can talk to one on one about it. But it comes back to honesty like you got to be as upfront as you can and tell the client "I might not be the expert level at, say, Android as I am on Ruby, so it's going to be slower, it's going to take more time, but I can get the resources and give in, say, my experience in iOS. I think I can manage it". And basically, you just got to leave the call to the client; you give them as much information as you can and let them make the decision. EVAN: Totally. JIM: I think this is sort of a good lead into attempt to conversation. When you're looking for work and you're trying to move into areas where you don't have experience, and for as long as you're focusing on the business value of what it is you're doing, then you can show your client or potential client that you're not just there to learn some technical thing or to push some new technology into their stack, but that you, at least, have some understanding of that particular technology is important to their bottom line, and that you can help them grow by learning that or by working with somebody who knows it and applying it rather than just saying "Yes, I can do that" and kind of getting myriad and technical questions; it can really make you seem like someone who will be helpful in general and not just helpful for this particular technology they're interested in. CHUCK: I have a related question, then. What about the contract? Where you take the contract? You've kind of sold them on Ruby on Rails and Backbone.js, and then you figure out that Backbone.js doesn't really fit the problem as well as, say, AngularJS or Ember.js, that you just don't know. At that point, again, how do you represent that to the client? EVAN: First, you have to trust yourself that you are actually right about something that you don't really know much about. CHUCK: Fair enough. ASHE: I think it's interesting going into a project and offering a technology before you know it can be done in that technology. I tried to remain as 'technology-specific agnostic' within my contract because things come up. I try to apply the technology that works best for the problem, not just what I might be best at or I feel most comfortable, and what would actually work best for the client; what would work best for the contractor that comes after me or whoever has to maintain this. So maybe, not putting those specifics in the contract is a way to go. EVAN: I'm going to throw out maybe one of the heretical ones, although I think we've said it occasionally on this podcast that, if they are looking for skills that I don't have enough of and I know other people that do, and they absolutely need those skills and I can't substitute my own somehow, I would probably just refer them as someone who actually would know how to do it better. ASHE: Right. EVAN: Even though it would hurt a little, let's be honest. [crosstalk] ASHE: But there's so much trust with that client, though, that "You're honest with me enough that you think that there's somebody else that can do this better, I'm more likely to go to you for business or for referrals", that kind of thing in the future. EVAN: Sure. You can say it's just the right thing to do, you can say it's paying it forward. I don't think I've ever had it come back to me, but I've still done it a number of times. JIM: I want to echo what I've said about possibly just leaving these things out of a contract -- I have a contract right now that specifically says that I'll be giving support for my SQL development where we're actually using a couple different databases, and it's the type of thing where we negotiate it on other aspects of the contract, and I realized that at the end. It just wasn't worth me saying "Oh by the way, you have me specifically supporting my SQL, but not these other things" - we're doing postscripts in Mongo and Redis, and it's just not worth it. So it's the type of thing where we got most of the details hammered out in a contract, and then nobody is looking at those aspects of the money details. I think, if we do find out like "Hey, we're going to use Backbone", and you get into it, actually, this is a much better fit for just plain old simple JavaScripts, somebody totally over-engineered this thing. I think it's perfectly fine to go back to them and say, "Yeah, we talked about doing this, but we discovered new things". ERIC: Well, that's the idea. It's basically to find like what the project is using, but then that's still like "This can be changed at any time" based on client and developer requirements changes and all that. So I actually pin it down a little bit, but I keep it vague in that we can change without doing a whole new contract. ASHE: I think it's a lot easier to stay vague if they didn't come to you asking for specific technology or if they don't already have an existing app with this specific technology. You can just say "This is their problem that we're solving", you don't have to put prescription for the problem in a contract. CHUCK: Yeah, that's what I was going to say. Usually, I'm being contracted to build an app that does X,Y, and Z, that solves this problems, and does these kinds of things; and I don't specify the technology, I specify "You're going to pay an hourly rate as I worked through this or you're going to pay a fixed bid and here are the very specific details of what I'm going to provide and not going to provide", but it doesn't break it down into technologies and technology stacks. EVAN: That's the difference between a staff aug project, too, and I guess, a sole source contract especially Greenfield where in a latter case, you can choose the implementation in a former case. They probably already have some technologies and you might know some of them, you might not know some of them, in which case, you have to learn some of them on the job or you could work with them. CHUCK: Yeah. One thing that I've run into recently is, one lead that I've been chasing for a while just emailed me and said "Hey, I'm looking for somebody who can do iOS work for me". I've recently made some contacts that can help me do iOS stuff, I don't know if I could sub-contract to them, but they can definitely point me in the right direction. So I'm wondering if I could take the project maybe at a lower rate, or something. Have you ever considered doing that to break in to a new market or to pick up a new technology? EVAN: Totally. ERIC: No. I don't like to lower my rates especially because it's an experience thing. Most of the value I give to my client is not the technical value, but it's the business value and overall software engineering of how this is going to work with this other part. For example, I actually looked at getting into JavaScript, like leaving the Ruby side a little bit and doing JavaScript half the time and maybe if I can go all the way into JavaScripts. And as I've noticed, it just wasn't the community for me so I stayed in Ruby. But I was looking into that and I thought "Oh, should I lower my rate because I haven't been doing JavaScript as heavily". And realistically, when I came down to it is, they're still asking for some projects for me; they're still going to get business value from you. And the kind of clients I go for are the clients that handle business, handle profit, and it's basically an accelerator for them. So, whether I write it in Ruby or JavaScript or Perl or Erlang or anything, it doesn't matter to them; they're really comes down to "is that the right tool for them". Now, the other argument is, it could take me longer to do the JavaScript portion, and that's a fair argument. But I didn't really want to factor my rate into that because it's still -- if my rate is lower and the hours are the same -- it's still going to screw up my own accounting. So I just kept my rate the same and basically would tell the client "Look, if I run into, say, Backbone stuff and I don't know what I'm doing, I'll compute time like I will go off the clock for a few hours to figure out this specific problem", and then once I figured it out, I would go back on the clock to actually do their work. CHUCK: I think that's one fair approach. The other thing is if they're willing to accept the trade off of your skill level and keep the rate the same. In other words, if they feel like they're getting that kind of value out of it anyway, then I think fair is fair. ASHE: I think the other thing that's important about that is, once you lower your rates, it's really hard to bring them back up. I always try to keep my clients further around the same rate -- not everybody pays the same rate for various different reasons, but every new client pays at least as much as all the clients that came before them. So I'm providing the same amount of value whether or not I'm learning on the job because, like what Eric was saying, I bring a lot of other context and skills from other areas that I can apply and they work around that seems to be the same. And a lot of times, some of those hours actually won't bill for if it's purely like I'm reading a book or I'm watching videos. EVAN: I have a hard time -- couldn't justified to myself billing the same rate for technologies that I'm...If let's say, I'm trying to break in to a new area, I'm using primarily technologies that I'm brand new to. Sure, there are a lot of ways that I can add the same value I did before, but if I'm learning, then I know I'm not going to be working as efficiently as I would if I was using something that I'm proficient with. So to that extent, it doesn't seem right to me to bill the normal rate. That said, I've never really had a problem -- I guess I haven't really fluctuated my rate much because I haven't tried to do this all that much -- but I've never really had a problem getting my rate back up. All of what I've been seeing, and this is more of a segue so we're tangent so we really don't have to explore if you don't want, I just seen a lot of people who are offering lower rates than they used to from the leads that I've been getting over the past few months - these for the same skills, too, I might add. CHUCK: The only thing that I can see with that is, if I offer somebody a lower rate and it's like for few weeks or a month or whatever, that's not of huge problem. But as I become more proficient with that technology, I'm going to want to bring them up to the higher rate. I was just going to say, a lot of times, people aren't really keen on that. And if you set some kind of sunset where it's like "This 2 or 3 months, it's kind of me ramping up, and then after that, you have to pay the full rate", then they'll go find somebody else. EVAN: Well, that's what I've talked to some clients about doing before. For example, I was trying to do exactly that with my apprentice, with Pat, that I told the client that I would bill them X rate for Y amount of time, and then after that, his rate will go up to something else. And I really didn't have too many problems with that. ASHE: I guess I'd just operate on the -- like there's some kind of something psychological at work when you tell somebody what your rate is. In their head, they equate that with how much you’re worth. And I think that, for me not wanting to bring my rate down is lowering the value in their mind that I provide. EVAN: But you could tell them, "Before, what I normally do is this; this is what I'd normally charge for this skill. (But) because I'm learning it, I would start at this rate, and we would agree on a finite period of time and then I would up it to my normal rate". I think you have a really good point there, but you can establish at expectation by saying "This is what I normally bill for my ordinary work". ERIC: And at the same time, you can just bill your normal rate and then count them hours on the invoice to kind of balance them to the low rate; and there could be a difference at all projects. Because almost all of my projects are about a year in length, so we're talking long-term contracts, procurement, a lot of red tape to cut through, and having to deal like a rate change or something like that, I know, would upset a lot of purchasing departments. ASHE: Yeah. EVAN: And in fairness, Eric, that's exactly what I'm doing with my friend and the work I'm doing right now. CHUCK: So basically, what you were saying is you just add another line item that is "Here's your discount, your (whatever) percentage discount", or whatever dollar discount per hour? EVAN: Yes. Actually I will say -- I'm taking advice that, I think maybe it was Eric or one of us, not me, gave on an earlier episode where when we're comping the customer time -- I specifically tell them, "I'm comping the customer time and tell them how much". ERIC: Yeah. That's something I learned from a client who did [inaudible]. You basically say, "I'm billing you $400 and in this invoice is $20 of comp time or where we're searching and thrashing on this other issue". So you've showed them upfront that "You would have been charged $120, but you're not". That's exactly how I do it; I learned it from them. CHUCK: I like that. So is that how you handle things when you get really stuck on something that you don't know? ERIC: That's how I do it, yeah. I'll go off the clock for a little bit - 15 minutes, an hour, or couple of hours. Sometimes I'll even tell the client like "Look, I need you to push the account or the schedule back on this thing; I'm running at a problem and I'd like to take it out of band (and) look at it on my own time, and then come back to you". That's part of how I do my project management; we always have 2 or 3 things going so I can jump to something else for billable time while I look at that other issue. CHUCK: The other question I have is the time tracking thing. So, you go off the clock? Or you just essentially adding another line item that is non-billable, or something? ERIC: Yeah. This goes back to the show and time tracking; I track all of my time. I track my time I spend in email, I track my time I spend doing my daily planning, so in my system, I have an issued where basically 'this is the task', and I've logged my billable time to that, while I also log my non-billable time to it, so I can come back and say that "I'm going to spend 10 hours on this feature, but of that, 3 hours was non-billable. And my invoicing software can take that into account and put that all on to the invoice like it needs to be. CHUCK: How do the rest of you guys handle getting stuck? ASHE: Most of the time, I already know people who do those specific types of things so I reach out to them. In exchange, I buy them coffee or I buy them lunch, just because I'm in next steps away that I would have learned otherwise. So I look at it as like a temporary mentorship. A lot of times, I'll approach people before I take a project on and say "Hey, I'm taking on this project. If I have any questions about this, do you mind if I would send you an email or if we can get together for an hour and I'll buy you lunch", or whatever the case is. That way, they're kind of expecting that it might happen. And it also works, too, because I have a lot of people that will end up in a reciprocal relationship where I know something that they might want to take on for a client, that they can then come to me and ask questions. EVAN: I was going to add that I think it also depends on different definitions of stuck; I guess we're always working at certain degrees of efficiencies. Sometimes we are operating less efficiently solving a particular problem for one reason or another maybe; we're just bumbling around that particular day, or it's a particularly nasty problem. So my solution varies based on the kinds of stuck. If it's a particularly nasty problem, well they hired me to solve problems and nasty ones included, so maybe if it's as long as it's something I'm skilled in, then I probably just bill my hours straight. If it's, again, something I'm not skilled than I feel like I should be, then maybe I comp them some -- ERIC: On this one, I do sometimes the -- if I spend a couple of hours or whatever trying to figure out difficult problem and find out that it's just user like I forgot a semi-colon or something really stupid, I'll go back and comp them time that I had on my clock or running as billable time. JIM: For me, I am very quick to question the business value or something if I find it a bit difficult to do. Not so much because I'm lazy, but if it is difficult to implement, I want to weigh that option; is it worth it to implement as feature and pay me or whoever else is working on it to implement it, or is there an alternative way to get what you want. So that's the first thing that I do: find something difficult, or run into a bug, or whatever it may be. I'll take a step back and look and forget about the technical aspects, but I will go to the person whose in-charge of the product and say, "Hey, do we really need to do this? Do you know that the users want to do this?" Sometimes their answer is yes, and then I'd do similar things, not to be able just to ask questions and try and reach out to the people who might know. But then, I would also do what Eric does, kind of stop the clock and go do my research. CHUCK: Yeah. One other thing I want to add to that is just that, sometimes the trade off isn't what it's going to cost, or whether or not there's business value, but (it) has more to do with the velocity. So you're going back to them and say, "Hey look, I told you this is probably going to take about 4-6 hours, looks like it's going to be more like 12-18 hours", so you're going to kick a couple other features off of this print or out of this release. And then they can make the call as to whether it's worth it on their timeline to make that change. EVAN: In terms of keeping the customer happy, what I found in most of those cases is that there's at least one other option that I can identify. So at least, I can present them with a trade off that's more than binary of "Yes, we implement; No, we don't". It's "We can implement it the way you wanted and it will cost a lot more or take more time", or "We can implement it in this more spectacular passion and maybe we can take this really simple approach that allows us to be lazy, but it doesn't cost much and it gets you most of the way there", or we can choose not do it at all. I really prefer to give them that trade off because otherwise, you're frankly presenting them with a problem. They're saying they want X and you're essentially saying "You can have it, but it'll cost a lot or no". And I find it more productive whenever I can to take a step back and say, "Is there a way I can cheat a little, if I can bend the rules and try to do this simpler?" CHUCK: Yeah. One other approach I've used is, I've come back to them, because again, we're talking about things that we usually know somebody who can do it. I've gone back to a client and said, "Hey look, can we temporarily grant access to this sub-contractor of mine who is awesome? If I do it, it's going to take 6 hours, but he's not going to struggle the same way I am, so can I bring him in and have him do it in an hour?" And then you'd just handle the billing on how you handle the billing. JIM: I want to bring a conversation back around because we've talked about sort of just extending ourselves a little bit. For example, I have zero experience with Erlang, and if I decided I wanted to learn Erlang, I think the only way I would try to find a project where I could work on that is if I knew I had sufficient runway available. If I'm up against the bottom of my bank account and I need to make sure that I'm paying my mortgage and my kids can go to the doctor or whatever it may be, that definitely place in to whether or not I would take a project or how I might respond to somebody interested in some technology where I don't have experience. ERIC: Yeah, I'll absolutely do that within the project. If the project is all about Erlang, and that's the core of the project, and I'm not skilled in it, I wouldn't take it. But if it's, say, Rails or Ruby and there might be like an Erlang component that worst case scenario, you could drop the Erlang and go to just a Ruby stack, I would probably try to take it and then use that kind of cipher to pick up Errlang. ASHE: Yeah. And those who has to be something actually want to learn. I don't necessarily want to learn Erlang so I don't have as much motivation to take a project on I know would be all on Errlang. CHUCK: How do we get Errlang as the technology [inaudible] EVAN: It's Jim's fault. [laughter] CHUCK: One of the question when we're discussing that Ashe put in was continually refactoring each to learn more. I'm a little curious to see what you guys approached to that is just because over the years, I've gotten from writing really crappy Rails code to writing some less crappy Rails code; there are few aspects that I'm still solidifying there in my style of writing it. But as you learn more, obviously, you're going to be able to write better code. Do you go back in refactor things? ASHE: I definitely do as long as I'm obviously still on the project and there's still hours available. I always try, if I'm coding hours, I always try to put a little bit of buffer time in there if it's something I'm learning new just because you don't know if something is going to -- something looks easy but it's going to take far too long. So if I have those extra hours in there, I definitely go back and start playing the things that I may have just learned to something that I wrote 2 weeks ago or 3 weeks ago. CHUCK: Can I push back a little on that? How do you convince the client that it's worth it to them to have you basically re-write the same code? ASHE: I think the same way that you convince a client that refactoring in general is a good idea. You're kind of future-proofing against technical debt, right? It's something that's knocked on in the most elegant way or the most "but if it's not done in the best way possible, then that's something that somebody else is going to have to deal with in the future. If it's something that's confusing, that's going to cause you more time and frustration in the future, so you gain a lot out of refactoring". EVAN: Then it come down to educating the client and explaining to them what technical debt is and really it means that while they have the illusion of making a lot of progress quickly, that what it mean is a longer term as that things are going to slow down. Or, that things will actually still get done quickly, but they will break a lot more often. JIM: I will actually resort to showing them the code. If it's non-technical people, I will show them well-factored code and the code that I want to change. I'll explain to them, "Look, it's difficult here. The pain point is for actually...If we make a change to this process, I have to break this apart", whoever has to come back and understand it. It's much easier if, for example, you look at this code -- and code in general for non-technical people can be kind of scary, but if you show them good code versus bad code, they see it like there's a gestalt without looking at well-written code that if you have this massive procedure all mess, it's really difficult to understand. And they get that like "these are the jump to the conclusion about why he might need something like this", if they're not technically trained. EVAN: Did you just say gestalt on this podcast? JIM: I did. I did. EVAN: I was "Who said that?" CHUCK: Jim? EVAN: Yeah, okay. CHUCK: So, the other question I have -- I know that we all kind of have our ways of approaching refactoring (in technologies you're familiar with), but the technologies that we're not so familiar with, as we're learning we're talking about as we learn we refactor things, how frequently do you go back and refactor trouble areas versus just refactoring things as you have to go back and work on that code again? EVAN: I think it depends on how central it is to the client; how much I expect them to lean on that particular piece of code in the future. Usually, I have to base on conversations with the client; what's the direction of their product? Is this something [inaudible]? If they're going to need to work on a lot more in the future, then it should be cleaner. ASHE: Right. And it's 'the code that I'm proud of' is the other thing that I like to think about. Is it something that, if I was somebody coming out to this project and I read that code what I grown about it, I try to not leave that kind of mess behind. So, whether I'm going back in refactoring, something that I wrote 3 weeks ago or if it's something that I had to add something else and to dis-block and "Oh, I should probably fix this stuff around it", it just really depends on what I'm learning and the quality of code to begin with. EVAN: I have to agree. And the position should be on try because some projects or some clients I worked with, they just don't have enough budget to let me do everything right and get the features that they want. And yes, if Uncle Bob were listening, he would say "Well, you shouldn't have accepted that project in the first place", and then as I wrote in the chat "Well, I kind of like paying my bills so sometimes I accept constraints that maybe I don't like very much." ASHE: Yeah, not every project is an ideal project for sure. CHUCK: So the other question I have is, as you're learning a technology, how often do you find that you have to educate your client on that technology? EVAN: Meaning? CHUCK: For example, let's say that you make the determination that MongoDB is the way to go for this project for whatever reason. So you're learning MongoDB as you developed this application, how much do you have to explain to the client as far as why you went with MongoDB? Or, how much do they actually need to know about it as you learn it? ERIC: You got to think about it for like if that's going to be part of their stack, they're going to need to know the risks associated with it, like a database, say, what's the chance of losing the data, what's the chance of it going down, what's the scalability, all that stuff. So they're going to have to know at least how that technology is going to affect their business. I try to educate them at the very high level of what it is. And also, if they really need support like, say, there's a problem in MongoDB that's outside of all their developers' knowledge, can they contact the corporate entity and get paid support? Is there a huge community for it? Depending on how critical is that, something I don't take lightly, I try to bring up big stack changes well in advanced that when they're actually need it just so the client has time to get used to it and feel comfortable with the technology. I maybe even do a prototype or two around it to see how it's going to play out with their main app before I actually put it in the main code. CHUCK: So Evan just put a link in regarding MongoDB. I just have to ask, is that NSFW? EVAN: Slightly. CHUCK: Okay. EVAN: I don't think there's any sexual language in it, but there's definitely be some profanity. CHUCK: If it's the one I'm thinking about, it's pretty funny [inaudible]. EVAN: Involves a certain kind of farming. CHUCK: [laughs] Oh...Anyway, yeah, I tend to agree with what Eric said. ERIC: On another point, like say, a third-party JavaScript library that just does like Date Validations or something like that, that's such low-risk that I don't even tell the client. I would say "We're going to use third-party of the code, open source, MIT", or whatever and just use it. That's kind of as a consultant, you got to weigh a lot of the technical risk and then translate into business first for them. CHUCK: Yup. JIM: I'm curious, what's -- everybody here is a freelancer -- what are all of you interested in learning? Are any of you actively pursuing a particular technology or process that you want to learn about? EVAN: That's like to do a little bit more closure and I wouldn't mind picking up an Erlang project. ASHE: Yeah, closure is definitely on my list; Backbone is also in my list - two things that I haven't had the opportunity or the time to really focus any time on. CHUCK: My things are, I really want to learn more deeply just JavaScript, no JS. The other one that I've been playing with lately that I really want to spend a little bit more time with is iOS development. ERIC: For me, lots of what I'm trying to pick up right now is actually business side like marketing, landing page stuff. Do a little bit of stuff of Redis and basic key-values type stores. CHUCK: You mean you have to know business stuff to do business stuff? EVAN: Ah, yeeaah...? CHUCK: Alright. Well, should I go and order this time, Evan? Eric, what are your picks? ERIC: [laughs] Okay. So my picks, there's 3 of them, I'm not going to go over a lot of them. But basically, I guess this past week or two, I started changing a lot of my passwords around. The password scheme that I had before, I've just got tired of it and wanting to get something more secure. So my 3 picks this week, there's an "xkcd" that talks about passwords and how you can just strengthen them, if you noticed the "Correct Horse Battery Staple" one. The next one is the link I found. Basically, you'd type your password into, you can just make it up, but using -- I don't know, the algorithm -- but it basically figures out how large of a search space the password would be so if it's a common word, it's obviously going to be easy to find. But if it's Correct Horse Batter Staple, it's going to take (what is it?) 1.24 hundred trillion trillion sensories to crack given like something that's even faster than what NSA has. So that's a nice little thing to check the algorithms or kind of how you're doing your passwords. Let's say it's all local, obviously you don't type in "think password" into website of such as your banks. And then the third thing I came across, it's called the "Diceware Passphrase" system, or whatever. Basically, you actually use physical dice and roll them however many times and it basically will kind of generate a English real word language password for you. I got the hint from one password and last pass, they talk about how to create good master passwords and this came up at right there. It's pretty neat because it's very very random and it's supposed to be pretty secure; the more words and the more dice will you make, the more secure it'll be. I'll put the links in the show notes. It's very very technical stuff, but if you're thinking about doing password, I recommend going through these to kind of see how they work. CHUCK: Alright. Evan, what are your picks? EVAN: I guess I'll pick a couple of iOS apps I've been using lately. I've been using the "Mailbox" app, which is a kind of interesting email replacement. It has some GTG like features where you can take email and say "Remind me about this email in a day, a week, a month, or few hours", and then it goes out of your inbox for that period of time. So, it lets you get through at inbox zero (and that's a big deal to a lot of people) pretty easily just by shuffling around things in terms of importance. So I've been loving that; it's completely free. It's just that you'd probably have to wait in line in order to be able to use it and it's only on iOS. JIM: Has it changed the way you use your email? Or, you just kind of kicking the can down the road? EVAN: No, actually it has changed the way I use my email because ordinarily what I would do is I would take the important ones and I would them in my to-do list and then they would often languish there. And being quite honest, my to-do list doesn't get 'to-done' as often as I would like it to be. Whereas with Mailbox, when I have something come up later, well I always see that because I check my email for like impulsively even if I don't check my to-do list as compulsively, so it's actually been pretty helpful for me. And the other thing I've been using lately is a calendar replacement called "Fantastical", which really is just a better UI on top of the built-in calendar. It allows you to very easily browse whole days and then has a much better month for you; and that's also fairly cheap and has a nice user interface. You can also enter appointments semantically, but I don't think it plays with Siri other than you can schedule events toward the normal Siri protocol. But (if) you can't do it, then that whatever...you know what I mean [laughs]. Or, you don’t… CHUCK: [laughs] Alright. So those are your picks? EVAN: Yeah. And I also like to pick the shoe, which I'm eating right now while I'm trying to describe Fantastical. [Ashe laughs] CHUCK: The shoe that you're eating? Is that a well-done steak? Or, it's your foot in your mouth? EVAN: Well, I think it is a leather upper, so yeah. CHUCK: [laughs] Alright. Jim, what are your picks? JIM: Alright. I've actually prepared this. I'm usually get to the end of the show and think "Oh, no! I forgot to get some picks!" So I read a blog post this morning titled "How Much Sleep Do We Really Need to Work Productively?" and it's great. I've been very interested in tracking my sleep; I used to have a fit-bit that would help me track my sleep and then I lost that, and then I bought a new one, and then I lost that one. [laughter] JIM: Actually, there's another one I can't remember the name of it...you wear it on your wrist. Anyways, it's supposed to be very good about waking you up at the right time, but I can -- EVAN: Jabba. JIM: Jabba, that's what it is. Well, that's the company, isn't it? EVAN: Yeah, that's the company [inaudible]. JIM: They have something, so I'm going to try and check that out. But, I've been jealous of my kids who nap and they have barely care the world and I would love to work naps back into my day, so I'm planning on working on that. And then, I just recently purchased and started reading "The Visual Display of Quantitative Information" by Edward Tufte. So far, it's a great book. I have a graphic design background and displaying lots of data is something I'm really interested in. And hopefully, I'm going to be able to pull some ideas from it to put into my book as well. But so far, (it's) a great book. Those are my picks. CHUCK: Awesome. Ashe, what are your picks? ASHE: I have one that is not at out recent, but somehow have crossed it last week [inaudible] this past week on Twitter. So I'm a Vim user, I've been a Vim user for about 2 years and somebody posted on Stack Overflow this gigantic list of like their "Most Productive Vim Shortcuts" that aren't very well-known, and it's a huge less and it's gotten over almost 3,000 Plus Ones on it so it's really good. The second one is "UX Apprentice", which is a scented the folks behind Balsamic just released. It basically walks you through what you like, say, all the different steps, who should be involved, the kinds of things that you do, software that you might think about using, books you might think of reading. So I thought that was really neat. UX is something I'm trying to learn more about this year. And then the third one is a book called "Wool" by Hugh Howey. It's a science fiction novel just kind of written in an interesting way. It's set up as a serial so there are 5 or 8 like short stories in the serial. He released them one by one on Amazon, and it's one of the better science fiction stories I've read in a long time. I really enjoyed the fact that a lot of the main characters are women that are written really well; they're written like actual people. And that's what I've been impatiently waiting for our science fiction book club to pick up because I'm not to talk to people about it so badly. CHUCK: You have a science fiction book club? ASHE: I do! EVAN: I should actually show before those one of these days... ASHE: Yeah. I really love science fiction in general, and I wanted to start a book club and a lot of my friends aren't in Madison where I live. So I've invited anybody who wanted to participate. We have a Go Group and then once a month we go hang out and discuss the book. CHUCK: Oh so this is one I could actually attend? ASHE: Yeah! CHUCK: Ohh...Alright, I'm going to be harrassing you a little later. [Ashe laughs] EVAN: That's if there are enough spots in the hang out because the hang outs keep crowded, don't they? ASHE: It just depends. Like last night, we've talked about an Arthur C. Clark book that we just read, and we had 4 people. So sometimes they're really crowded, sometimes not so much. CHUCK: And you get to hang out with Ashe. ASHE: There you go! CHUCK: Alright. So my picks, my first pick, I was looking for a new game because I got a little bit tired of the games I had on my iPhone, which is really the only thing I played games on anymore. And I found this one, it's called "Robocalypse", I guess it's what it's called. It's an interesting game; you build buildings and then the buildings build units and you go and fight. It's got this story that's supposed to be funny and clever that isn't quite so funny and clever, but it's nice to build a bunch of robots and then say "Go, kill that thing over there". So I've been enjoying it, not so much for the storyline, but just for the fact that I have something on my phone that I can build and play and stuff. So, yeah, I think that's the only pick I've got. I'm too tired to think of anything else [laughs]. Anyway, I guess I should actually tell you about another podcast that I just started if you're interested in iOS development. If you go to "iphreaksshow.com", it's not up yet but it will be up by the time this is released. Yeah, go check it out; it should be on iTunes by then, too, so you can pick up the show and start listening to it if you want to hear us talk about programming for iPhone, iPad, that kind of stuff. And with that, I guess we'll wrap it up. ERIC: Take care! JIM: Thank you! ASHE: Thank yah! EVAN: Byee. CHUCK: Yeah. We'll talk to you guys next week!

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.