Hacker News new | past | comments | ask | show | jobs | submit login

Let them fail: Second best case is that they fail, learn something, and are either open to suggestions or have better ideas the next time around. Either way, you have to re-do the project. Best case, they succeed, and you learn something.

Second worse case is that they fail, don't learn anything; lather, rinse, repeat. The worst case? They produce a semi-functional failure and you have a shambling horror of a monstrosity to support until you finally give up and resign.

Don't let them fail: Second best case: You mentor them into a failure, but they learn something and you learn something. That's sort of good, right? The best case is that you mentor them into a success, they learn stuff and you have a functional project.

The second worst case is that you beat them into submission and get a functional project, but they resent you for not letting them do things their way; they haven't learned anything. The worst case is that you mentor them into a failure, catch all the blame for it, and they're now mentoring you. (And yes, I'm explicitly assuming that you are ten times as skilled and experienced as they are; this is a very bad thing.)

Now, it may just be my experience, but the best cases on either side are entirely theoretical. I've only personally experienced variations on the worst cases. But, I've also worked in government contracting (that may be redundant). There are a lot of hard-headed, not-especially-competent junior devs out there.

The bottom line is that you should just do it yourself---it'll generally save you a lot of grief.




This exactly.

I'd love to find some way to deal with the politics of the case where you end up with the shambling semi functional monstrosity.

Watching someone who is clearly out of their depth trying like hell to save face while time slips past and the software doesn't improve is very frustrating.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: