How do I encourage a more junior employee to work more thoroughly and do the job properly?

Question

I'm a senior software developer at my employer and I have recently been put in charge of a more junior developer. This is my first time acting as a manager (or even a mentor). I've been tasked to give this developer tasks to do and to generally check the quality of his work. I'm not technically his boss (I'm not paying him and I can't fire him), just a colleague who tells him what to work on.

I've been managing him as best I can, trying to give him tasks that introduce him to the codebase and are also useful to me. Over the past few weeks I've realised that he's really rushing the work and missing big, obvious mistakes. I've been pretty hands-off in this approach. I'm not checking all of his work thoroughly (I don't have time for that!) but I do merge his pull requests and get him to correct things that he messes up.

It's become pretty clear to me that these mistakes are purely due to not working thoroughly enough and rushing through the work. I understand that he's new and probably wants to prove himself to be 'quick'. I was hoping that by me bringing them up he would realise that taking a bit longer to do things thoroughly pays off in the long run time-wise. It's really not a race and he's not going to get fired for taking an extra couple of days to double-check himself.

I don't really know how to approach this with him. If I carry on pointing out his mistakes, will he eventually learn? How do I approach talking to him about it? I don't really want to come across as bossy and telling him how to do things. (Being a team player is something I'm working hard at improving on). How do I encourage him to work more thoroughly while still giving him the space to mess up and make mistakes and learn from them?

Edit: Some examples:
- I'll ask him to go through the code and convert the 5 instances of A to B, and he'll miss 1 of them. So it's not that he's incapable, he's just rushing and missing obvious things.
- He'll have syntax errors in his pull request.
- He'll accidentally add auto-generated text files to the pull request because he's not looking at the files he commits.

(These are simplified examples, I know code-reuse is bad and that the gitignore should be configured to exclude certain files. These are the kinds of things that indicate that he's rushing and not checking what he's doing.)

I'm not even that worried about technique as such, because I know that he'll learn that as he goes along. I just want him to slow down and double-check his work before he decides he's 'done' with a task. It would be nice to work with him on technique, but his pull requests are so full of other disasters that I haven't even been able to get there yet.

Answer 1

He'll have syntax errors in his pull request.

This is bad.

You need to set the clear expectation with him that he will test code before raising a pull request.

When you see such an error, I would ask him how he has tested this. Not if, as that would suggest it might be optional.

When he says, "I did X, Y and Z", then point out the syntax error.

Hopefully, the resultant embarrassment will encourage him to be more thorough in future...

Answer 2

I be may mistaken, but it sounds like you are spoon-feeding him a little too much. He knows you´ll check it anyways, so why go to the effort?

1. Lead by example. For example if you do some Peer-programming, also do peer-testing together as a part of the process.

2. Gradually stop pointing out his errors. Just reject his work and let him figure it out himself. It should cause him more effort to work sloppy than to get it right the first time.

3. Hold him accountable. Try to find tasks for him where he can make errors without seriously hurting the company. Then let him know he is accountable for this and that and you won´t check his work. (this is about responsibility, of course you can check it anyway)

4. Give him access to a Copy of "The Clean Coder" by Robert C Martin

If he does not pick up on this, have a one-on-one meeting, where you clearly define your expectations to him. The general rule is: Quality control should find nothing! make this his only goal for the month - not matter how slow he gets, no matter how often he asks for help, but once he submits his work he should be absolutely certain there are no errors in it.

Answer 3

I think the real problem is that your expectations for an inexperienced developer are unrealistic, and your organization has an ad-hoc development process that relies on the good intentions of a handful of experienced developers.

The new developer is trying to do a good job but they don't have enough professional experience to know what is expected. Nor have you trained them.

he's really rushing the work and missing big, obvious mistakes.

Perhaps obvious to you with years of professional experience. Not obvious to your new developer.

I was hoping that by me bringing them up he would realise that taking a bit longer to do things thoroughly pays off in the long run time-wise. It's really not a race and he's not going to get fired for taking an extra couple of days to double-check himself.

Have you told him directly to relax and slow down? Have you given him a written checklist to be accomplished before he submits a pull request? Have you considered having your developers double-check each other?

... I'll ask him to go through the code and convert the 5 instances of A to B, and he'll miss 1 of them. So it's not that he's incapable, he's just rushing and missing obvious things,

That's not an "obvious" thing, that's tedium that should be automated by a refactoring tool. It also smells like unnecessary duplication that should be factored out so there's only one instance to change, not 5.

How did the unit tests pass with the code in that state?

I've been pretty hands-off in this approach. I'm not checking all of his work thoroughly (I don't have time for that!) ...

Who is? Is there no automatic verification of pull requests for correctness and test coverage? If you don't have time to check his work thoroughly, do you have time to handle the bugs that will not be detected until code is in production?

Specific Suggestions:

1. Write a training plan for the new developer. This will take time from one of your experienced developers, maybe you, but that's part of the cost of adding staff. If you don't have time for this, then you should have hired someone with some years of professional experience on your stack.

2. Start doing detailed reviews of all code changes. Even experienced developers will make mistakes. Reviews take less time than resolving production bugs.

3. Create automated gates for pull requests -- the code should build and new code should be covered by unit tests. If unit testing is impossible due to highly coupled code, make plans to improve that.

Answer 4

There's a couple things that may change the way he approaches his work. First off, just let him know that he clearly has the skills. But just be like

Hey I've noticed that you're more than capable of writing really good code, however there's been a few things that you've missed. With your skills there's no need for the few mistakes, just take your time it's okay if you take a day or two extra

This will allow him to believe he's "proved" himself as you know of his programming skill however he will also take more time to avoid this.

If this continues you'll have to just be more stern and mention that these mistakes keep occurring and you've been here long enough to know x and y etc...

However just mentioning it to him, making him feel like he has responsibility and you trust him but you have some concern should make him think that some errors should be avoided without making him scared to make mistakes. This will allow him to make mistakes as you mentioned and learn from there but at the same time make improvement and avoid rushing.

Answer 5

There's a few things you can do. First, take the time to set up a build server. Have it alert everyone when a build fails - make sure to identify the offender.

Next, conduct code reviews with the group. Have him explain his changes. If there were 5 things to change and he did 4 then call him out on it, again, in front of the group.

A little shame can be a good thing. Either he'll start stepping up or you need to talk to the manager about finding a replacement.