How to help a dev, who is otherwise good, improve the speed at which they work?

Question

I work as the lead dev on a small team. I manage 3-4 devs.

I don't have any issues with this particular dev apart from that given their level they should be completing tasks faster. This isn't just my interpretation; another senior member of the team feels the same way.

This dev is normally dilligent and commited to what we do. They are a good employee but if I am being honest I don't think they're a natural developer. That doesn't mean they're terrible at what they do.

There's a number of things that can slow down a dev:

• the task is naturally complex
• distracted by other tasks
• getting stuck and not knowing how to proceed
  • ...and not looking in the right places for answers
• life gets in the way; personal issues, feeling demotivated, etc
• slacking

I know that the last option doesn't apply here. Like I said, they are commited.

For context, this issue is most obvious when they're having to do a task they've done many times before (i.e. tackling a similar bug/feature). It looks like they just aren't learning from these experiences? They seem to get stuck and not be able to take a step back and view the problem from another angle. They do ask for help eventually.

My intention is to speak to them but I wanted to make sure I have constructive feedback, not just "work faster please". I also don't want to instill in them anxiety or pressure about how long they take as that might make things worse.

Answer 1

I think you hit the nail on the head with this part of your post:

It looks like they just aren't learning from these experiences?

See if you can determine why. While everyone is different, I have found that WRITING DOWN (yes, I know that's old-fashioned but it's worked for 1000s of years) things really helps with recalling and even if it doesn't, the notebook serves are a reference for issues when they come up again.

The key, in my mind, is to enhance their learning so that they are able to work more efficiently in the future.

Another technique that I've found helpful when working with junior developers is to help lead them through problem solving. They do the work and you resist the urge to jump in and do it for them. You're just there to facilitate and advise.

Answer 2

If you've established that they're objectively slow, the next step is to work out what it is that they're slow at.

Reading and understanding tickets? Finding the relevant bits of code that need changing? Understanding the current code? Working out how to solve the problem? Actually writing code? Writing unit tests? Testing that their fix works properly? Documenting their changes? Sending their code for review? Something else?

This means sitting down and talking with them, and seeing how they approach and an task and where they're struggling. Once you've found out which area(s) they're slow in, you can then look at how to address that. But until you understand that, you're just guessing.

If an application is "slow" then the first thing that you need to do is some proper troubleshooting and profiling to determine where the problem actually is - and this is no different.

Answer 3

I don't have much to add to the other answers regarding what kinds of intervention might be helpful, but I want to address this part of your question:

My intention is to speak to them but I wanted to make sure I have constructive feedback, not just "work faster please". I also don't want to instill in them anxiety or pressure about how long they take as that might make things worse.

