14

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.

  • When you say its become pretty clear, How do you mean? – Twyxz Sep 6 '18 at 9:45
  • @Twyxz 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. – user91714 Sep 6 '18 at 9:46
  • This might not just be a coding thing but more of a "new to work" type situation where they are not used to being in these types of situations where thorough work is important. – Twyxz Sep 6 '18 at 10:18
  • @JoeStrazzere My job title doesn't have manager in it, I'm just in charge of him. I work for a startup, there are like 5 of us in my department, and it's only me and him who specialise in this specific language in the company. Our boss isn't a programmer. – user91714 Sep 6 '18 at 10:30
  • for the last case of auto generated file, it is better to have a proper .gitignore on it. Such mistakes happens to easily, they won't with a proper configuration. For the syntax errors, you can have an continuous integration platform compiling the code each time something is pushed and send an email if compilation failed. – Walfrat Sep 6 '18 at 13:00
17

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...

  • 2
    Yeah, I was shocked when I read that. – Jim Clay Sep 6 '18 at 13:40
  • 1
    Yes make sure he is testing his own code; that he is satisfied that his work is resulting in the desired outcome before making the pull request. It might be that he's simply writing code and submitting it without giving it a second thought. – Matthew E Cornish Sep 6 '18 at 15:38
  • 1
    I had a manager who would rollback and delete a devs commits entirely if they failed to compile. At first I thought that was a bit too harsh. About 2 weeks in I realized it was the perfect solution to making sure someone didn't hose us all. This was quite a few years before we had dedicated build servers that would run CI tests on every commit. – NotMe Sep 8 '18 at 8:44
  • Actually it is so bad the manager should be fored. Pretty much any platform in wider use allows gated pull requests. Gate on Compile. COmpile error? Pull Request automatically rejected. Done. – TomTom Sep 9 '18 at 11:34
5

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.

  • Every line of code should receive some level of peer review. To me, it sounds like they need more process, not less. – Eric Sep 9 '18 at 22:55
  • @Eric: Letting sombody know he is accountable and his code won´t be checked for him does not mean you don´t have to check it! – Daniel Sep 10 '18 at 16:15
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.

  • Would you give the same answer if the field wasn't software programming? What if it was (for example) an engineering company that built bridges? Or a geomatics company that created maps? Or an electrical engineering company that designed circuit boards? The point is that thoroughness is a good quality that makes a good employee, and I want to address that. Our department actually is an electrical engineering department, and we are programming in an HDL which has no CI available and our automation options are limited. – user91714 Sep 8 '18 at 11:16
  • 2
    There are some tasks that require performing duplicated work, legitimately. I did not ask this question to receive an analysis of the department's apparently inadequate workflow. – user91714 Sep 8 '18 at 11:16
  • @Stacey: "I'm a senior software developer...code...syntax errors...pull request..." That's why I thought it was about programming. – kevin cline Sep 8 '18 at 22:19
1

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.

-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.

  • 1
    Shaming can work well in the short run, but tends to foster an environment of fear resulting in people trying to hide/downplay their mistakes. Doing group code reviews can be useful, so everyone can learn from anybody else's mistakes, but those sessions should focus on the troublesome code, not the "offender". – Llewellyn Sep 8 '18 at 20:24

Your Answer

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