My Experiment with two untested Software Developers: Week #1

Last week, I wrote about Finding Software Developers

TL;DR version: Skip the lengthy interview process in favor of “speed dating” style interview. Hire the developer if they have a positive can do attitude and immediate availability and let them prove their ability with real work deliverables.

What I didn’t reveal was that I hired two developers the day I wrote that article. These are Ruby on Rails developers in remote places of the world. I had posted a job on upwork.com that looked like this:

Within four hours I had almost 30 applicants for the job. Of those, I saw five, perhaps six I was very interested in talking to. Nearly all the first round applicants’ hourly rates were roughly $30/hr. Which was surprisingly low, knowing what highly skilled U.S. based developers earn. So I started down my usual long, involved hiring process described earlier to pick the best candidate to hire. I didn’t use rates to separate and rank — I looked for best cover letter and matching skills to start.

I spent almost sixtotal hours interviewing and hired one of the five for ten hours as he said he could fix a problem I’d shown him through sharing the code-base during our interview process. I hadn’t quite had my Eureka moment to abandon this interviewing approach at the time, but the actual hiring decision served to spur a radical change in my approach. Heck, the guy said, “give me 10 hours to show you” and I liked that.

The next day, I had another 60 applicants for the job.

Geez, now what?

I can’t interview all these guys. What, oh, what have I done now??

I took a deep breath, got some coffee and reflected on how I was going to approach this entirely unexpected problem. Then I had an idea. Are the developers at the bottom of the rate pool any good at all? Back at my desk, I sorted the entire list by hourly rate, lowest to highest. The rates ranged from $5/hr to nearly $50/hr with the bulk of the pack around $30/hr. Next question: “Do these developers speak English fluently?” Their cover letters gave me a clear indication exactly who understood my job post clearly and addressed specific points in my post.

Then I looked at their experience and skill set. Not believing the rates I was seeing, I decided to reach out to them via Skype with the sole purpose of satisfying my curiosity, “is $X really your rate?” The guys with ultra-low rates made it clear they wanted to work with me and that their advertised rate is half their normal rate and only for a couple of weeks so I can try them out.

That’s when I had my Eureka moment. Let’s just throw the work at ‘em and see what happens. I went down the list in increasing hourly rate and picked the first guy that felt was understanding me very clearly in the Skype session and opened the source repository to him and threw him into my #slack channel, and we got started. All within 30 minutes of initial contact. I was happy. I also couldn’t believe I’d just done that.

But the thought kept bubbling? “Is it really this easy? His rate’s so low that, even after we go to full hourly rate, I have enough room in my budget for two developers at this rate. Then it hit me, hire another guy now.

An hour later, I had another guy on the team, into the code, and with tickets assigned.

What on Earth have I just done!?

Hurdle #1: I’m the bottleneck now!

Whoops. I couldn’t put the tickets together fast enough. The project wasn’t yet conceived well enough that I could just assign a bunch of tickets to a major area of functionality under development and just roll with adding more. I needed to think about the overall project and develop a very clear vision of what I wanted to build. In short, “get it out of my head and down on paper.”

So how did I manage the gap? Two ways:

  1. Started a mini-education with my developers. Gave them homework on better coding practices/standards to read up on. I also fed them two or three YouTube videos from recent Rails Conferences to watch and learn.
  2. Found current feature implementations I didn’t quite like and had them do the clean up. This one was easier than new work/feature, but more challenging than #1. These tickets mostly involved cleaning up style or fixing some non-railsy implementation of some feature or wrapping some test around features I had built, but didn’t spec with tests.

Hurdle #2: Working as a Team

I’d been flying solo for five years now. I’d forgotten the good habits necessary to lead a team. As a leader, you have to establish a vision for your crew and make sure their work pipeline is filled at all times. You also have to take care of your crew’s feelings and sense of belonging to the team and bring them into the culture. This is totally different from being the guy who not only figures out the problem and approach to solving it, but is also the one implementing it. There’s a lot of steps one just doesn’t have to think about or put out there for public consumption.

