The Freelancers' Show 103 - Working with Other Contractors

00:00
Download MP3

The Freelancers discuss working with other contractors.

Transcript

CHUCK: What is the drilling over there, anyway? REUVEN: At 10:20 at night, I don’t know. I'm not sure. I'm guessing as to which neighbor it is, but I could be wrong. CURTIS: [Inaudible] adults only on the show, so I'm not going to talk about what he’s doing at night. CHUCK: Oh, jeez! REUVEN: [Laughs] God! [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [You're fantastic at coding, but do you have an action plan to take it to the next level? The upcoming book, Next Level Freelance will help you optimize your freelance business for happiness. The book is packed with actionable steps to make more money, case studies, tips to find more clients and exercises for you to establish your desired lifestyle. Extras include nine interviews of freelancers who make great money while enjoying great work-life balance, videos on strategies to find quality subcontractors, and videos on making more free time by outsourcing your daily tasks. Check it out today, nextlevelfreelance.com.] [This episode is sponsored by Planscope. Planscope is a project management and collaboration app built for freelancers and the way they work with clients. It makes it easy to price up new estimates, and once you're underway, helps answer the question, “Will this get done on time and under budget?” I've been using Planscope to do my estimates and manage my projects, and I really, really like it. It makes it really easy to keep things in order and understand when things will get done. You can go check it out at planscope.io. ] CHUCK: Hey everybody, and welcome to episode 103 of the Freelancers’ Show. This week on our panel we have Reuven Lerner. REUVEN: Hi, everyone. CHUCK: Curtis McHale. CURTIS: Good day. CHUCK: Eric Davis. ERIC: Hi. CHUCK: I'm Charles Max Wood from DevChat.tv and this week we’re going to be talking about being on project teams with other freelancers. Now I'm sure that you guys have done this before; I'm not the only one. Do you have good stories or bad stories? CURTIS: Both. REUVEN: Yes. ERIC: Yes. CHUCK: I was going to say the same. Have you been the project manager on any of those? CURTIS: On the one I'm working with currently, I guess I kind of am because they just hired their in-house guy who started in the last couple of days, so I had been running the development side mainly and facing with the one person on their end. ERIC: Yeah, it depends. Do you mean the official title-bearing project manager, or the one who actually manages the project? CHUCK: Either, or. CURTIS: I don’t have the title but I've been kind of overseeing all the development up to this point. REUVEN: Yeah, I've been doing that. I've got a project right now that I'm working on. I'm managing a guy who works for me and someone else in another country, and sort of pulling it together. So, yeah. CHUCK: Yeah, I've had several projects where I've been managing the project or managing the people on the project and it’s always interesting to see where the challenges are. Let’s talk about some of the issues that we run into with this. Curtis mentioned that he had an issue with somebody that he is or was working with. CURTIS: Yeah, so right now I'm on a project. I was busy for a bit, so I wasn’t on it full time, I was just on it part-time and they hired someone to help augment my time – because I didn’t have a lot – who doesn’t know PHP, doesn’t know WordPress, and doesn’t know version control at all. Really. So that is my “augmentation,” which, at this point, costs me more than it helps me at all. REUVEN: And your client, presumably, too. CURTIS: Oh, yeah. I mean, sure, they're paying him. I have no idea, but they're paying him, but they're paying me. I know what they're paying me, and they're paying me to tell him how to checkup branches and how to write a super basic WordPress plugin. CHUCK: So what do you do in those instances? How do you handle things like that? It’s a little bit different if it’s your subcontractor that’s incompetent because you can fire them [crosstalk]. CURTIS: Yeah, which is what I do. So now they have one person on-site. He seems very good; he just started, but the questions he asks, the knowledge transfer questions, not like ‘how do I do a foundational thing.” CHUCK: Right [inaudible]. CURTIS: So I am thinking that once we get a little farther, a few more steps with the guy that’s in-house, so he’ll be taking – he’ll probably do a bit more of my role as he learns more or as he gets up to speed on the project that I will probably have a talk with him and then the official project manager and say, “Hey, this other guy’s costing us a lot of time and not giving us a lot. It takes me longer to do things – he’s working on something for three weeks that I've told him how to do three times, in 12 minutes, when it was finally my time, I fixed it.” REUVEN: Have you been asked by the client at all to evaluate this guy’s performance? CURTIS: Nope. I was away for a little bit, then came back because we had the baby. So when I came back and he said he needed time, and he said, “Oh by the way, there's a new guy.” And I went, “Oh. Okay.” I can only find out that he’s really into Lord of the Rings. That's the only thing I see about him out there. CHUCK: [Chuckles] Nice. So one thing that comes to my mind, too, is you could also, depending on how you invoice and track your time, is that you could put it on your invoice, ‘spent two hours explaining to so and so and such and such, spent another hour explaining another thing to this guy,’ and so then you can actually point that out on the invoice and say, “You realize that it cost me six hours today, or this week.” CURTIS: And I've done some of that because I've only had part-time weeks, or a couple of days up until this week. I have done that, like cleaning up this aspect or cleaning up this aspect after the developer, or doing that. They haven't done – like that’s probably [inaudible] of my time, when I only had a little bit of time in the last few weeks, just cleaning up, and teaching him how to do things that I think are pretty basic if you're hired to work in WordPress, right? So now I'm back to weekly, so I don’t really count for my hours so much, so they won’t see that necessarily at this point. REUVEN: And they might see it as a plus, at least in the beginning, that you're helping this guy out and giving him some instruction. They might be less pleased if you're giving him instruction in very basic things, and you're doing it repeatedly. CURTIS: He might be a good developer; he just doesn’t write any of the languages, or anything that we work with. He works in C or something and Ruby. [Inaudible] those Ruby guys, eh. CHUCK: [Chuckles] Those Ruby guys. One thing that I've also done, I've been pretty straightforward usually with my clients and so I just let them know. “Look, this is going to extend your timeline by this much, and it’s going to cost you this much more because I have to babysit him.” I'm usually a little nicer about that, and I give them all the caveats, “obviously, it’s your call,” blah-blah-blah, but if you can show them that it affects the bottom line a lot of times the clients would just go, “He can learn in somebody else’s time.” CURTIS: I'm kind of hoping today would do that, say the thing that he’s working on for three weeks, I fixed in 12 minutes and got a little frustrated on the column; we’re still trying to talk about how to do it. I said, “It’s one line of code; I've given it to you. Why isn’t it in yet?” I also look at the commit log and I've seen that for three weeks, I am the only person who committed any code at all and think, “Really, guys?” REUVEN: Where did the rest of the code go? CURTIS: That’s a great question. I know the one guy who just started, he was very part-time as well and he’s working on a rather large-ish feature, so it could be another branch I just didn’t look at or he hasn’t pushed or something, and that’s fine. But yeah, that’s a great question. I’ll just pull and see what everyone’s done and there's nothing. In fact, I think the only – the first amount of code he’s pushed today in a special branch because he’s got a broken plugin that I will have to go fix now, that I gave him most of the code for off the bat. CHUCK: That’s nuts. CURTIS: I agree! I'm kinda stuck. I've been working for them long enough, this company, since September, that I think that I can probably approach the main project manager and say, “Hey, here’s some problems that I'm having and I think we can do this better.” You don’t wanna go in and say, “This other person’s a moron,” right? “Let’s just get rid of this person because he’s a moron.” REUVEN: Why don’t you go in and say, “Look, the way things are working right now, this is not to anyone’s advantage. Maybe if you will do the following tutorials or concentrate his time on some other part of the task or something, then after a month or two he can get up to speed, and then he’d be able to do the things you're asking to do.” Although if he’s really not getting the super basic things, then that might point to bigger problems. I think [inaudible]. CURTIS: And it might just be that he’s never done WordPress, so he just wouldn’t know how to write a plugin, right? But that’s when we’re working in it that you would assume you hire someone that can. CHUCK: Well –. REUVEN: I haven't written a WordPress plugin, and I know that there must be just a gazillion tutorials out there for how to do it. CURTIS: That’s right, but when someone said, “I’d like to hire Reuven to do my WordPress project,” I would say, “I really like Reuven. He’s a good programmer. He does not write WordPress though, so he’s going to have to learn how to do that.” Right? REUVEN: Right, and that’s what I do with my client. Just yesterday, I was talking to a guy who wanted me to do some back end stuff and maybe some angular js as well. I said, “Listen, I've been working with JavaScript for a while; I'm sure I can pick – and I've played with angular; I haven't done anything serious with it.” He said, “Okay, that’s not a problem, but I'm glad you told me.” If you say it straight out, you're okay with it usually. But if you come in as the expert in that, or as a professional in that, there's a minimum level of competence you're expected to have. CURTIS: Yeah, and I have no idea what discussion they’ve had. I just know when I was introduced, they said, “Hey, this guy’s an amazing developer. Someone in marketing says they're amazing. And this is who you're working with now,” and I said, “Oh, okay.” I did a quick search, and went, “I hope it’s not the guy who’s really into the Lord of the Rings,” because that’s the only thing I could find about him. There's nothing else that says he works in WordPress at all. I don’t even see anything that says he works in programming, at all, and when they said, “There's this another guy that we’re bringing in [inaudible] Oh yeah, he does a bunch of WordPress stuff and he’s written for [inaudible] Magazine and stuff.” He’s probably quite good, right? He probably has a good head start on everything, and it will be more knowledge-transfer or things like that than anything else. CHUCK: Yeah, so it’s kinda out of your hands and that kinda sucks. I'm curious – I wanna change the topic a little bit. Have you guys worked with a guy that goes in and is kind of a cowboy? He seems to know what he's doing, but he just kinda goes in and recklessly does stuff, or does things that’s not the way that they team does things, and things like that. ERIC: Mm-hm. REUVEN: Yeah, I've got a project now, it’s a little tricky because basically I was approached by a company to take over – me and my employee will take over their extremely large Rails application and our first task was to upgrade it from Rails 2 to Rails 3. And I said, “Look, that’s a lot of work; that’s a big application. Maybe we can work with the current outsourcing company with one of their developers, and we’ll all work together, and we’ll do this upgrade, and then we’ll take the code over.” And everyone thought this was a fine and good idea, and we were moving forward, and basically the guy for the original company who has been working on it for the last few years feels a very strong sense of ownership, and feels that some of the decisions I've made, I have just been wrong. So after we make a decision, or I make a decision, and I say, “We should do x” and my employee implements x – or vice versa, my employee implements x and I say, “Yes, that was the way to go.” He goes in at night and changes the code back to the way he thinks it should be. So that’s been difficult to manage, to say the least. ERIC: Yeah, I got one even more than that where I said, “We should do x,” had everyone on the team, except for one guy, say “X looks good.” The one guy said, “We should do y.”Wwe said, “Okay, well, we’re not going to do any kind of consensus here. Let’s ask the project managers.” Kicked up to the project managers and the project donor; they all agreed x is the best thing. We did x, that guy went in later, changed it to y, and then made the excuse, “Well it’s already changed. We can’t change it back to x.” [Laughter] CHUCK: It’s [inaudible] really easy. ERIC: It ended up great. The way it worked is that it ended up not messing up data, but it stored data in a way where now you have to [inaudible] it to get back to x, and so once it was in and running, we couldn’t go back and it actually caused the exact problems that I brought up why we wanted to do it our way. But hey, I mean, maybe he had something else, I don’t know. CHUCK: I've worked on a project where one of the other guys on the team, we kinda get the word down, but we wanted a particular feature and he’d come in and he’d be the hero. He’d be like, “I’ll totally cover that feature, and we’ll get it done, and you guys just keep plugging along on the other stuff.” And then three days later, he’ll come – he’d like, disappear. Or he’d come back and he’d be like, “Alright, I'm bored with it now. Somebody needs to finish it.” REUVEN: Oh, my God. CHUCK: And it’s just like, “Why do we have you here?” If you wanna be the triage guy, and you wanna go out there and you wanna get stuff out of our plate, out of our way, then, fine. But finish it. ERIC: Yeah, that guy sounds like a real ninja developer. CHUCK: Yeah. CURTIS: As in he disappears well? ERIC: Yes. REUVEN: Deadly, but deadly to the project. I had something, I guess this is about six months ago, where I was called in similarly to sort of take over from, or start working with some other consultants who have been working on it for about a year or so, and then maybe slowly but surely take over the code. And the code was just horrible. The code was horrible, the configuration as horrible – everything was horrible. And the deeper I got into it, the worse I thought it was. And so finally, after complaining for a while, they hooked me up with the guy directly, because we’ve been sort of talking indirectly in various means. And so I also had these Skype conversations with him, where he basically insisted, “No, no, no. The way I'm doing it is totally the right way to go. I can’t imagine doing it any other way.” And so I was already sort of not sure if I wanted to continue working in this kind of relationship, even if eventually I was going to take over the code, and then they basically solved the problem for me by paying me late. And I said, “Okay, I'm out of here.” And I can’t say that I regretted it, and I would be shocked if they'd actually launched given the state of affairs when I left. CHUCK: I had a similar situation where instead of kinda being brought on to be brought up to speed to take over, they had basically let the other guy go and hired me to take over, and he was impossible to get a hold of. And so all of the pieces, all the parts of this code that he had touched was just totally a mess, and I couldn’t get a hold of him to have him explain to me what he had been trying to do, and they couldn’t explain to me what they had wanted then, because it’d been done so long ago. Eventually, it was just, “Okay, well, just tell me what you would like it to look like now, and we’d figure those features out, but some of that knowledge transfer would have saved them days or weeks of work. Have you guys taken over projects that have been built by larger firms? I've taken over projects that had been built by Hash Rocket, [inaudible], which are both big Rails consultants here in the United States, and it’s always interesting to see what they’ve done and how they do things. REUVEN: No, I don’t think I've ever done that. My dreamy vision is, Wow, if I had written code from there, obviously there’d be no problems at all. But the reality is, their consulting company, they hire people from all sorts of different shapes and styles and experience levels, and at the end of the day, they're just trying to satisfy the clients’ product needs, not necessarily make amazing code. ERIC: I have a friend who used to have a very good business going, and then cleaning up after – none of the agencies we’ve mentioned, but some large Rails agencies who didn’t launch very well, and he'd made good money doing that for a number of years. CHUCK: Yeah, and I mean for the most part, these consultancies put out good code, it looked nice, but sometimes they made decisions I think based upon something that they had cargo culted or that they had written themselves, so there were a few things in there sometimes that were just like, “Okay, you could have done this in half the work if you had just used this other library, or if you'd just done this a little bit differently.” But it’s a lot easier, I think, to critique somebody else’s code especially if they're not working on the project anymore. CURTIS: Yeah, but we all do that type of stuff, right? I write a solution that I like until someone says, “Hey, here’s a way better one” and I agree, and I just keep using it. CHUCK: Yeah. ERIC: Well, not just that, but I mean it could also – it’s what they don’t know if they don’t know. Maybe they’ve never heard of that library, or maybe there's – they had to implement in half an hour, so they fell back on cargo culting because they couldn’t research that. It’s hard to really critique what you get because there could be a historic factor; there's a lot of personal relationship stuff that’s kind of built around the code that you may not know. First, it’s something you're enliving right now. That’s something you kinda see that at play and understand why some decisions might not be the best decision but they're optimal for what you have. CHUCK: That’s true, that’s very true. REUVEN: And even the best the code basis is going to have some weirdness in it. I mean, this project that I just took over now, I'm taking over from this company in the Ukraine, where I looked at their code, I didn’t give it a fairly strong [inaudible], “This is pretty well-structured and nicely done and has a reasonable number of tests and so on and so forth.” And yes, overall, it’s done very well [crosstalk]. Right, right. Except for the crazy monkey patches that they do in there. And oh yeah, it’s also dependent on the hosting that you have in DNS and all sorts of other little things that add up to nothing terrible but just frustrating to deal with sometimes. CHUCK: Yup. One other thing that I've seen with consulting firms handling our projects is that I did some work for a company that hired different consulting firms to the different parts of their app, and that doesn’t necessarily make any of them wrong, but it also makes things inconsistent between the different parts of the code. And it’s nice to have a consistent style and a consistent way of solving the same problem, and you just didn’t get that form one piece of, one part of the app to the other. And so you'd have to figure out how one group reinvented the wheel and have another group reinvented the wheel. ERIC: Yeah, that schizophrenic [inaudible]. CHUCK: Now one problem that I've seen with several of these multiple consultants on the same team is communication, because everybody has a different way that they prefer to communicate with both the client and with other developers. How do you guys usually solve those problems? CURTIS: On the project that I'm working on now, we’re all using Trello for project management and then Skype chats for our communication. We have a group for it, the DevTeam, which is project manager and me, and you have the two developers. CHUCK: So you just standardize around tools and say everybody has to use these? CURTIS: Yeah. The only issue I see with what we have right now is the one developer who’s not really pulling his weight, asks all the dumb questions on a private chat just to me. CHUCK: [Chuckles] ERIC: Yeah, that’s hard. I've been in that where someone in one channel appears very intelligent, but then in a back channel, you can tell they have not a clue. And it’s like, “Well talk about it in public so we can actually see how you really are and you have this fake face on.” CURTIS: Yeah, that’s totally what it is. Asking me a question in the other channel when I have mentioned it in the group channel, he’s like, “Oh, let’s just take this offline.” “Okay.” Even in the call we had earlier today, same thing. I started to talk about something, he’s like, “We could just talk about that after; we don’t need to kill everyone’s time on that.” And the project manager’s like, “Okay.” ERIC: Yeah, what I like to do is either put in a project management system that’s completely visible to the entire team or use email for it, either through a mailing list or just having people CC as it appears in FYI-type of emails, basically keep all the communication there. And the thing is, if you and that guy go off on a rabbit-hole to, so you don’t waste anyone’s time, at the end of it, you would then email the entire team, “Okay, here’s what we talked about; here’s the summary.” So everyone at the least can stay in the loop, or if they need to look back at it later, “Why is it that this guy has been working here 10 months, why can’t he still get it?” And then they trace the history and see that he never actually knew it in the first place. But I mean, I've always worked with smaller clients who are very transparent, very – everyone on the team pulls their weight, and so it’s a little bit different for me. CURTIS: Yeah, you'd think with three people it’d be obvious where weight’s pulled or not, but we shall see. REUVEN: Yeah. One of my daughters was doing a school project just recently and she was complaining that not everyone was pulling their own weight, and I told her that my software engineering class in college, we had three people working on a project. We’re divided into teams and I had to work on a project, and one of the people in my team was not pulling her weight. And so the other two went to the professor, we complained. He said, “Well, this is a class in software engineering – teaching you how to deal with the real world. In the real world, you will work in teams where not everyone works equally well, and you still have to get the job done, so, off you go!” I don’t know if it was the nicest lesson, but it was a true-to-life lesson, that’s for sure. ERIC: Yeah, I had a class like that, and I got frustrated because we were supposed to just make a project plan for doing something, but the professor wasn’t very good at it and it sounded like we’d actually implement it, so I ended up trying to convince people to do it. They didn’t do it. They didn’t do it. I ended up making the project plan and implementing the entire CMS website and gave it to the professor. He’s like, “Oh, I actually just wanted a project plan, but hey, you'd get an A anyways.” And it ended up like I did all the work. I didn’t care because I knew what I was doing so it only took a few hours, but you know, you're always going to run into, you're always going to have people that don’t know what they're doing or they don’t care or they just, for some reason, they're just not able to do it. I know one person, she wanted to help but she actually didn’t know enough and for me to get her up to speed it would have taken twice longer than the assignment. CHUCK: My experience with most of those class projects or groups projects was that part of the assignment was actually getting a review of everyone else in your group, and so it became pretty apparent that somebody wasn’t pulling their weight because everybody else in the group basically said, “Oh, someone didn’t do anything.” But I don’t know if there's a good correlation or if there's something that’s like that in the real world. REUVEN: I've found that using a task tracker makes that pretty visible pretty quickly. There's a project I was working on years ago where I had, it was three of us working in my company, working with a bunch of their programmers in-house, and they were constantly accusing us of taking extremely long time to do things. And we were like, “No, no, no, that’s not true at all!” And so finally we installed a task tracker, and immediately those problems disappeared because it was obvious that actually we were doing things on time and we would click it off as being done, well, there was no denying it. We at least said we have done it, so we needed to check it. So I think you can remove some of those problems through more transparency and more communication.  [Crosstalk] CURTIS: And one thing that in theory Trello can do, it doesn’t have to get stats to do that though, right? We have cards assigned to other developers and I am the only one that’s continued to move cards into the ‘Done’ pile for evaluation. I have actually moved their cards into the ‘Next Deploy’ pile at any time. A couple times, if you’ve done a couple deploys and put [inaudible]. ERIC: And a lot of that comes down to the project manager has to know what they're doing. Like I said earlier, the official one or the one who’s actually running it, because I've seen developers hoodwink project managers and say, “Yeah, it just turned out really tricky and [inaudible] story.” It’s maybe an hour-long project, maybe a 15-minute project that they spent three calendar weeks on. And a good project manager will spot that and be like, “No, you told me it would take a day. Why aren’t you doing it?” And after enough occurrences of that, that person gets let go or moved to a position where they can’t affect the project.” REUVEN: Yeah, I've found that a combination of three things tends to increase transparency. One of them is take a tracker, job tracker. I've tried Trello a little bit, based on Curtis’ recommendation and I have to try it a little more, but truth be told, it really isn’t a matter of what you’ve got, so long as it’s clear what the tasks are and everyone’s buying into that, so that’s number one. Number two is having some sort of daily standup, just so you can sort of know what people are working on, and make sure people are moving ahead. Because if Joe says – not to pick on people named Joe – but if Joe says, “I'm working on x.” And every single day, he’s working on x and he’s not making progress, that’s a pretty big sign. And then as you guys mentioned, having some sort of open chat room also where people can be very obvious about what they're working on and if they're stuck, they can ask for help. I think the combination of those tends to weed out some of the, shall we say, slower workers, or encourages them to try to get up to speed. CURTIS: I mean, that’s basically like business management 101: track what you're doing, make sure what needs to get done is actually getting done, and have communication so that if there is a problem, you can take action. That goes as far back as people have worked together. Tools like modern tools obviously help, but you can do that in a paper. I know a company that does [inaudible] using just index cards on an internal window. They use basically the same process you described but with just paper and talking in a face-to-face meeting. REUVEN: Yeah, I told on this project that on this project that we’re getting from Ukraine, the guy who works for me is a Russian speaker. I thought it was great, we’ll be able to talk to each other in Russian. And there were all sorts of like mutual accusations of various things from both sides. So I said, I kept begging him, “Please, please, please, guys. Put it all in the public chat room and then I’ll know what's going on and I won’t be surprised.” So one morning, I opened Skype to 200 messages in Russian, so that didn’t really help me so much, but the thought was good. CURTIS: So you need to learn Russian – that’s the take away, right? REUVEN: Yeah, yeah, yeah, that. Exactly. CURTIS: For me there are some other issues I mentioned, like our standup often ends up being an hour, and I'm sitting there with my feet up, because we’re sitting around for an hour talking about screen sharing and trying to do things, [inaudible] everyone’s just watching. So there's four people watching the screen share, which is not a standup proper I know. REUVEN: Oh my God. I mean, I was never – and this is probably a good thing – I never got any sort of formal training in Agile and standups and so forth, but I was fortunate enough to be part of an international team probably five, six years ago already, where the person who’s running it was I thought very effective at showing us how to do standups, where they're quick to the point, make sure everyone’s moving along, and if you have to go into more depth on discussion, that’s great – we’ll set up another meeting for that, but that’s not what we’re doing now. ERIC: Here’s the scenario, because this, I think, a lot of freelancers are going to run into. What if you're in a project where you're working for a client and the client either has a subcontractor, or sorry, he has another contractor an employee working for them, and that person, to you, you can tell they're incompetent, they don’t know what they’re doing and it’s not just your bias. You actually know they're making mistakes and you can point it out. How do you actually go to the client to tell them about it? Or do you even do it at all, or just kinda let it go? CHUCK: I think it depends a lot on the client; some clients will be open to that, some of them, “Well that guy’s been working for me for 50 billion years and I just can’t let him go.” Or they think the world of him because they just don’t know any better. Those are hard because you're effectively telling them something that they may not even believe is true, whereas if they're open to that kind of thing, then it’s a little bit different. REUVEN: Yeah, I agree that it depends on the client. I think I tend to try to be subtle with my hints if I think that they're really bad. I can’t really remember any particular examples of this, but I think it would be more like, pointing out the questions that they’ve had, or pointing out the time that they took to do things. And if it’s once, if it’s twice – fine, that’s part of my sort of summary report and I send it out to everyone, but if turns out the same person is taking a long time all the time and asking all [inaudible] questions all the time, then it’s not my job to decide whether he/she’ll be fired, but at least the manager has the information they need to come to that conclusion. CURTIS: Yeah, see I always – I don’t know, just kinda like tattling in some ways although I suppose they pay me to do that, right, to make sure that we’re efficient? REUVEN: Right, right, I definitely found more and more over the years that part of my role in coming to these companies is they see me as someone who has experience, and not just experience in the technology, but in what can be expected for someone at a particular level. And so, often they’ll ask me what I think about someone, and I try to be nice, but I also have to be honest. CHUCK: Yeah. I have another scenario that I've run into, and that is, I was on a team with a bunch of other contractors and for the most part, everybody on the team kind of had an area that they would just kind of go to and work on. I was never really sure where to jump in, and so eventually I wound up just leaving the project because I couldn’t any clear direction I want to work on, so I wasn’t billing many hours, and I just wasn’t sure what to do there. Do you have any suggestions for that kind of a situation? REUVEN: That comes down to direction too, right? Over the last three weeks, I've been saying to one developer, “This is your task; you need to do it.” And that's my direction to that. We also have a list for the ‘Next Deploy’ coming up and the tasks on their cards in Trello that we can get done then. So, if you're out of things, just jump in there and grab the next one, or ask questions about it if you can’t, you know, you're not sure. ERIC: Yeah, it’s [inaudible] like that project was very [inaudible] and each person worked in their own little area and there wasn’t the benefit of a good project manager that kind of say, “Well Chuck, we’re going to have you either take over your own silo or you're going to jump around and give you the resources and the ability to actually pick up work from people. CHUCK: Yeah. REUVEN: Right, right. Someone should be giving direction or at least giving the heuristics for how to choose something. So like, this project now, that’s my guy and this guy from Ukraine. I didn’t want to start assigning tickets to them. I just don’t feel like spoonfeeding that, but I asked them, “How are you guys dividing it? How would you like to divide it up?” And they came up with a solution or a system, which I thought was more than reasonable, and they more or less stuck to it. That sort of gave them a good feeling and empowered them, it reduced my workload, and the things were done, I think, pretty efficiently. So you should have – an ideal situation I've had someone to whom you can go and ask, but there also should be that same person who would notice that it wasn’t clear what you were doing, or that you weren’t billing out any hours, and try to take advantage of your skill set. CHUCK: Yeah, and I kept pushing that and eventually I’d get one of the project managers who’d come in, “Well, can you work on this?” and so I’d get it done. But I’d wind up waiting days between three to four-hour jobs to do. ERIC: Yeah, what I did with a client is I told them “I'm available this week; that’s what you paid for. If you can’t give me work, like if I'm sitting idle, that’s your money being wasted.” And that motivated them to give me plenty of backlogs to start working through, and when I finished through that, they're like, “Oh.” So I just start grabbing things I have to do.” But that goes back to proper planning and actually being on the ball of stuff. CHUCK: Yeah, that makes sense. ERIC: I mean, that’s the thing. We’ve talked a lot about the contractor and employee doesn’t – they're incompetent or they're not doing their job, or they don’t know their job, but I mean it also works for managers and people running the project. I mean, not all jokes about, management stuff aside – it’s a hard job to do, but if you can find someone that knows how to do it, they're gold to the project. REUVEN: I think the guy that we have on the other end doing tons of managerial level stuff is very good at insulating developers some random crazy request, but as far as keeping some things moving forward, we’re having issues right now with that. ERIC: Yeah, and there's – I don’t remember the distinction, like I got a lot of the software management stuff from Microsoft side, but they have a product manager, like a program manager. One level is the more technical – like passing out tasks, figuring out dependencies – more of a project lead, but not as much coding. And then there's the other side, which is the more business management, which is where you hide the developers from the business side. You work with the potential customers or clients, if you got what they need in the software, that sort of thing. And a lot of times, when you have the resources, that’s two separate people just because the skill sets are different. CHUCK: Yeah, so I wanna kinda change gears a little bit. If you wind up managing the project and you're making the decisions as far as what tools to use and what approaches you wanna take, Agile or not Agile or whatever – what's your preferred tool set? What kinds of solutions do you tend to lean toward? ERIC: I think we did this in our show where I was ranting about Agile. There’s basically two kinda fundamental ways for me. One is, for the most part I follow something called the Chaos Theory of Management, which is it sounds really chaotic but it’s not, it’s the weird thing. Basically, it’s work on the most important thing. When that’s done, work on the next most important thing. At the Wikipedia page, you can read it in about five minutes and you get the entire concept. And then the second part is, I'm adaptive. If a client’s doing Scrim, I’ll do Scrim. If they're doing capital A Agile, I’ll do capital A Agile. If they're doing Waterfall, I might kind of try to make it not as, like try to limit the disadvantages of Waterfall, but I’ll do Waterfall with them. And a lot of that’s because I try to make it so I could fit in with their organization so I could get the stuff done, instead of fighting the organization. And so I guess what comes out of that is, whatever tools they have or that they wanna do, that’s what I’ll use. I might suggest like, “This one might be [inaudible] for these reasons,” but I don’t push it. If they don’t wanna use it or the migration cost is too high, then we don’t do it. REUVEN: Yeah, I also –. For ticket trackers for instance, I’ll typically say to a client, “If you're using something already, then I’ll use that. And if you're not using something, then you could just use either copy of Chili Project running on my server,” and we just use that and it’s more than good enough for our purposes. And if they say, “Well, is there anything else out there?” Then I can go through a few different options then say, “You can pay for this, you can install that” and then I’ll leave them at their hands. But I would say at least half the time they already have something they’ve got running already, so there's no reason to install or start with something new. CURTIS: Yeah, lots of my clients don’t have something already, so I push them to Trello mostly in the past, although I may be changing that in the future. ERIC: Yeah, and I have iOS standards so that the client doesn’t have a bug tracker, or they don’t have a real-time chat system. I say, “Here’s what I use with almost all of my other clients; this is my recommended tool.” And then I might have a couple other ones if that doesn’t fit for price scale or whatever reason. But I don’t try to push it; I just like, “Here’s what I use, I have the most experience, here’s you're going to get the most [inaudible] for your buck out of it.” CHUCK: Yeah, yeah. I like that approach. And I’d been playing with several different systems; I think I finally settled on Redmine for my project management and I tend to use Skype for my discussions though I had been trying some of the other ones out that are out there, that provides you different chat rooms or whatever. But yeah, there are a lot of options out there for the little things that you can do. REUVEN: Yeah, I found that so many of my clients use Skype, that setting up an IM chat room on Skype is pretty natural even if they're not necessarily used to using it for that. Pretty quickly, they get up to speed on that and I think they see it as useful thing. But I use other systems too. At the end of the day, as long as you have some sort of live chat, I feel that really does add a lot to the communication among members of a team, especially if they're distributed. ERIC: Yeah, and I mean, I had a client who –. I'm in West Coast US and he was in Switzerland and we ended up going all the way back to just using email, and at the time we were using Redmine. And so basically those were the two systems we used and maybe once a month we would have a phone call, which would be like early his morning or late, late his day and that would be just to kinda go over stuff where we would like, lines were getting crossed on text chat. It was a half-hour talk and that was it, and that project ran for two or three years – I don’t remember how long. It was a pretty successful project for how little communication tools we use. CHUCK: So are there any other techniques or tricks or tools that you can use to make things a little bit simpler when you're dealing with other contractors? ERIC: A big hammer comes in handy. [Chuckling] CHUCK: For their hands or the keyboard? ERIC: It depends if they're typing too much or not typing enough. CHUCK: [Chuckles] ERIC: I mean, I always tend to go on the lower side. It’s easier to add tools than to remove them, because you always have one or two people who, “I have to have this tool” and so if they have to have it then it tends to [inaudible] the whole team, and it’s really hard to take tools away from people when that’s not working for the team as a whole. And the other thing – it’s a processing I found is, if you're having problems with people just communicating an idea or anything, go to higher fidelity. I work at home; I don’t really go on-site to clients, but I've had a client where it was just much easier just to fly up and just sit down with him for half a day than it was to try to talk to him over the phone or even video chat and try to get the ideas across. Never be afraid to kind of accelerate that. Just say, “Hey, we need to have a phone call. We’re not making this work with this tool.” REUVEN: Yeah, yeah. No matter how good the tool is – phone, or if you want Skype chats – like actual voice communication are still much better for nuance communication and really getting to the fine points. ERIC: Yeah, and there's a [inaudible] can pick up even just in voice, “Well I think that’s a great idea?” or “I think that’s a great idea!” Same words, completely different meaning. CHUCK: Yeah, makes sense. Alright, anything else to add? ERIC: Since this show kinda got started on you're in a bad environment, I always bring this out because a lot of people are afraid of it. If you're under contract with someone, make sure your contract, you have a way to get out, because you can always just fire the client and walk away. It’s kind of the atomic weapon method of getting out of there, but if you're in a really toxic place, you can’t make it better, it’s probably better for you, your sanity and all that stuff just to get out and just let them be toxic on their own. REUVEN: I could not have said that better or more strongly. Absolutely. I think I've now fired two clients, three clients, over the last number of years, and each time I was nervous about doing it, and after I did it, I was so, so, so relieved to have gotten out of that rat’s nest of code and behavior and problems. ERIC: And if you're too scared to do that, see if you can just let the contract lapse without renewing it, and just say like “I wanna pursue other opportunities” or some other non-committal answer and just let it go when it’s done. I know it hurts especially to the pocket, but you're probably better off without a toxic environment. REUVEN: I should add also, the most recent client I left, these guys who had bad coders and they didn’t pay me on time. So I called the CEO and said, “Look, I’ll be leaving your project” and he was completely and utterly stunned. I said, “Listen, I'm not trying to be mean about this, and I don’t want to screw you over, and I will try to help you out and make sure there's a transition. There's another developer; I will talk to them, I will talk them. If you want to bring an in-house, I will talk to your people in-house.” And I ended up going in for an hour or two to their office; I did not charge them for it just to do that certain transition work partly because I felt like this was the right thing to do, and partly – and this is a little self-serving – Israel is a really small country with a very small high tech area, and you don’t want to get a bad reputation. At the end of the day, that’s what we’ve got in the freelancing world – our reputations. So I definitely feel good about having finished that project, but I also feel good about how I did it, that I left on at least a semi-positive note. CHUCK: Yeah, that makes sense. Alright, well let’s head into the picks, shall we? Curtis, you wanna start us off with the picks? CURTIS: Sure, I'm going to pick a new backpack that I got a while ago from Mission Workshops. I do a lot of cycling, and this is a waterproof messenger bag but it is better than my old Chrome bag because it has a full laptop compartment in it with enough room for my iPad and enough three pockets on the front of it for a bunch of other things. Plus, it has a huge compartment, although it says it’s about the same size as the old one, I can fit about double the stuff in it. I just rode back from Vancouver, it was about a 60-mile ride, with all my stuff, for six days, plus my laptop and everything else in it, and the bag handled it beautifully. And it’s actually from the original owners of Chrome who sold Chrome a number of years ago. CHUCK: Cool. Reuven, what are your picks? REUVEN: So I got three picks for this week. Number one is, I can’t believe I've been using Python and teaching it for so long and never discovered it until about a month or so ago – Python Tutor at pythontutor.com – it is amazing. You enter code, and then it [inaudible] you through it one line at a time, drawing graphically all the variables and how they work into various variable scopes. And I found in teaching my classes, it has been, first of all, much, much, much easier to read than my handwriting on a white board and of course standardized. So even when it’s thoroughly complex, it works, and there are a few variants of this Python Tutor that also work in other languages. So for instance, there's a Ruby version and a JavaScript version. I’ll put in a link to the main one in the show notes and you can go the other ones from there. Second one is I've been trying to monitor my weight, even lost some weight recently, and I read years and years ago the Hacker’s Diet Book. I'm not convinced that the book as like a strategy for losing weight or maintaining weight is the best one, but the online tool is actually really great. It gives you a nice running average and it sort of averages our weight in the last week, and the graphs are free and available and cool and nice to use, so I definitely recommend those. And the third one is, as I'm sure everyone has heard, the new season of House of Cards is out on Netflix, and I am totally, totally loving it. I really love politics and I love these sorts of dramas; I have to agree with the reviewers who said that it goes way into the fantasy realm, like Washington couldn’t even – even our worst nightmares, it couldn’t run this way, but that doesn’t make it any less entertaining, so I definitely recommend it. If you need something to do, if you have nothing to do for 13 hours, go watch this. That’s it for this week. CHUCK: Alright. Eric, what are your picks? ERIC: I've got a few today. One is iOS game I've been playing called New World Colony; it’s basically a strategy game. It’s pretty fun; the thing that I like about it the most is it works on iPad and iPhone, but even on the iPhone you can actually play it pretty good, it’s turn-based and all that. And it’s very fun, just [inaudible] for five minutes, play, save your game, and come back later. The next pick is just kind of on topic for the show, I'm gonna link to the Peter Principle in Wikipedia. It’s basically a management theory that says that people get promoted in an organization until they become incompetent. There's a funny one in there by the creator of Dilbert, who basically says that the least smart people are promoted simply because they're the ones you don’t want doing the actual work. CHUCK:  [Laughs] I like it. ERIC: Yeah. I found that it’s probably not that relevant. There's a software version of the Peter Principle that software systems become more complex over time that even the creators can’t understand it. CHUCK: Nice. Well I'm going to throw a few picks out there. The first one, I read the book Tribes by Seth Godin, really enjoyed it. That’s all I really have to say about that. It kinda inspired me to be a little bit more of a rebel, I guess. ERIC: More of a tribal man? CHUCK: Yeah, something like that. We also went out to the Saint George Parade of Homes. I saw a bunch of houses, which was a lot of fun. One thing that I always think is interesting in comparison to the freelancers is that these home-builders, they're businesses that go out and build homes, and the Parade of Homes is kind of their way of showing off their work. And what's really interesting is we always go with my father-in-law who’s a general contractor, and so he’s always pointing things out that  - that’s sloppy, that’s wrong, this looks funny, and this is why – and it really kinda drives home, you know, that the quality, if you know what you're doing, is really evident. One of the other things that I realized during this particular Parade of Homes was that I pulled one of the drawers out in the kitchens, and we were just kind of checking it out, and it turned out that when I felt the underside of it, I realized that that it was made out particle board. If you’ve done damage to anything made of particle board, you know that it’s basically impossible to fix. And it also doesn’t stand up to wear and tear in the same way that a plank of wood. So it was really interesting to me, that even though on the outside it looks terrific and still be made of sub-par materials underneath. Anyway, so yeah, I've got a whole bunch of object lessons out of that, but I'm probably going to be blogging about. But anyway, those are my picks and I guess we don’t have any other announcement or anything, so we’ll wrap this up. We’ll catch you all 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.