HN Explorer

How to teach a new (remote) developer your application?

3 points by devan ↗ HN
Hey,

I'm a hacker and a designer (a rare breed apparently) I've developed a fully working prototype of my application and I've finally found a developer who's probably just as excited to work on it as I am. Which is great since i'm a sole founder.

How do i go about teaching him the system, how everything works, the logic etc... also taking in the consideration that he would be working remotely.

I suppose i tried to do as much as i could on my own to avoid this situation, but i need another pair of hands.

What would you recommend? I know it's probably going to be a tedious task, but it needs to be done.

6 comments

[ 4.9 ms ] story [ 23.3 ms ] thread
timrobinson
Give him bugs to fix. Make them small enough that you don't have to give him an excessive amount of supervision, but large enough that he gets exposure to a few parts of the application.
yannickmahe
I'd do exactly that, and work up to evolutions. Some handholding may be useful when working on logic, but apart from that most developers don't need anymore to get up to speed. That's assuming they know the underlying technolog, otherwise I'd start with tutorials for that tech/language/platform.
mfrye
What's your budget? Smart and experienced developers can pick up these things very quickly.

I have ran into the same issue before when I opted for the $20/hr on an overseas developer thinking he should be experienced. He knew how to program and can write textbook perfect code, but I spent over a week hand-holding before I gave up on him and made no progress.

Round two, I spent over $60/hr for an overseas developer. I never looked back, hands free.

devan
Well i'm 19 and using my student loan to fund my servers, so my budget is pretty low ha.

He's a pretty talented developer, i've been viewing his code on github. He's happy to come aboard, but we haven't agreed on any terms yet. I'm not really looking to outsource work to developers, i'm looking to build a team together.

bartonfink
Personally, I prefer to learn a system by working on it instead of studying it from the outside. Bugs, except the most trivial ones, are great for this because you have to walk through the system to sort out cause from effect and you can't help but learn as you do that. If you don't have bugs, you can get some mileage out of utilities you've always wanted but haven't had time to write (maybe you want your code to use a new function to generate a standard window title). The key there is not just doing the discrete work (the function), but the weaving it into existing code.

However, occasionally I'll run into a ? that I can't answer myself directly from the code I see (a good example would be a message queue where I only have access to the producer or consumer). For that, I either need some external resource, whether it's someone to ask ?'s of, or documentation to read or even a fair amount of time to see the whole system working together.

Probably the least effective method I've run into is having someone try to walk me through a system. Very few people are able to explain a system from soup to nuts without taking their own knowledge base for granted. If you do decide to do this, the best method I've found is to treat the explanation as a series of problem/solution pairs. Keep reframing the discussion in terms of a conceptual problem, and then point the code that solves that problem. You can drill down as needed, and the constant reframing gives enough breadcrumbs that it's easy for an outsider to follow.

eengstrom
'who's probably' isn't a very strong statement of enthusiasm.

Your best bet is for one of you to travel to the other and hack for a few weeks and sleep on the couch or floor if necessary.