Now the stories have to fully reflect what’s in my head. The goal is to become hands off enough that I simply describe the User story as what we want the feature to do and not worry about implementation details. But the entire team is fresh and don’t know me. I have to show my team in the beginning what my standards are and not allow them waste time on “the easy path” (a.k.a. get it done as fast as possible with no test and unreadable code), so I’m front-loading the stories with implementation details I wouldn’t normally spell out.

Hurdle #3: Reviewing Code

In other words, just keeping up! Both of these developers are churning through the User Stories faster than I anticipated. I have to read unfamiliar code in a project I’ve owned for a while and decide if it passes muster or needs more work. This is a different way of working altogether and it is forcing me to get out of my turtle’s shell and rediscover team-oriented workflows with the git repo such as Gitlab Flow. For example, the first couple of days, I was reviewing every single commit and that was killing my own productivity. Then one of the developers suggested the merge request feature of gitlab which neatly wraps up the totality of all commits to be considered in one place. Merge requests also have a lot of code review features built in, complete with commenting on individual lines of code. If I reject the merge request, the developer can work out the issues and the whole merge request is updated to latest code for another round of review.

Hurdle #4: What to do About the First Developer?

The first guy I hired charged 3 times the rate of the two I now had on the team. What do I do about it? It was my intent to carry him forward if he worked out. I sat on the decision a couple days while waiting on the first developer complete the tasks I had assigned.

After looking at the first developer’s code, two things became apparent. He was good, but he wasn’t substantially better than the two I’d hired in the interim. Overall, I like the developer, but my reasoning at this stage: If two guys at one-third the price are delivering comparably, I’m better off continuing to work with the two with the hopes of adding a third at around the same lower-rate once I get these present challenges resolved.

Surprise #1: Leadership isn’t Expensive

One of the developers is already showing signs of a being a great team player. He introduced me to merge requests and he’s helped the second developer resolve some issues without prompting from me. And this is three days in. Not three weeks out. All qualities I am looking for. I could’ve interviewed for the typical 90 minutes and still not know this was how this developer was going to step up.

Surprise #2: Both Developers are Ramping up Fast

Both developers have clearly different levels of skills, yet both have ramped up surprisingly quickly on the project and are contributing usefully. So either, I write great code that’s easy to understand (where’s that humble pie, I need some now), or this is the nature of the world these developers are used to as freelancers on upwork.com.

Surprise #3: Guilt

Damn, these guys are cheap. Am I honoring them by paying so little when I’m used to pay up to 10 times what I just hired these guys for? A sense of guilt is with me at the moment, but it’s also the sort of guilt that is getting rationalized away as I come to grips with the fact that where these guys are in the world, the rate they’re earning is SOLID. They are showing every day they’re happy and positive. What I’ve come to understand as I work with them is they want a great team to be on where their efforts are appreciated (just like all of us) and they also much prefer long-term, steady engagement over constant rat-race of chasing new engagements on sites like Upwork. Their half-price introductory period is also their choice and advertisement to me to let them prove themselves. I didn’t ask them to start that low. Their attitude is, “Let me show you my worth” and mine is, “Ok, let’s do it!”

Conclusion

TL;DR: Hiring is always brings surprises and challenges one must solve quickly. Hiring by trying instead of subjectively gauging with long interview process is proving a surprisingly successful experiment for me thus far, but adding team members is far from easy. On the other hand, trying out folks at the bottom of the hourly wage pool makes it very affordable (and cheaper) to see who can deliver the goods.

As I finish this up, the questions on my mind at the end of the week (TGIF):

  1. What’s Next?
  2. Will they both work out long-term?

It’s too soon to say, but I’m optimistic about both. Each developer has his strengths and weaknesses, which is true of every individual. The real trick is me being patient with myself and giving the individuals enough room to breathe. What I will continue to watch for is how they gel as a team overall and how they grow as developers under my guidance.