The panelists talk about ramping up on client projects.

 

Am I talking into this thing right?

 [This episode is brought to you by Audible. Audible is the first place I go to keep my business skills sharp. They offer over 150,000 books on business, finance, planning and much more. They also have a great selection of fiction that keeps me entertained when I'm just not up for some serious content. I love it because I can buy a book, download it to my iPhone, and listen while running errands or at the gym. Get your free trial at freelancersshow.com/audible]

 [This episode is brought to you by Code School. Code School offers interactive online courses in Ruby, JavaScript, HTML, CSS and iOS. Their courses are fun and interesting and include exercises       for      the       student.        To       level   up      your    development skills, go      to freelancersshow.com/codeschool]

Hey everybody and welcome to episode 126 of the Freelancers’ Show. This week on our panel we have Eric Davis.

Hello.

Curtis McHale.

Good day.

I'm Charles Max Wood from DevChat.tv and this week we're going to be talking about how to ramp up on a project when there's a lot of preexisting content. In my line of work, it's usually code that you have to come up to speed on. Have you guys ever worked on projects like this?

Yup. Yes I have.

Do you want to talk a little bit about what those projects were?

I had one - I guess the biggest one was taking over a fairly complex WordPress site. Specifically, we were working on one widget, which sounds fairly small, but it did a lot of stuff and allowed you to customize the widgets per page, so each page had its own widget area in WordPress. Anyways, I had to fix it [inaudible] because it was broken and the hardest part was that there was zero documentation anywhere, and then there were also no tests, so it was like just coming in and seeing how it worked just from the get-go.

Right. What about you Eric?

Okay, I can think of a few cases where I'd come in where a project didn't have something existing but it's actually majority of the time there's something already there. With Redmine, that's like a big one; it's 50 plus thousand lines of Ruby Rails code, so it's a pretty large application. And even if I was making a new plug-in for someone, I would have to integrate and use existing APIs and some of them aren't well-documented so you have all these legacy burden you have to deal with. I've done some rescues which kind of, based on the fact that they are rescue, you're coming into a project that has code or other assets that are done, and you need to fix up and clean up. I think there's been very few projects where I come in and can start from scratch, and even in those cases, they're typically like additional projects for a client where I've already done kind of, "Hey, we have all these stuff here. Let's just start something new instead of lumping it in to this other category."

Yeah, that makes sense. Well I've kind of done both. I did a couple of maintenance contracts pretty early on, going freelance and so it was a large body of work that had already been done and then I had to maintain it and figure out how things had been put together. I've also worked on a few teams where there was a lot of work that had been done and I was coming into the middle of the project, and finally I've been in the situation that Eric's talking about, working on systems like Instructure Canvas and Redmine, so I've kind of seen a few of these. What do you guys tend to do to get up to speed on those?

Well I've actually just picked up one a little bit ago, so I actually went through my process again. This is all code-related but you can kind of take it to whatever you want, but once you get access to the code or all the assets, you download them, there's typically a couple of major areas where those are the core aspects of the project. For Rails, it's like the bundle or file, if they have stuff in the initializers, and then kind of picking through the models I found is always good, because that's where your database is. That kind of shows how the data's put together and then from there, you can kind of pick through whatever you notice. It also changes, like if it's an API-heavy project, there's going to be a lot in the data; there's going to be a lot in API calls. If it's a more of a frontend, a lot of JavaScript front-end single page app, then I'd probably jump to the JavaScript area, but it's basically I have to go by experience. There's also tools that will help – even in the Ruby world and JavaScript world – that will give you a state of your project: if you have missing tests, you have a good amount of test, you're missing an entire test suite on some functionality, or the code standards, code quality, is not up to snuff in this file or that file. That can kind of point you to trouble spots, which is basically what you're looking for when you first do your eval – what's going to bite you later on.

How about you, Curtis?

That one project I talked about, the first thing I did was actually write documentation for every function in the whole thing so I could even figure out what was going on. That's actually one of the best tools that I found as I become a better developer, is writing the documentation or a DocBlock at the top of each function so you know what's going on.

I also take notes. I have a file I keep open where I jot stuff down like I don't know what this method's doing. I don't know why it's interacting like this and that's more of just for my personal use as I'm exploring it.

Yeah, in my experience – first of all the DocBlocks at the beginning of methods, it feels like clutter to me most of the time.

If the code's bad too then most likely the documentation's going to be bad, so I mean, if you're lucky, you don't actually have any documentation, but I found sometimes they'll lie to you and so the code is one thing and the DocBlock is from a previous version that does another. You have to be careful with that.

Yup, but one thing that I do often with getting involved is I'll ask them if I can be put in touch with the previous developer, and most of the time they have a good enough relationship with whoever they had before that they can come in for a few hours and kind of show me around. Show me what's what and what's where and all of that stuff, and sometimes not. And so then I have to do a lot of the things that you guys are talking about. With the code – and this is very much a code thing – I don't start writing tests right away, but as I'm getting into things and making the changes that they want, I'll tend to put tests around the stuff that's already there, if there aren't already tests. In that way, I can kind of figure out if I broke something because the test passed, and I kind of characterized what it should have been, and so if I change it then it breaks, then I know what broke. But yeah, digging into it is really interesting and I like a lot of the advice that Eric gave, because it's more or less the process that I go through.

One thing that I found useful especially on apps that don't have tests or they're just not documented is to try to write a very high-level test that goes end to end, like ‘this is what it actually does.’ That can serve as a safety net but also I've found that using that with a debugger or whatever just breakpoint space throughout the application, you can kind of see the path of a user as they go through it and so you can see if there's a weird way that stuff's loaded, if there's callbacks or any kind of oddities. And sometimes I don't even check that end, and the test might not have any actual assertions; it's just clicking links and following redirects – doing that sort of thing – and that's just for me to walk through, programmatically, how the application works.

One other thing I've done – because a lot of times there is information out there that isn't necessarily in the code or in the work that's been done – I spend a lot of time talking to the folks that hired me. I'll ask them for things like emails from the past or any kind of correspondence, really. I'll go look through their backlog of git-pushes and pulls and git-requests and if they're using a time - or not a time tracking, a project management system. I'll go look through past tickets and see what they've got there, and get an idea of how it flowed before and what kinds of things were important to them, and what kind of information they put in there. A lot of times, there's information in there about why they built things a certain way or why they did things a certain way that's not in the code, but then as I move forward, I have an idea of where to go from there because I know why they made some of the decisions they made in the past.

Yeah, and that's actually a tool I use a lot. Git, or even if you Subversion – I think almost every version control has a blame feature which actually looks at a file and will tell you who last made a change to each line. So I use that Git History, Blame – all that stuff – to really track through, because sometimes there might be something that's confusing or it looks wrong, but when you go through the history, you understand, "Oh, this was made because they're working around something or whatever." And I myself, I try to put in really good, comprehensive commit messages when I make changes, and so if other people in the project do that too, you can kind of follow what they've done. It's a hit or miss; some projects don't, and like Curtis said, like in the chat, some people don't even use version control, so you pretty much can't use that if they don't use the tool.

What about systems that kind of - Oh, go ahead, Curtis.

I was going to say I've a number that I have no version control whatsoever and the client is coming to me with it, "Hey, this doesn't work." And so I even stepped back to, "When you got this project started, how did you expect it to work?" And they give me a spec way from the beginning of the whole thing and then we sometimes throw out what we’ve had or fix what we had. I did that one for someone that had like 300, 301 redirects, instead of two WordPress template files which would have made everything work. So that's what I did – killed the redirects once I figured it out and added two template files.

That's useful if you can talk to your client or other people in the team. I've done it where I've sat down with the lead developer and said, "Okay, let's make a list of every feature that this system needs to do." And then we compared that to what it did and found that there's some gaps or there's some areas that it's kind of divergent from what they expected, but no one actually sat down and kind of, "Here's the full spec," or "Here's the full idea," so that was pretty enlightening. We ended up passing that around for about a year or so afterwards of like, "Hey, this is a new thing," or "Hey, this actually should be covered by this other feature," that sort of thing. It's just the project got too big; it got away from everyone, I think.

Now if you're coming on to a team that's already doing the work, what kinds of things do you do differently there?

If there's a team there, you're kind of lucky that you can talk to people. You can use chat; you can get on the phone. I've done a lot of screen-sharing where I've walked through stuff. It's a really quick way to kind of bootstrap like if there's no documentation. It's basically informal documentation on the project. I've done that and actually found gaps in their setup instructions and basically pointed out, "Hey, I'm a new developer; I'm looking at this with fresh eyes. You glossed over an entire important section that I lost time on, but if we write it down, it would save the next person." And so especially if it's an internal team, like the staff of a company, getting that written down is good for them, because if they hire another employee, that employee doesn't lose that time. Because that time just gets sunk and once you know the process, you forget to write it down. But yeah, I like using the team kind of as clarification and shortcuts for stuff. And it depends on your role: if you're coming in just as someone to do the work versus someone who's actually going to train the team, that's going to depend on how you're going to approach them.

Yeah, that's true. I found that it is a lot easier to get going because, like you said, you have those resources, the people that are already in the trenches and fighting the good fight to get some of the stuff figured out. I just want to put a shout out to a product that I used called Screen Hero, and that's just something - it doesn't work on Linux but it does on Mac and Windows, and so yeah, I've been able to share my screen. They can actually type on my screen and it's pretty handy to get things going. A lot of times too, if I get stuck, then, “Hey, you know, I'm getting this weird error or I'm encountering this problem,” and a lot of times they can just push you in the right direction. And so you get the little nudge you need, and they can still get the work done without actually having to stop and come and look and see what you're doing, so it's pretty nice. But they're also there if you do need them to come over and stop and look at what you're doing. So Eric brought up in the chat room, getting the app actually running, if it's an application that you're working on. Have you encountered problems with that?

Yeah, like I said a few minutes ago, sometimes there are setup instructions especially in software like Ruby, Rails, or any kind of large system. It's not like you can just download the source code and run it; there are typically steps involved. Most of the time, people try to have that setup in the README or somewhere, like on a wiki or whatever, but there are steps that are skipped, like the README was written six months ago, since that time we've changed things. And so, I don't make it my first point. I actually want to read some of the code that I'm going to be running before I actually get it running, but sometimes it can be a bare. I've encountered issues where they used very weird versions of libraries and system software, like a certain version of the database server that isn't available anymore – it's now taken off the market or whatever. I've ran into issues of, you need to get special API keys from third-party vendors, or you need to get holes punched in firewalls. There's a lot of setting up and getting started things that could happen and I think it's important to do that. Once you kind of feel comfortable with, “Okay, I can see how some of this system works to kind of get the app running.” If you can, in Rails, like starting the Rails application server – I actually tried to do that before I even get the test to run, because tests are usually flakier, but if you can get the app to run, then you know you have most of the dependencies handled. Once it's running then you can poke around with it, and then you can start working on tests or whatever the next step to getting bootstrapped is.

Yeah that makes sense to me. One thing I'd add to that is a lot of times, I'd get things running and then, in Ruby on Rails at least – and I think in most other systems – they keep a log of what's going on, and so once I have it running, then I'll run through some of the routine stuff that it's supposed to do and watch the log and watch what floats past. That way, I can get an idea of what it's doing and it's a really good way of seeing, "Okay, these are kind of the core classes or core areas of functionality in the app."

Yeah, and I mean Curtis [inaudible] but I've had problems – because I've done a little bit of WordPress development – but I've had problems where a plugin was built for a certain version and you're now on a different one, and so the underlying APIs have changed or whatever. The plugin might start working, but it doesn’t actually have all the features where you got this big, blank screen or weird errors like that. That’s kind of the process of getting it running, getting it where  you can kind of see what's going on, and it could mean your development version needs to be downgraded or it could be that the software itself needs to be upgraded to work with the latest one.

I actually had one using a Vagrant box, and I had to use SaltStack to build it, but then the SaltStack had actually changed and then Vagrant had updated two or three versions, and to actually get it running for myself, I had to, in theory, roll back my virtual box version and my Vagrant version to an old one that wasn’t supported with the rest of my development’s installs and then I could run their server theoretically. I did not continue with that project because it was crazy, but –.

And that time Salt was brand new, so I'm looking around for information on it, and there was nothing. There was very little written about it and even less written about it in the context of how we were running it, and it was pulling from their live server only specific blocks in a multi-site install and the guy was too busy to continue working on it, that’s why the original developer wasn’t working on it.

That’s funny. I've run into things where, in the setup, they specify different versions of Ruby or different versions of Rails just from one project to the other, and the setups and the APIs just aren't completely compatible. One’s from another, so you actually have to almost isolate them and run them in different environments and things and do funny stuff. That kind of thing has gotten better, but at the same time, sometimes it’s hard. I am kinda curious – Eric, you were talking about how they have documentation on how to set it up but that documentation is out of date. Do you wind up requesting access to their documentation system so you can update it, or do you do that in your own system? And if they don’t have documentation, what do you do?

It depends a lot on the project. In this specific case that I'm thinking of, their documentation is scattered in the actual README, kind of a plain text file in the code, and then it’s also on a GitHub wiki. They gave me access to all of that, but what I did was I talked to them. “Hey, your docs don’t look like they're correct; I had to do this extra step. Does that sound right or am I going off on a different track?” and they're like, “Oh yeah, we glossed over that.” What I'm doing is I'm going to change the README in the docs, because that’s the canonical way to get it set up. Since that’s tracked in git, I sent the changes to them, they’ll be in the project; everyone who gets it from then on will have it updated. In the past, I've had companies where the wiki was the canonical source, and so they'd give me access to that. I would edit it, put my changes right in there – sometimes I even have to write a whole, new document. Once it was done, the client, they're like, “Hey, there's new docs on how this new server’s set up” or whatever it ends up being. The nice thing – or at least what I try to make sure – is that those docs are searchable, so when new team members come on, they can search for ‘I don’t know why it’s doing this’ or whatever. I don’t catch the docs, so sometimes I’ll actually link the docs; I've even made a  quick start thing for people who know what they're doing, like if you're a Rails developer, you know how Rails works, but here’s the 1-2-3 checklist of getting started, which is like, set a bundler. You’re a Rails person, you know how to do that, you just do it, but then item 5 would be, “Now sign up for this third-party API keys. Make sure to get this kind, not this kind, and put them in this file,” where it’s a bit more detailed because it’s more app-specific at that point.

Yeah, that makes sense. If you get to pick the documentation system, what do you do?

I like the README sometimes because it’s self-contained with the code; it’s very easy to keep it insync, and everyone who gets to code gets the README. I think most developers I know will jump and look at the README or an install doc to see how to get set up. That said, the wikis are typically more accessible; they're a little bit easier to manage and you don’t have just one file. I've seen READMEs that are a couple hundred thousand lines long, like people just dump everything in there. It’s a pain if you don’t know what you're looking for; you can’t jump through it. So if the project has a lot of documentation, I tend to do the quick start or bare minimum in a README, and then point them to a wiki of ‘here’s the complete stuff’, or ‘if you have problems, here’s how to troubleshoot it.’ It also helps too if you have non-developers writing documentation. That way, you don’t have to give code access or git access to change the README; they can just do it on the wiki.

Yeah, that makes sense. What about you, Curtis, how do you manage documenting stuff?

I write a full DocBlock for every function, say, probably 95% of every function in there, all the time and we can generate documentation out of that if we want. For longer-term documenting, especially user [inaudible], I will actually record a screencast for my clients so they can see it longterm in their dashboard. Outside of that – there's a bit of a README in them, but there's not a ton past that.

Yeah, that makes sense. When you're trying to get ramped up on a project, do you try and do phone or Skype calls, or email? What seems to be the most effective way to do it?

I think it depends on the savvy of the client, right, who you have access to. In the one where I had all the broken redirects, I talked to the client; I said, “This doesn’t work” and I dug in after that. The developer was totally AWOL because they couldn’t do it and that’s why I just dug in myself; there was not much past that. On other ones where we’ve had to do more, I guess, almost to discovery then it’s [inaudible] email and back-and-forth, and then I actually produce a report of all the issues that we need to fix before we enter into any new work, typically.

Yeah, that makes sense. If you're starting a new project, do you tend to create a lot of documentation for whoever’s coming after you, or for the most part do you just not worry about it?

That really depends on what we have. When I set up a custom Vagrant box, I write out all the install instructions so they're copied and pasted in a README file and so the next developer that comes in can clone the box, clone the repositories they need and get running [inaudible], so it’s essentially a tutorial for them. And then I have all, say, my function and code-level documentation as we go, like even when I build a WordPress plugin or something with WooCommerce, it’s all set up so that if we deactivate the plugin, WooCommerce goes back to work in how it should. Or if WooCommerce is turned off, all the plugins that I built that rely on WooCommerce turn themselves off too and give you warnings all across the top of the page, saying, ‘this is all turned off because WooCommerce is not around anymore.’

So one more thing, I think we've all had the experience of working on open source projects – I mean, WordPress is open source; Redmine is open source; some of the other things that I've worked on – Spree and Canvas are open source. How do you come up to speed on those?

Pretty much the same process. I've noticed a lot of open source stuff tends to have more formal docs, or they have nothing at all. They might have a mailing list or forums or stuff like that; most of them now, I noticed, have wikis or at least a few wiki pages. It’s the same thing; I mean, I go through the README, I’ll go through that documentation; if it’s a Rails app I’ll look at the gem file, look at the routes, look at the models. I think it’s the same process; the only kind of difference is you don’t really have someone you can call – you can’t call your client to talk about it. If you know the maintainer or you know people who work on it, you can always ask them, but a lot of times you kinda need to really assemble your thoughts and post to a mailing list or something and then kinda take a bit of flack for oh-you're-a-newbie type of thing.

Which is retarded.

Yeah. Anyway, that’s part of the [crosstalk].

I don’t have a lot of contribution to WordPress Core, because when I first started – in fact, I do zero contribution to WordPress Core, because when I first started I asked some questions and got that junk and I almost left the WordPress community because it was just retarded. I would never choose to spend my time with people that treat me that way, so why on earth would I do it for work? And then I found out the people that were not morons. You can tell my opinion on that. I know WordPress now has a flags tickets in Trac, which is what they use for all their bug tracking called easyfix. It may be a decent amount of work, but it doesn’t touch all over nine parts of WordPress. It’s contained; it’s one fix in one spot, so you can do it, you can do the test. And they even do a bit of a mentorship program where you can get current core contributors to help mentor you through those fixes, so they're doing much better than they were before, because before it used to be – basically, I got called a moron and an idiot.

Yeah, and I've been on the other side of it – not calling people that – but I've seen a ton of new people get started and asking specific questions, or asking general questions, and it’s hard because as a maintainer or even a top contributor, you want to help people, but at the same time, that takes up a lot of your time. What I've done on projects is kind of make a getting started guide for developers or how to contribute and try to give people a bit of process, and so even if I don’t have time, I will be able to say, “Hey, I'm sorry I don’t have time to help you specifically, but here’s the document to get it started. If you have a specific question, feel free to post a new thread or whatever.” But it’s hard to balance the ‘here’s the information you need; I am not an expert on this system, so I don’t know exactly what problems you're going to run into,’ and then bounce that against the one-on-one help for everyone. There are a lot of people that want to help but then they burnout and they don’t do it, so you can't invest all that time on one person.

I know one of the projects I contribute to, WP eCommerce, has full documentation on how to get the repository, how to put a patch up or pull your request in GitHub and all of that has the whole workflow on how to add to documentation, which is very helpful to anyone starting out.

And I’ll put the link in the show notes, too, the guides we made for ChiliProject. There was one section that’s about how you do you – if you want to contribute code. It’s like a six-step process, but if you want a longer, more in-depth version, it’s a whole another wiki page. That’s kind of how we documented that.

Yup, very cool. Any other thoughts related to coming up to speed or helping other people come up to speed on new projects where there's a lot to know?

Kind of what Curtis talked about doing the documentations on each function, I try to take advantage of the time where I'm new to the project and I don’t know stuff to write documentation for the next new person. I just gained this little bit of knowledge, so while I still remember the old me who didn’t have that knowledge, I try to capture that transition from old me to the new me and get it written down, or record it, or however – something so that the next person who comes along, they’d have an easier time. They don’t have to spend two hours learning and running into problems to find the answer; they can just read it and do it in two minutes and move on. That’s kind of – I think it’s the Boy Scouts – it’s like, “Leave the area better than how you found it” type of idea.

Right. Yeah, that makes sense.

Yeah. I just had one recently – actually late last year and early this year – where I knew I was coming in on a very specific set of features and I was also building a development process proper, and then I'm going to be handing it off back to their internal team. I made sure there's a lot more documentation for that so the internal team gets the ‘how we did it’ at that point, and I know since then they’ve changed something, which is just fine, of course, because it works better for them now. But there was a huge amount of documentation and wiki pages and we used Bitbucket, so it has a wiki built right in and a whole bunch of information built there so they could continue to take it long term. Again, the whole series just taught us how to work with the code that you have and the system you have now.

I think another thing – developers think about it, but I don’t think other people do as much: documentation’s great if you keep it updated, but you're still doing stubs by hand. What I've done on the past few projects is some of those stubs I've actually written to a script, like a setup script, that would download stuff that you need. It would copy files, set up stuff, so instead of you going through 10 stubs manually and accidentally forgetting to do five, the setup script does all of it for you. So you sit down on a computer, run it, and you're ready to go. Kind of the advantage that you have, as the creator of that git, is if you ever script your system or need to reinstall, or if you're using virtual machines or stuff like that, you can go from ‘it’s a fresh install’ to ‘I'm set up a lot quicker.’ One project I worked on, I ran that script probably every week. I was working on a remote server, and so I was able to kind of delete the server and start over. It was nice to know that I have everything set up, I'm good to go; there's not some weird thing that's going to screw me up in two hours time and make all my work go away. Automating and scripting some of that stuff is pretty easy; the time [inaudible] is amazing, especially if you track it in and let other people use it too.

Yeah, they're really handy. You see those in the Vagrant files and Docker files depending on how you're setting stuff up. Also, Chef recipes and things like that.

Yeah, a lot of stuff I even [inaudible] just Bash scripts. I've used all of those – not a lot of Chef – but they're focused on one specific thing. Well there are some times, like in Rails, you pretty much want to create your database, migrate it, [inaudible] of data, do a bundle install – some of those things you're going to do multiple times, not just when the system gets set up. My setup script usually handles all that, and if you do it the right way, you can have it skip over one-time stuff and just do stuff that you continuously do, like bundle install or whatever.

Yeah, that makes sense. It’s interesting that a lot of this information can be held in places that aren't specifically documents, per se. You have the Bash scripts or the Docker file, or the Vagrant file or whatever you're using to get set up. The information in there is basically what you need to get it set up. You have information in the tests; you have information in the code itself. You can document it the way Curtis was talking about where you put information around what you put in there so the people know why it’s there or what it does. None of these really qualify as documents per se, but they are informational if you know how to utilize them.

That’s the whole point – it’s executable documentation. It’s documentation that you can run and have it either do something or you can see the output of. When you drill it down, that’s the whole point of unit tests and automated testing, is that you have this documentation of how the system should work and you're running that documentation and proving that it either works or it doesn’t work. I mean, if you want to get really meta, you can probably think about code that way too, but I don’t want to get there right now.

Yup. Have you worked on any projects that aren't, strictly-speaking, code projects where you had to ramp up on things?

Yeah.

And is the process that much different? I mean, we talked specifically about code, but –.

One project I did was more of a business process type of project where the company needed help with their development process and they do training for developers, that sort of thing. The [inaudible] concepts are pretty much the same – you kinda figure out how they are doing things now, what the existing setup is, maybe try it once or twice. If it’s a business process, you run through doing invoices once to see how it works, and then talking to them and figuring out, “Okay, how do you want this to be?” and then the project was kind of a transition from where they are now to where they want to be. I think it’s the same thing; depending on what it is you're doing, you might need a lot more interaction. Like in that project, I was talking to people every day; it’s not like you can just go off, play with the code, figure out how it worked and then come back later. You're basically trying to load as much knowledge into your head as you can so that when you can talk to people you kinda get a good idea – you can do the mapping of where they are to where they want to be.

Yup. One other thing that just came to mind was when I do estimates and things, a lot of times there's a lot of information tied up in that, so by putting the information into the estimate or putting the information within easy reach of the estimate –. I get an email and I can put some of that information in there to kinda say, “I'm estimating it this way because of this concern” – that also is information that can be passed along to whoever comes next.

Do you mean estimates like a proposal for the project, or estimates like –?

Yes.

Okay. For that, when I do proposals, I don’t do them very frequently but I will try to write out the different big blocks of it, and those are – I estimate inside of those. In each of those big blocks I’ll describe what it includes, what it doesn’t include and all that. If I had my choice, I'd actually do that in my project management system, and so I'd do a lot of the breaking stuff up, estimating in there. Then if the client’s like, “Yes, let’s get started,” all of that’s there and those estimated blocks are actually just tasks that I would start working on, and so it’s like ‘here’s the list of requirements and we’re good to go.’ Sometimes if it’s more interactive, we’ll work back and forth on one of those tasks and kind of refine it like, “Well you said I can’t do this; let’s make it do that,” even if it changes the estimate.

Yup. Alright, let’s go ahead and do the picks. Curtis, do you want to start us off with the picks?

Sure. I'm going to pick just something you can do, which is dishwash your keyboard. I have tossed my keyboard – many keyboards – into dishwashers. Make sure you take out the batteries if it’s wireless and stick it on the top rack, let it run through the rinse cycle; let it dry. I have to let my Kinesis Freestyle dry for a week – or two weeks actually – to be totally dry and then it works fine. I've been doing that for years; I've saved a few keyboards from full coffee spills or a whole can of pop dropped on them. The first one I tried was it hit delete and get the E key – on the opposite side of the keyboard, right? That was the first one I tried and it works great.

Huh.

Washing machine and dryer might work too if need it faster. [Chuckling]

I have done it faster. I had one job, like 3:30 on Friday, my boss spilled their whole cup of coffee with sugar on their Apple wireless keyboard. We pulled the batteries immediately and I went down and stuck it in the dishwasher right away, in the top shelf, and ran it through the rinse cycle, and then used an air compressor to dry it out faster, and we used it Monday. It was fine; no problem whatsoever. I've done it with tons of different keyboards.

That’s actually why having a backup keyboard’s good in case you need to clean one.

That’s crazy!

What, that you can do that?

Yeah!

Well, I've done it for years; it’s great! I have my backup Freestyle Kinesis coming soon, actually. The last time I washed this keyboard, we were going away for six weeks, so I dishwashed it just before I left, stuck it on the bed and came back six weeks later, plugged it back in and kept going.

Yeah, that's nuts. I don’t know if I'm brave enough to stick my keyboard in the dishwasher.

I'd stick your keyboard in the dishwasher.

Mm-hm. Alright, Eric, what are your picks?

Alright, so I got two picks. This first one, it’s the copywriting book from Ittybiz, who I've talked about on the show before – a really great marketing and copywriting person. This book was actually off the market for a while; it’s on now. I don’t know if she has taken it away, but the URL has shhh – it’s like one of those ‘don’t tell everyone about it.’ I think this eBooks, along with the Copy Hackers series, have been the best copywriting eBooks I've ever read, and I've read through a bunch of them now. Literally, the title is Copywriting For People Who Categorically Do Not Want To Be Copywriters When They Grow Up. It’s a good one if you need a little bit of copywriting for products or your business or whatever. I highly recommend it. My second is kind of relevant to what I was talking about earlier about scripting your setup, is the utility called Docker. It’s basically a system platform or whatever to build container-ized applications or whatever. It’s kind of weird to describe, but basically you can build mini virtual machines. I like it because I've tried to use Vagrant, I've tried to use other VM machines and all that to do developments, so I can work completely isolated from my main computer, and Docker’s the first one that actually worked for me, and it’s actually really performant. I'm actually using it on a project right now for client end, and it’s amazing to just hop into that, work on stuff, I screw stuff up, I exit out, rebuild it in two seconds and I'm back in with a clean slate, so it’s pretty amazing. I think I just did 1.0 a little bit ago, so if you haven't tried it out, now’s a good time to try it out. I haven't used it in production, but as far as reproducible development environments, it’s great.

Awesome. We did an episode on Ruby Rogues, so I’ll put a link to that in the show notes as well. I'm going to pick a couple of things; one of them is Screenhero – I've mentioned it before. Screenhero is just a handy tool; like I said, you can share screens, you can click on another folk’s’ screen if you're sharing through Screenhero. It doesn’t work on Linux yet, but they are coming out of beta and will be charging for it soon, so it will be a paid product that I think is awesome and I want to give them some attention, so that’s what I'm doing. Also, just in general, I want to point out that GitHub – so I guess this is my other pick. GitHub has a lot of the features that we’ve talked about here. They have issue-tracking, which I know some people actually use for their project management, and they have a wiki in there; you can do READMEs and most text formats and it’ll show it with headers and formatting and everything else, so you can do it in Markdown or Orgmode. Overall, GitHub is a great place to go if you want to get started documenting this stuff and putting information in. They also make the git commits pretty easy to read, so all in all it’s a great resource if you're going to be working on stuff to do that kind of thing. So yeah, those are all the picks I have, so we’ll wrap up. Thanks for coming guys; we’ll catch you all next week!