I've given a very simple coding task but I'm not quite getting what asked, how to be more effective/efficient?

Question

I'm leading a small subproject in my company, and I've never lead any project before in my career and this miniproject according to my manager is supposed to be an exercise on leadership.

I did a task breakdown and assigned them. One of these tasks was of the form

Develop a function/API with signature Output functionName(Input1,Input2), the function should perform TaskX

Where TaskX was described pretty much in detail. It was pretty clear and direct and also quite self contained.

I got delivered however quite a big class where the requested API was essentially a member function of a class, the class had also data members that are not really useful for sake of the function itself (for example it has a completely useless viewer for sake of the function). I did the code review and I was trying to explain how I would've done it, including code snippets (which were like 20/30 lines of code) this also included the body of the function.

For some reason, not quite clear to me, I keep getting delivered a big class whose feature and implementation I don't think are entirely correct, but that's not the point. The point is that if I wanted to use that member function I had to instantiate quite a big object which doesn't make much sense.

So to me the goal of the task hasn't be achieved, and I've tried to talk through exactly what I want and why but somehow I still keep getting resistance. Also bear in mind given how short the function was I was expecting this to be done in at most three days (and this was an over-estimate since the function at the end was really short in terms of code) but it's been two weeks now. The reason for taking this long it's because together with the actual meat of the task I'm getting a whole class, as described, and a few scripts and a IDE project which I honestly don't need. The only thing I would physically need is one or two source files.

I've already talked about this to my line manager and essentially the only thing I got out of this conversation was that the engineer I'm currently working with has the tendency to overdo things. So my question here is what's the best way to deal with this situation in the future?

The only thing I personally thought was to sit next to him and try to walk him through the tasks I assigned to him, but often these conversations drift off to stuff not strictly related to the task (this is probably because I'm too available in giving explanations and this is doing more harm than good).

Any advice?

(Note: The project is very small it's like three engineers involved, including myself).

Update : So despite my code review I was provided again with bloated code. So the technique I have adopted to sort this out was kind of a mixture of a couple of answers I got from here.

First of all I explicity asked why I was given so much code given the task. I was given reasons (whether or not I agreed or not it doesn't really matter) but at the end we clarified what was necessary for the task, so at the end I got the 20 lines I thought were necessary. So this sorted out the current task.

As an exercise for him however I've assigned to give me some form of design/pseudocode whose implementation would allow to achieve goal the next task. Therefore we had a meeting where we discussed this. The discussion some times tended to drift off to other details (useful to understand but not important from coding point of view), I think this time however I managed to stay on track most of the time. At the end of this meeting I asked the explicit question "how many lines of code do you think you need to implement this?" he explained to me what he had to do in is opinion and this time sounded about right, I've also emphasized many times the minimal code required and I think I was understood this time.

Answer 1

The only thing I personally thought was to sit next to him and try to walk him through the tasks I assigned to him

This seems like a good idea to me. It's basically following the principle "Lead by Example".

Of course, the idea is that your team will eventually be able to do things on their own, without you having to sit next to them, but in this case seems that doing this once with this person could help.

Try getting with them, and try to do one of the tasks you have assigned them. Share with them your though process, ask them what is their thinking and reasoning, give your feedback, suggestions and corrections, but let them do the coding.

After that, let them finish the rest of the tasks on their own, and see how they managed to do so now. Perhaps this person tends to over-complicate things, and what they need is a little bit of guidance to understand and change their ways.

but often these conversations drift off to stuff not strictly related to the task (this is probably because I'm too available in giving explanations and this is doing more harm than good).

I would not frame this as a conversation; perhaps that is your mistake and why this deviates.

This should be more on the lines of Pair Programming (but, again, let them do the coding and refrain from putting code yourself as much as you can).

If you feel this person starts to deviate or to go into details that are not needed, politely put the exercise back on track and refocus on the task at hand.

Answer 2

Set your engineer a challenge: Produce the minimal code to meet the requirements. This version does not have to be ready for release, just a correct implementation of the requirements.

When that is done, discuss with the engineer what else is needed to make it ready for release. What is the benefit and cost of anything that might be added?

Answer 3

This sounds a lot like obfuscation. Obfuscation is a practice, usually employed by developers who are not good at their jobs, whereby they ensure their job security by making their code as hard as possible to understand and work with so that they're the only one who knows how it works. Therefore, if they get fired, the company has to throw out all the work they did and redo it from scratch, because nobody understands what was done. Therefore, they think, they are less likely to get fired, because the overhead cost of replacing them is too high.

Here's what you do: If you think a project can be done in 3 days, then you set a deadline of 3 days. That's a KPI for your developer to meet; if they can't get the assignment done in 3 days, then that's a strike against them that you can use on their next performance review. If they don't believe that 3 days is enough time, they can come to you and negotiate the deadline, and at that time you can clarify the requirements with them and make them understand the assignment they are getting is not as big as they think it is, and then if they still try to deliver something really big, you can express to them that their code does not meet specifications.

The most important thing to do with a developer who is obfuscating is to not merge their code. The obfuscation scheme fails if their code is prevented from going in production. Make sure only clean code goes into production so if this developer leaves the company, you don't get stuck with a ton of tech debt.

As a caveat to all of the above: Many languages have "best practices" that look a lot like code obfuscation, e.g. interfaces definitions, lots of configuration overhead, and so on. Make sure that you understand the constraints the developer is working under; it's possible he is delivering good, clean code up to the standards of the languages/frameworks he's working with, and you're telling him to write bad, hackey code that's hard to maintain, and he's trying to tell you nicely that you're a moron and you're not listening. Keep this in mind with whatever you do.

Answer 4

If you have authority, while dealing with this developer, try to implement narrower deadlines and add specific output requirements.

Up to the point that you send him a dedicated code editor file, depending on a language you utilize (i.e. *.cs) with structure and "Put code here" in the context

This way it would be harder for him to inflate and obfuscate his work.

But, if as a result you would get an unacceptable work, you would have something to go to your higher-up with for advice / confirmation of an action required for this developer

IMHO, dealing with all kinds of subordinates, is also part of growing in to managerial role where your job is not to do the work, but to distribute assignments and integrate received results in to a final product