My advice would be to frame this as a matter of professional development (that is, "development" in the sense of improving one's skills, not software development). If the speed at which they're working is not actually causing problems for the company then there is no need to think of this as an intervention to fix a problem; rather, it's about recognising potential and trying to find opportunities to achieve it. And improving this employee's skills will be beneficial for their career, not only the company.

So this can be good for them, too, and if they can see that then this will be a cooperative endeavour, rather than an intervention imposed on them from above. Meanwhile, there might also be worthwhile professional development opportunities for your other devs, in which case you wouldn't even have to obviously be singling this particular dev out.

Answer 4

I believe the first task before a discussion is to come up with a list of possible impediments that is broader than what you've described. In my experience some (junior) programmers don't realize that they are perceived as slow so the coaching is important.

Here are some causes of "slowness" to complete work I've seen in my coaching:

1. Analysis Paralysis - too many ways to do things, unclear/uncertain about the best (or better) course of action- and unclear direction.
2. Shiny object distraction. In the course of working new concepts, ideas, are encountered and results in too frequent shifting focus, attention or approach.
3. Failure to understand the objective(s) - either because they are vague, or not specified. Implied, unstated objectives are very difficult to meet.
4. Unfamiliarity with tools, approaches, languages or responsibilities in the organization.
5. Failure to avail themselves of the best tools and knowledge (e.g. not able to do a good search for options, or to understand the results they do find).
6. Inability to discern between MUSTs and SHOULDs. That is trying to solve problems that do not require solving. This is really item 3 in a different form.
7. Unusually difficult problem domain. Some problems are Easy only if you've seen or tackled them before.
8. Perception that asking for help, or asking for too much help is a negative. Sometimes teams inadvertently reinforce this belief by their behavior.
9. Inter-personal issues / team dynamics / perceived inavailability of mentors co-workers.
10. Personal distractions.
11. Disinterest. Some problems are just not interesting and cause procrastination unless personal discipline is applied.
12. Intense pressure to complete something "perfectly" sometimes robs people of motivation.
13. No "definition of done" together with unstated expectations that may result in too little (incomplete) or too much work (overkill).
14. Being asked to do maintenance on poorly written code. This can be very daunting. It may be necessary, but often requires a lot of learning, trying.
15. Lackluster approach to debugging and problem solving (and/or a non-existent debugging philosophy and tools)

So given those (and many other possibilities), I would recommend first coming up with observations about the programmer that may apply. Then you can ask questions to illuminate. E.g. "Do you enjoy the work you are doing?", "What do you least enjoy about your work?" Are team members helpful when you ask? How aggressive are the project deadlines? What is the most useful thing you've learned while working here? Are you finding the resources you need to be able to get the work done? Are you clear about what your current project is? How do you known when you are done? What about your last project - how satisfying was that? Is there anything I can do to help you be more effective?

For example in my recent coaching, I realized that one of our programmers lacks fundamental understanding of the language being used and was struggling to understand the error messages being emitted. In another case a programmer was looking up error messages on the internet and "blindly" trying the suggestions without paying attention to the context of the answers.

Answer 5

Rather than attempting to give feedback away from their programming process (such as in a meeting or an e-mail) from what is apparently a position where you don't know the details of the problem, you should sit down and pair program with this developer for a few hours, or have another senior developer do this. The more senior developer should let the junior programmer take the lead and at first simply follow along without commenting too much. Once you start to see where the issues are and what's slowing the developer down you can both offer advice to that developer and consider building processes and tools that will help in areas that slow down not only this developer but perhaps other ones, too.

As a more general thing, having developers pair up on a regular basis will help a lot with getting developers on the same page and spreading good techniques throughout your development team. (If you've not done much pair-programming before, it may be a good idea to try it out first with someone with whom you're more co-equal. But honestly, I can as easily think of ways this could be worse, rather than better.)

One commenter has suggested that it's possible this technique may may lead to the junior developer being disabled by crippling anxiety. I'm going to suggest that this is less likely than with other feedback techniques for several reasons. When you are providing small items of feedback such as "what do you think of doing X instead of Y right here" instead of "everything you do is too slow" you're both pointing out much smaller problems of nowhere near you-could-be-fired size and you're helping the junior developer to reach a solution, rather than just leaving him with the stress of figuring it out himself. You can also provide counter-intuitive advice that he would be unlikely to follow himself without your direction: if he habitually keeps doing something really inefficient in the editor, he may need to slow down in order to break the habit and speed up, which is not something he may come up with himself if he's received only advice that he's "too slow."

Answer 6

I am surprised that no one else has brought this up. My two cents is 'familiarity with the tool set'.

Anyone can fumble with a table knife to tighten or loosen a slotted screw, but a slotted screwdriver is "designed for the task". Maybe your developer has access to the same toolset as everyone else, but is not familiar with ways to use the tools to get through tasks more efficiently. For example:

• Using a SQL Trace tool to examine which query is not producing a correct output, instead of repeatedly stepping through client code
• Using a browser's console log to debug Javascript, again instead of repeatedly stepping through code. Also, the debugger() function to set breakpoints
• Using an IDE instead of a plain-text editor
• Making the best use of debugging, formatting, refactoring features of the IDE instead of doing things the hard way
• DRY (Don't repeat yourself)
• Making good use of object oriented development principles and SOLID. I've found that a surprising number of developers don't put good principles into practice, and it makes writing code and maintaining code much harder.
• Using Entity Relationship Diagrams to understand relationships. In a complex scenario, visual representations are great tools to assist a learning curve.
• Using CSS instead of inline styles

There are many more ways I can think of to optimize the work. Some of you might think these things should be quite obvious, but I really don't think these are concepts that are taught in classroom environments. Some developers are of the mindset that if they aren't taught to use a tool in a certain way, then they just don't.

You might bring up some of these topics in a Lunch-and-Learn session for the team, and avoid singling anyone out individually. Ultimately, sharing these kinds of things is good for the entire team. Come up with topics, and delegate the presentation so everyone gets a chance to learn and share. What do you have to lose, and what do you have to gain?

Best of luck.

Answer 7

Have you considered that they could be slow on tasks they've done before because they think they're going to be easy so they put them off?

If I have a large unique task that I know will take a full week's worth of development, I work hard every day to finish it. If I have a task that I know will take 5 minutes, I put it off over and over because I know I can finish it quickly so I don't need to work on it yet.

Consequently, a 5 minute task and a week long task might get finished at the same time, because I've put off the 5 minute task while working on the week long task.

If this is the case, you could have the first day or two of the sprint be the days that they're expected to work on easy tasks and get them finished. Then, the later parts of the sprint should be dedicated to the harder tasks that will take longer.

If I've misdiagnosed the problem, you can ignore this, but I wanted to throw this perspective out there.

Answer 8

You can establish standard practices from Scrum in your team which would mitigate or prevent issues you've described:

• Use backlog for tasks. Break down complex tasks into smaller pieces
• Limit work in progress to avoid distraction - single piece flow tend to be faster and don't need context switching
• Organize planning before each development iteration to discuss how long would it take or what's the best way to solve existing problems in a backlog
• Short daily meetings to talk about what's done, goals or impediments
• Have recurring retrospective meetings where the team could discuss what went well and what could be improved. In this way, you could step back and propose more conceptual solutions to repeating problems.

Or try pair programming:

the courtesy of rejecting phone calls or other distractions while working together, taking fewer breaks at agreed-upon intervals, or shared breaks to return phone calls (but returning to work quickly since someone is waiting). One member of the team might have more focus and help drive or awaken the other if they lose focus, and that role might periodically change. One member might have knowledge of a topic or technique which the other does not, which might eliminate delays to find or test a solution, or allow for a better solution, thus effectively expanding the skill set, knowledge, and experience of a programmer as compared to working alone. Each of these intangible benefits, and many more, may be challenging to accurately measure, but can contribute to more efficient working hours.

Answer 9

These are my "facts".

A) We all work at our own pace, this isn't inherently or necessarily "improvable".

B) Slow is sometimes synonymous with low quality, ie we can do less in a shorter time frame.

