4

Background: I work for a software startup, I am an intermediate developer in a leadership position. I have not been lead for this whole project, and I would say I am much more comfortable with writing projects than leading them. This has been going on for about a year and is one of many things I have been working on improving after the project was handed off to me, and maybe has not had the proper attention it needs.

This employee likes to get involved. He volunteers for tasks, stays on top of new technologies, learns independently, and is always excited when he talks about software.

However, his code does not reflect what I would expect from someone like this. He often copy-pastes code and misappropriates it. When he designs systems, they are messy and not well thought out, always resulting in spaghetti code and confusing interfaces. He has trouble adhering to agreed upon standards and structure where more junior employees have no problem, showing a lack of understanding for why decisions were made even when they are documented. He often defaults to using hacks. All this despite being around this project since the beginnning.

So far, I have tried:

  • Offering him chances to improve upon old code when he has recognized it was not up to par and new tickets for the same features have come up
  • Letting him know that I percieve a lack of structure and attention. After this, I let him know that I find writing second drafts help with this, and that he should try it out as a starting point to find what works for him

I did not see improvement in either of these cases. Currently, I am working on standards documents for the company that I hope will help him and more junior developers with gaps in their knowledge. I don't know if that will work or not.

Could someone with more leadership experience give me advice on how to help this employee grow?

| improve this question | |
  • 2
    Do you peer review each other's code? – DarkCygnus♦ Nov 30 '17 at 17:02
  • Have you tried having a frank conversation with him about it? Explain to him where you are consistently seeing problems and ask him what he thinks would help him fix them? – David K Nov 30 '17 at 17:13
  • @DarkCygnus We do code reviews. If some of what I said seems like we don't, that's because we didn't when the project was handed to me and I introduced them. – user80306 Nov 30 '17 at 17:24
  • @DavidK The frankest coversation I had with him was when I told him about the perceived lack of structure and attention in his code, detailed above. I have not asked him what he thinks would help. – user80306 Nov 30 '17 at 17:27
  • 1
    Quick update on this. My coworker decided to leave company very shortly after I made this post. I will be sad to see him go. I'm sure with a better onboarding process and the right leadership, he could have grown into a much stronger employee given his desire to improve. – user80306 Dec 15 '17 at 18:24
10

Could someone with more leadership experience give me advice on how to help this employee grow?

First you need to understand the "why" behind the struggles. If you don't know that, you can't know how to help.

Talk with him. Review code with him. Find out what he understands and what he doesn't. Then you can try some improvement experiments.

For example, if this person is undertrained, you can provide training. If this person needs to focus, you can reduce the number of tasks on his plate. If this person needs to prioritize, you can help work on a sequential todo list. And so on.

Lastly, if you conclude that person is simply not capable of accomplishing the tasks necessary, you can help this person find a more suitable role. Sometimes that is within your company, sometimes not.

| improve this answer | |
1

Code review is the first step. Once you have pointed out the problems, and this is critical, require him to fix them and the code cannot be pushed to production until you accept it as fixed. If he has production rights, remove them immediately (Devs should never have rights to production, but it happens in some places.) Accept that you will miss a few deadlines at first (plan the delay quietly into your schedule in fact, so that he thinks he is missing the deadline, and the customer is not aware of it.).

Part of failing code review is when standards are not adhered to and part of it is when the code is not maintainable or difficult to understand or just buggy. Be sure to let the deadline pass even if it is just for standards adherence. You get what you expect and if you don't expect people to adhere to a standard, they will not.

Give him verbal guidance when he is trying to fix, but do not write a single line of code. It has to be painful to do things incorrectly. It is the only way he will learn.

If he doesn't appear to be able to take what he learned in one situation to the next, have him keep a spreadsheet of how he solved various problems and when he asks for help to fix something, have him refer to that spreadsheet as a first step. I did this with one person a couple of years ago and performance improved dramatically once there was a record of how things were solved and she was forced to keep it up and use it.

If this still doesn't help, then you need to take formal steps to l;let him know he has to improve or he is going to be let go. If you get to this point, talk to HR about what the process is in your company for performance improvement plans and/or firing for poor performance.

| improve this answer | |
  • I have given verbal guidance on many code reviews. He doesn't seem to learn, but he also doesn't come to me for help very often. Perhaps the spreadsheet will still help him personally. Thank you. – user80306 Nov 30 '17 at 20:02
  • Remember the critical part is that nothing goes to production until you approve it and he fixes everything directly himself. – HLGEM Nov 30 '17 at 20:13
1

IMO, Looks like this person may have trouble concentrating. Eclectic people have this tendency.
Adding mandatory structure at least will give you what to talk about.

If you have time, you can create a code structure template for him to follow.

TDD can help, add specifically structured block of test methods that need to follow every module he changes.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .