7

Some months ago I asked the manager to add another developer to our software project, in order to be able to offload some things and parallelise a little more. The new guy is (and was already) a friend of mine.

For the initial period I planned to review his work in order to find mistakes, and I did. However, I found out that I cannot stop. Every time I take a look at his code I find small but evident bugs, just at a glance, and this does not give me the confidence to just trust his code.

I learned to let go about stylistic issues. But now I need him to be autonomous and I cannot ignore those major problems. At the same time, it seems he's starting to rely more and more on my supervision... he's also asking my opinions about the smallest details, which is actually the opposite that I wanted.

I have no idea for the reason of his mistakes, if they're just inexperience or distraction or whatever. What can I do or say to improve the situation?

  • 9
    Some developers, when confronted with a workload problem, think "I know, I'll hire an assistant developer." Now they have two problems. --Not Jamie Zawinski – A. I. Breveleri Feb 9 '18 at 3:47
  • 3
    If you've criticized/reviewed/suggested changes in his code more than once before, wouldn't that naturally make him seek your approval in subsequent developmental situations? – ValarMorghulis Feb 9 '18 at 4:40
  • 1
    by bug do you mean "he hasn't tested it, and it won't work?" or "it isn't the best designed code?" – WendyG Feb 9 '18 at 11:25
  • 1
    "I find small but evident bugs (...) I cannot ignore those major problems" - sorry, but this doesn't add up. Either problems are small (things that can be attributed to lack of attention or experience, which do not completely bring down value of overall work) or they are major (things that are plainly broken and can't be fixed without spending considerable resources). It seems to me that you want him to be exactly like you. If that is the case, you should re-think your goals and create a plan that accounts for differences between people. – Mirosław Zalewski Feb 9 '18 at 13:08
  • 1
    Did you recommend this guy solely because he's your friend? If you needed an extra pair of hands you can rely on to work independently, why didn't you recommend someone you knew could handle the task? Management hiring somebody who's slow on the uptake is one thing, but you recommending the hire makes this a bit more complicated. – Steve-O Feb 9 '18 at 14:32
0

Good that you let go on the stylistic stuff. You can use a code beautifier, if necessary. IDEs like Eclipse let you define code styles & will then format the code for you.

However, don't give ground on variable names, which ought to be meaningful enough for maintainability.

I would recommend you to

  1. automate your interactions with him as much as possible

  2. eventually, push him out of the nest and let him sink or swim non his own (to mix analogies).
    How long do you intend to carry him for otherwise ?

As to "1. automate your interactions with him as much as possible" ...

  • make sure that he is provided with sufficient documentation, which he can consult, rather than distracting you
  • make sure that he understands that compiler warnings are not acceptable. This ought to reduce the number of bugs
  • make him use a static analysis tool (Linter). Ditto
  • point him at Stack Overflow
  • Make him write unit tests (and add anew unit test to cover every bug report).

And, finally, if you recommended (which you do not state you did, but it's a fair enough guess) him because he is your friend and you wanted to him a favo(u)r, consider his a lesson learned. Sounds like you did neither the company who puts food on your table, nor yourself, a favo(u)r.

  • 1
    "You can use a code beautifier" - or better yet: Make sure the new coworker uses one (either manually or automatically) before each commit. That way, there is at least no worry about this part, and there is no worry that past changes to the file are harder to analyze than necessary because actual changes of the content are interspersed (or even coincide) with frequent reformatting commits. – O. R. Mapper Feb 9 '18 at 7:58
  • Sorry, bad English :-) I mean "you can" in the sense of "one can", which rally meant "he can". Thanks for correcting that. The OP should be trying to offload as much as possible. Automating it with commit is a great idea, btw (+1) – Mawg Feb 9 '18 at 8:04
  • 1
    I particularly like suggestion 2 regarding his requests for my opinion. Still need to manually check for issues in the code though, when they're not caught by the linters – Jellyfish Feb 9 '18 at 14:51
  • I am curious as to what code issues he has that a linter won't catch. Is it really that bad? Can you give a (disguised) example? – Mawg Feb 9 '18 at 15:11
  • 1
    Hmmmm, a downvote - after being accepted as the answer - and with no explanation given. Yup, it all checks out; I'm still on S.E ;-) – Mawg Feb 11 '18 at 9:52
7

It might be inexperience, or it might be that his previous work environment prioritized quality differently.

In any case, I've found that a code review process with documented standards can do wonders. Write up the standards together so that he understands what's being asked and feel like he has a voice in it.

Once that's in place, tell him to go ahead and code with the standards in mind, and you'll review it together during your designated review time. Don't forget to do the compliment sandwich so that reviews don't become torture sessions for him.

If small bugs are keeping you up at night, think about putting in unit tests or acceptance tests, or hiring a QA engineer.

One of the things I remind myself is that, barring security issues, I try not to let perfect be the enemy of good.

  • 1
    I'll try to remember that last line. – Jellyfish Feb 9 '18 at 14:55
1

It sounds like you and your co-worker (as well as your manager) need to agree on the level of quality the both of you want to produce as a team, and figure out a process to get there, one that doesn't have your co-worker constantly leaning on you for support.

For instance, you and your co-worker need to come to an agreement about what should be expected out of a task before calling it "done" and moving on to the next task, and you shouldn't move on to the next task until your assigned task is done. This definition of done should include having tested the code to ensure that it meets all requirements and doesn't break any existing functionality. It should also include some level of code review and a code quality check just to make sure that you and your co-worker can agree as a team that the code is worth publishing.

You might think of a few more things to add to that definition, but the important thing is that if something isn't considered done by your agreement, it needs to be sent back and completed before taking on another development task. Over time, this will send the signal to your co-worker about what he/she is expected to produce in terms of code quality, and hopefully he or she will match those expectations over time. (If your coworker's code quality still doesn't improve, it might then be time to talk the situation over with your manager.)

Lastly, if you do find that your co-worker is too dependent on you for things that need to get done, you should probably point him to a few sites (i.e. stack overflow) to find answers to his questions, and tell him that you don't have time to constantly help him out.

Furthermore, from a project management perspective, experience breeds speed; you should expect that it will take your co-worker longer to complete tasks than it will take you. As a result, you should not set your deadlines with the expectation that your co-worker will be able to match your development speed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.