|
Make sure Rob tests his code and gets it reviewed before check-in. Don't single Rob out, though -- make the process universal. If the lead programmer complains about the new process, make it as minimum a burden as possible, and make code quality the focus of the process. The lead programmer and the third programmer can review each others' changes, and Rob will need one of them to review his changes, which might improve communication between them, and make Rob look better. Rob may be stuck not knowing what to do, or unmotivated because he does not see a future in his work. If this is possible, then give Rob work which directly impacts customers (internal or external), even future customers not yet realized. If Rob is working on something which doesn't impact customers in the form of a product or service, this may be demotivating, and he may not know what to do next. Even if he's told what to do, if he doesn't see it having any real impact on the customer product or service, then he may be demotivated and may not be able to prioritize his work correctly. Rob needs feedback, whether in the form of code reviews, direct communication, or in the form of comparing his work against customer requirements. If the requirements are unclear to him, or he cannot mentally connect his work to customer requirements, he may be stuck or unmotivated, even if he's very bright and has been assigned specific tasks. |