Helping a team member deal with my high standards

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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!

Answer 4

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.

Answer 5

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 :-(

Answer 6

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