C) There are no accurate benchmarks to measure the correct time to spend on a task.

My suggestion would be,

1. If it's not acute, leave it.
2. If it is acute, switch the talk from time to quality. Ask them to deliver the best thing they can in a set time frame, ie one week.

Give relevant feedback on quality issues, only if you feel that a software engineer with the same experience level would have easily done better. Things like no tests, poor encapsulation, etc. Given the limited time frame, Missing requirements aren't relevant, only grossly incorrect ones.

If there is a comment from you about encapsulation more than exactly twice, it's time for HR to get involved. Say so the second time: "We talked about encapsulation, this is a basic requirement from your code. Please make sure we don't have this discussion again, otherwise we will need to consider if you fit this position. "

Answer 10

It makes sense to do some preparations, so good that you ask around before going to talk to them.

Try to be specific (first to yourself) on WHY the lower speed is a problem. Make it as factual as possible. If you can explain that in nice words, you can ask your dev for a quick chat and explain that you see it as a problem and investigate if the dev acknowledges this. If they don't, all the effort you will put into it will probably be met with resistance in some sort of way.

If they acknowlegde the problem, it is now a shared problem which you can try to figure out together.

Don't immediately come up with solutions of your own, first start exploring if the dev sees areas that might be problematic and can be improved upon. If so, offer help if posssible.

Answer 11

