29

I'm the tech lead for our small and growing tech team. One of the first people we hired was a mid-level engineer and a little new to the full software-engineer setup: best practices, coding standards, automated test writing, etc...

Some of the early things this person worked on were less mission-critical, and so I was not a stickler for best-practices in the beginning, to give them time to catch up. Over the months though I've been slowly encouraging best practices and raising the bar, and have always been very clear about my long-term expectations (full test coverage, strict adherence to coding standards, etc). This person has recently started working on more critical components, and so I'm now doing daily code-reviews with them to make sure that everything is completely up-to-spec before it is "finished".

The result of this is that I have sent their code back for more work a number of times. Some of it has been for outright bugs (and subsequently to write the missing tests that should have caught the bugs), and some of it has been more about future-proofing or changes that will make the code easier for others to work with in the future. Today in particular I sent the same piece of code back 3 or 4 times: initially for some details that were missed, and then more because the changes introduced to address my initial concerns had their own issues.

Probably not surprisingly, this person is clearly starting to feel frustrated with this process. To be clear, my own code reviews aren't simply "this is wrong, fix it" but involve a good amount of detail explaining what the problem is, why it will cause problems in the future, and why it will be better for all of us to get it right the first time around. I'm trying to help the person see the importance of getting this right from the beginning, even if it takes more time as a result. From my perspective (I've worked with a lot of large code bases in the past), these things are simply necessities to manage our systems in the long term. From this person's perspective though, I'm sure I'm seen as being overly picky.

As the tech lead of course, I set the standards, and I don't intend on changing them. However, I would like to help this person get past their frustration and see these things as I see them: if we don't get the obvious stuff right now, it is simply going to be that much harder for everyone a month from now when something needs to change.

It occurs to me that this may be a sign that I'm not providing sufficient (or good enough) training. I also may have transitioned from "Here are things to keep in mind" to "Let's get everything right before we move on" too quickly. With that in mind, here are some specific questions:

  1. How can I help my coder have a more positive perspective about me sending their code back for changes frequently?
  2. Is this a sign that I am doing other things wrong?
  3. Any suggestions on how I might smooth out this transition a little better?
  • After the first iteration of your the review and comes back, is his code actually correct in design and thinking but fails in implementation to the teams standard? Or does he fail in both? – Isaiah3015 Jan 30 '18 at 20:22
  • 2
    Do you have any old really awful code around that you get him to try to maintain? Let him find some bugs in software that was clearly not written to your standards. This should aid motivation. – A. I. Breveleri Jan 30 '18 at 21:11
  • Fails in both. As an example, part of the frustration was that something I had flagged as a bug that needed fixing was an edge case in an internal API call, and won't happen in proper usage. As a result they viewed it as "not actually a problem", while I viewed it as "will cause trouble if the API call is accidentally called wrong". Effectively, the code could result in a crash, but only if the internal API was called incorrectly. For our system a crash doesn't impact any other calls, so this wasn't exactly critical, but I consider any crashes to be unacceptable in production. – Conor Mancone Jan 30 '18 at 21:11
  • 4
    Start by showing him this post... it will do 50% of the job – Neoares Feb 2 '18 at 12:12
  • If he doesn't quit, then that should be a indication that he is okay with how you manage the project. You made it clear that from here on out, he's to do it the way your company does it and he's willing to accept that by staying around. – Dan Feb 2 '18 at 18:29
24

This topic is near and dear to me (so much so in fact I had to check my history to verify that I didn't write it)!

At the end of the day, I disagree with any suggestions that you let your high standards slide. Coding standards add real value and you don't throw them away because they are tough... but as Lead, it is your responsibility to make them ridiculously simple to follow.

Remember, this developer is not you. He could be the most competent developer in the world but his experiences and preferences are going to differ (perhaps widely) from yours. It's going to be much tougher for him to code to your expectations because your standards don't come natural to him.

I doubt your developer is frustrated because he needs to hit specific standards (if he does then you have a bigger problem), more likely his frustration is based on the feeling that he is trying to hit a moving target.

You need to simplify things for him:

  • Are your standards documented? If you don't have these written down somewhere (anywhere), you can't expect anyone to abide by them. Even the most accepted best practices tend to have one or two semi-competent detractors online. Developers don't always agree so make it concrete: write down your expectations.
  • Is that documentation readable? This is a big one... I've seen plenty of standards documents that list great detail but it's 60 pages worth of material! No developer can absorb that in one sitting. Even smaller 3 page documents can contain more bullet points than you are likely to remember when focused on a specific problem. Do your developer a favor and put together a checklist of important "reminder items" that he should review before he performs a commit. Think of it as a code review cheat sheet to help him review his own code before it comes to you.
  • Are you making use of code quality tools? You don't mention what languages you are using but for just about any language there exist static and dynamic code scanning frameworks that can actively critique your code while you type. Research and utilize these if you can! (some quick examples are Checkstyles, SonarQube) There is nothing better than finding out you are doing something wrong in the IDE while you are doing it so you can address the issue in real-time. Even finding issues during compilation is better than having it come back on a review. These tools empower the developer and save a lot of time during the review process. They may take some initial investment to set up properly but I promise you that you will like the long-term results.
  • Do you have a mentorship or shadowing program? Every professional could benefit from looking over the shoulder of a senior teammember. As @Marc Q. mentioned, encourage this developer to sit with other developers, learn the ropes and constantly strive to improve. Proactive personal development is so much better for morale than constantly reacting to negative feedback. Even just letting him in on your secret websites where you go for online help could end up being invaluable information to him.
  • Are you encouraging him? This is by far the most important point! Findings on a review is a blow to even the strongest ego. Sandwich those critiques between praise for doing the right thing. Point out clever solutions to problems he solved. Notice his overall improvement. Programming can be an excruciating endeavor even in the best of conditions but if you feel like you are also unappreciated it can be soul-crushing. Make sure to always give him positive reinforcement along with any correction. It may be what he needs to keep going for the day.
  • 2
    +1 to encouraging your coder: let him know that you are asking for the best because you believe in his abilities. You're impressed with his work so far, now you're excited to get him up to 'lead' level. – LeLetter Feb 2 '18 at 22:57
9

Focus on one thing at a time, wait until that standard is met, then introduce another.

The problem is that he's been allowed to go at a certain pace and now he's being introduced to standards he hasn't had to meet before.

In the interim, you will have to let some things slide. Let him know that you are going to help him get up to shop standards and that you ARE letting things slide for now, but it's only temporary.

Be patient with him because he is in this situation because he is in this mess in part due to you. You can't just flip a switch and expect the person to meet the standards.

So, in summary:

  • Be patient
  • Introduce standards one at a time
  • Make it clear that this is an ongoing project for him
  • 2
    I think this was what he was doing and now it is time to meet all the standards or keep working on the non critical stuff – Bill Leeper Jan 30 '18 at 20:24
  • 1
    @BillLeeper no, it sounds like he's been raising ALL of the standards at the same time, which is why I said ONE at a time. – Retired Codger Jan 30 '18 at 20:40
  • To be fair, it's probably been a little bit of both: the biggest change is having all code fully tested, and that is a change that I started working towards months ago and had clearly stated expectations about when it would go from "let's do our best in this area" to "test coverage must be complete before I give my a-okay". I think it's fair to say though that there are additional standards that are being raised at the same time without me communicating clearly. – Conor Mancone Jan 30 '18 at 21:02
  • As a for instance, the person is working on an API call to be consumed internally. I pointed out some bugs that would cause crashes in edge cases, but which would only happen if the person calling it internally called it wrong. I consider that a bug-to-be-fixed, but they were viewing it from the perspective of "our internal people won't do that so it doesn't matter". As a result, it is a grey area where you could reasonably conclude that I have raised the standards without clearly communicating that fact before hand. – Conor Mancone Jan 30 '18 at 21:04
  • 2
    @ConorMancone yeah, that one needs to be nipped in the bud. I usually do it with humor like "You have to do your best to make it fool proof because fools are so damn ingenious". Internal people are actually MORE likely to screw things up because they have more confidence with the native environment. – Retired Codger Jan 30 '18 at 21:14
4

Pair programming might help. Developers (this particular colleague and others) accept real-time suggestions a lot easier than after-the-fact criticism, in my experience. And it could change the present underling-supervisor relationship (that's how it sounds) into a co-contributor one (albeit some more senior than others). 'Hope this helps!

  • Why was this down-voted? Pair programming is a very valid idea. – DanK Feb 2 '18 at 20:45
  • Indeed, apart from making sure the standards are consistent, this is probably the best idea. Take a real, particularly problematic submission and sit down and discuss and fix it together, always being sure that the reasons for each applied standard are part of the conversation. Explain that the goal is not to be rejecting code 3 or 4 times, but to be doing this cleanup onself before submission, so that the reviews can be reserved for the kinds of oversights and dilemmas that require additional eyeballs. – Chris Stratton Feb 4 '18 at 18:47
  • Pair programming is actually the best idea, but properly implemented it means shuffling pairs so everybody learns and syncs to the same standard. Do not single out this employee - that would end up not being pair programming but mentoring/ letting him look over your shoulder ... – Daniel Feb 6 '18 at 13:25
  • Thanks @Daniel, I have edited my answer to reflect your suggestion of not singling out this particular employee. – Marc Q. Feb 6 '18 at 14:39
2

As someone who is starting his career as part-time coder, I will try to gie you some insight on how I would like someone would approach me about such topics.

How can I help my coder have a more positive perspective about me sending their code back for changes frequently?

As you mentioned in your question you already are providing him with detailed feedback. You describe it as he doesn't understand your feedback. In this case, he is either not able to understand it or he doesn't want to understand it. In the first instant. you need to check his technical skills. What does he know, what does he know in the partition and what doesn't he know. if this is sorted out give him guidance on where to find the needed information, and repeat this process for every item on your list.

In the second case, it will be hard to stop him from being frustrated because there might be other factors which prevent him from following your coding guidelines.

Is this a sign that I am doing other things wrong?

Not necessarily. If he is self-aware of his errors then you need to encourage him. Tell him that besides those things you mentioned in your post, he does a good job and that he can improve on that (of cause only if this is the case). I would second the answer from @The Snark Knight that you should not force everything on him at once but one thing at a time. Be sure, however, that this aspect is understood and well demonstrated.

Any suggestions on how I might smooth out this transition a little better?

What you will need is time and patience with him. Which might ease your and his pain is to create a 4 phases model (i only know the German term and didn't find any English links)

  1. Order: him to do things: here he needs guidance on what and how things should be done.
  2. Explain: why things should be done like this
  3. Participate: Check if your guidelines are met. discuss with him/the team if and how they should improve
  4. Delegate: This phase is IMHO not applicable in this case.

For every task or standard check, in which phase you would but him and act accordingly. Be aware that some people won't necessarily proceed to the next phase.

A general note which is totally opinion based and shouldn't be taken as an offensive. I think you missed a great opportunity with him when you let him slack the noncritical tasks because if you would have thought him back then, you wouldn't need to struggle now. When a new employee joins your team make sure you set the standard from the beginning.

1

Developing a feature to the point where it gets accepted takes time. It takes less time if you have lower standards, it takes more times if you have higher standards (although the extra time is expected to come back through less unforeseen problems later on).

The problem that is frustrating both of you is that currently this employee focuses too much at delivering quickly, and you focus at delivering in high quality, and this clashes (I assume that the time until his code is accepted is not the problem, but the three or four times forth-and-back is). So make it clear that a longer time to delivery is not a problem, but that he tries to deliver when the work is only half done.

I think trying to explain why changes should be done might lead to frustration. He should know this. He might come from a place that suffered from bad quality because of ridiculous deadlines and does what is best in that environment - which is not appropriate in your place.

The problem is just his development process. His development process currently is: 1. Write code that might be working (no obvious bugs). 2. There is no step 2. So just tell him that the process should be: 1. Write code that might be working (no obvious bugs). 2. Write tests that would fail if there are bugs. 3. Fix bugs found through testing and repeat until no bugs are found. 4. Go through all the work and make it maintainable and future proof as far as possible. (People might argue that these four steps are not optimal, but they are better than just one step).

Note that the same developer's next job might confront him with a lead developer who says "why are you wasting all your time writing tests, making your code maintainable and future proof, just ship it as it is and let the customers complain". I hope not :-(

  • The last point there is certainly spot on. That was the environment at my last job, and it drove me crazy. I only have one meaningless disagreement: this process doesn't actually frustrate me. It takes me very little time to look at their last commit and send out feedback, so I could really care less about the back-and-forth. I would just rather them not be frustrated about what I view as an important part of the job. – Conor Mancone Feb 4 '18 at 23:45
  • I think this is a great summary of the underlying issue: we disagree about what the process should be. I've talked about the standards I want for our work, and I've talked about why I think these things are necessities, but I don't think I've ever been clear about how I view this process. I would much rather someone take their time and cover everything. I think this employee, however, is focused on getting code shipped out as quickly as possible. We have deadlines (who doesn't), so that is an understandable desire, but bad code shipped quickly just takes more time later. – Conor Mancone Feb 4 '18 at 23:47
1
+100

"Some of the early things this person worked on were less mission-critical ... This person has recently started working on more critical components ... [I had to send] the same piece of code back 3 or 4 times ..." ... "Let's get everything right before we move on" too quickly. With that in mind, ...

Develop a documented policy that is simple and easy to follow, utilizing recognized standards and procedures that are:

  • Recognized best practices

There's nothing worse than someguy's idea: people will say "Where did you learn that?", and the answer is "Someguy told me to do this." - A non-transferrable skill.

  • Recognized tools

There's nothing worse than someguy's sloppy hack: people will say "Where did you learn that?", and the answer is "Someguy told me to do this." - A non-transferrable skill.

  • Recognized QC

There's nothing worse than someguy's fancy fool form: people will say "Where did you learn that?", and the answer is "Someguy told me to do this." - A non-transferrable skill.

Non-transferable skills are recognized nowhere but the place that developed them. They come into being from people whom never learned the correct way to do things, puzzling their way through life, they Monkey-Typewritter and Engineer's Hammer their way.

I've been many places where people have approached me to say that "they've headed this department several years", or "we've been doing it this way for decades" - that doesn't change the fact that if it is wrong it's a mistake, an error that ought not to be continued.

Part of my hiring conditions are: I do not teach basics, and basics don't teach me (no interruptions from looky Lou's and self-professed experts unless you want to pay 3x; because that's how much it costs). Company owner's understand that after they've heard it from a few dozen people or learned best practices before starting a business.

By doing things correctly your employees know that what they are doing has value (beyond the healthy paycheck). Trying to get people to do things that they know are wrong, for a chiseled down paycheck, is always going to be met with some resistance, sometimes a lot.

  • Ensure that the manager went to a good school and stays current with industry standards.

Some useful reading is:

Holzmann's “The Power of Ten—Rules for Developing Safety Critical Code".

JPL's "JPL Institutional Coding Standard for the C Programming Language" (Version: 1.0).

Find your own best practices and explain why it's important - it's what keeps them employed.

  • Use a series of recognized automated checkers.

It's an easy job to run and justify, plus it gives a specific list of either things to fix or things to explain. This will reduce your workload, conflict, and provide an easy upgrade to better code.

  • Use of QC

There are BS, IEEE, ISO, and MIL, etc. Standards - use what is applicable.

  • If it's important - Don't: accept, clean, pay, or teach bottom barrel.

Here are some specific questions:

How can I help my coder have a more positive perspective about me sending their code back for changes frequently?

Explain the difference between what they were doing before and what they are doing now.

Explain that you don't want to send code back 3 or 4 times as it would be quicker and better to fix it yourself, that defeats the purpose of having them do it, or someone else.

If they want a promotion and increased pay it needs to be earned, neither of you wants 3 or more rewrites of the same code and introducing new problems (including ire) is not something that can continue.

If they can't do the work that needs to be found out and a decision made about how to move forward.

Sometimes mistakes occur, that's understandable; babysitting time is going to have to come to a conclusion in the near future. Mission critical code is like it sounds, neither a game nor a joke.

Is this a sign that I am doing other things wrong?

"To be clear, my own code reviews aren't simply "this is wrong, fix it" but involve a good amount of detail explaining what the problem is, why it will cause problems in the future, and why it will be better for all of us to get it right the first time around. I'm trying to help the person see the importance of getting this right from the beginning, even if it takes more time as a result."

It doesn't seem like it's your fault, except the overexplaining and babysitting part; perhaps you've promoted them too quickly, we could blame you for that. The owner pays enough, don't they?

Any suggestions on how I might smooth out this transition a little better?

I guess you need to pull back a bit on what they are assigned to do and allow more time to do it.

When they hand in a finished job return the whole thing and say you're promoting them to doing their own first code review, and here's an additional X hours to do it.

If that improves things the deadlines were too short, if it's no better explain that an additional X hours were offered but there's still an unacceptable number of problems.

That might reduce your workload of multiple reviews, and leave them less stressed; a win-win.

Some people simply have a level that's 'good enough' they are nearsighted and can't see past that. Any prodding or explaining beyond what they know is going to be good enough is simply rejected, that's not something you want to pay for (up front, or coming back from the customer).

If they're "a mid-level engineer" they should get what you're saying. If they're less than 6 months out of school then possibly they don't. Maybe they just enjoy everything getting easier as time goes on ...

  • These are all good answers, but I'm putting the bounty here simply because it is a very coherent, comprehensive, and thorough answer. – Conor Mancone Feb 8 '18 at 2:42
  • I'm not following what you mean by "Part of my hiring conditions are: I do not teach basics, and basics don't teach me (no interruptions from looky Lou's and self-professed experts unless you want to pay 3x; because that's how much it costs). Company owner's understand that after they've heard it from a few dozen people or learned best practices before starting a business." In many disciplines, "the basics" are as far as it goes, and adhering to foundational principles (aka "the basics") can get you very far. – YetAnotherRandomUser Oct 11 '18 at 1:18
  • Some disciplines insist there is nothing but the basics, and that any advanced technique is really just part of the basics. Different disciplines in this context cross many barriers: sports, craftsmanship, programming, etc. – YetAnotherRandomUser Oct 11 '18 at 1:18

protected by Chris E Feb 2 '18 at 19:57

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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