As software developers, we need to know a lot of things. A lot more than most (albeit not all) professions. This knowledge is also spread over a plethora of different areas, infrastructure, algorithms, languages, etc. Which really doesn't make it conducive to storing everything in your brain all at once. Even the best devs find this hard.

I'm a large proponent of developing a "second brain" that stores all of this information in a well-organised way so that we can nip in, find what we need and get back to the task at hand when we encounter something we've seen before.

Personally, I recommend using Obsidian for this. It lets you build a knowledge base for yourself using markdown. One of the best features is that it lets you graph relationships between different motes of knowledge which helps when you're trying to recall how various different things fit together.

In the case of your developer, he could create a new note every time he encountered something he didn't know how to solve, and then update it with the solution after receiving help. This would then be linked with the project, technology, etc. Then, when he encountered the problem again, he could check his Obsidian Vault, search for the things related to x bug and he'll come across this document and know what to do.

The key thing to note though, is that for this to work it requires diligence and the pay-off is in the long-term as the knowledge base grows, it's not a short-term fix.

Answer 12

I'm afraid I lean heavily towards those other answers which question whether there is even a problem here.

If you accept that they are already giving a full effort - which is the real judgment that a manager is expected to make - then what else is there to change or optimise?

There will inevitably be individual variation between developers, so it is silly to assume there must be a problem just because others could work quicker. There will almost always be someone on a team who comparatively performs worst, because those determined to establish a ranking will find increasingly minor or subjective things to distinguish each member.

You also don't quantify the difference between the speed you would expect and the speed achieved. One developer taking twice as long as another, for example, would seem well within the realm of "variations in ability", that cannot necessarily be changed by any advice or alternate methods. Be careful to ensure that you are holding people only to sufficient standards, not trying to hold everyone to the maximum standard that any one individual does achieve.

My recommendation would be to keep an eye on the situation, but do not raise a problem unless you have made a specific diagnosis and have a feasible remedy.

Telling him to ask for help sooner may not be a real remedy, because it may erode the productivity of others called to help more frequently (if he could have got to the end on his own in a reasonable time), and it may erode his own productivity sooner or later if it undermines the time he has to spend on properly getting to grips in his own mind with certain difficulties.

Answer 13

I think the best thing you can do is to model the correct behaviors yourself and give the team opportunities to share knowledge without the constant pressure of "getting-it-done" asap.

Many folks do better when they can see how others approach problems. By "approach", I mean in a general sense. What's the workflow? Where are the information sources? What are the relationships across the org that help others? If the team is working as isolated individuals, each person has to discover on their own what they need to proceed. That can take A LOT of time.

This can be compounded when you're dealing with senior level people, who as you mention yourself, are held to higher expectations. These folks will feel shame in asking for help. They're battling internally with pressing on with digging a trench with a teaspoon or bothering someone else and risking being judged as a "help vampire". Sometimes it's better to reach out proactively or at least foster an environment where people feel safe to get help and ask questions-- is your environment like that?

Answer 14

One important piece of information missing in your question is: Is it same software in which they solved similar bug / added similar feature earlier?

You know softwares grow in complexity over time. More and more features added and there comes a time when it becomes immensely difficult to add another feature. There are just too many ropes to look at to stop oneself from getting tangled and the application to go haywire.

Another thing is, why would you think it would take significantly smaller time to do same software change?

Yes, some time would be saved because the research/learning is already done but depending on complexity of algorithm and one's luck in quickly finding a solution it can be a small amount of time. The algorithm still has to be implemented and its may be this part thats taking the bulk of time. There is no way to reduce this. You see while the solution is now well known and learned there are other things unique to this software that must be look out for that were not present in the other software the solution was originally found for. Each software has its own quirks and limitations.

You are using your home-made personal metric which very probably nobody else is using. Its very likely to be wrong. Similar in software development dont mean what you think (hope) it means.

Frankly you dont sound like one who has done hands on programming for a while (months, years). May be you have moved up the managerial ladder sometime ago. You sound like a customer who thinks since he has explained what he wants the work will be done by evening.