You might worked with a very productive co-worker at a company. He could produce a thousand lines a day in a place where 50 lines per day were considered to be a respectable output.
He would complete his tasks more rapidly. But maintaining and debugging the code proved to be a headache for him.
He copied and pasted a lot but didn’t always fix things like comments, misspelt variable names (like “lenth”), structure, and so on. He also used algorithmic quick cuts that left the code vulnerable.
So, rushing into production isn’t always a good idea.
Procedure needs to be reviewed (and possibly modified)
Before we completely understand why team members are operating at different rates, we cannot build a new plan. We must quickly find a solution to our communication problem with the team so that we are aware of all the factors that have contributed to this gap among our team members.
The problem can be recognized, and we can account for it in our schedule. When updating our project plan, we can either set more realistic goals based on the team’s or its members’ actual previous performance, or we can create team-wide estimates that account for speed disparities.
It is evident that our desired targets aren’t predicated on the current total productivity of our team, thus we need to cease thinking of them as delivery assurances in any case (Chatley & Allerton, 2020).
Your other co-worker might be a keen thinker. He would start by attempting a problem and develop a solution more slowly than normal. The code would be well-written and straightforward, yet it wouldn’t be perfect.
He contributes to the work done by your team on the sensor interpretation component, which was valuable because it used accurate heuristics. He was able to continually improve it due to his temperament and thorough approach to design and development.
By the time the project was completed, you had faster code and noticeably better recognition quality than what was anticipated to be produced by another strategy. In other words, his deliberate slowness really benefited the finished result.
I used to believe that we should treat everyone equally. I now understand that we treat them based on their abilities and needs.
Give work that is not urgent to a slow, undertalented developer
Ensure that they are aware of the need to become more efficient at work and collaborate with them to come up with practical solutions.
It may be worthwhile to invest a lot of time—months or years—into this if they are exceeding expectations in all other areas but speed. On the other hand, we should initiate the performance improvement plan (PIP) if they are consistently performing below expectations and are not improving. The plan may end with we urging them to change jobs.
Overall, being slow isn’t inherently a bad thing, but we must choose assignments that allow for it. Verify to see if they aren’t impeding a vital development path. Assist them in getting better by frequently providing them with constructive criticism over their slow speed.
If we have a developer who is particularly slow, look into WHY they are slow and see if we can suggest any simple changes. It is a problem that we must attempt to resolve if we are not benefiting from their additional time spent. However, we should use it to improve product if they do deliver something additional (Zhou & Mockus, 2010).
Only when software developer is unsure on how to approach a problem, they tend to be slow. They will consequently devote a lot of time to research and trial-and-error in order to find a solution.
It’s crucial to break the total project down into manageable components before hiring a software developer to work on it. Let him calculate the time needed to complete each module.
For example, Sections on a typical website can include registration, My Account, Profile, etc. So let him estimate how much he will need in order to log in. Here, we may be really particular. (For example, how long would it take to add Facebook and Twitter logins?)
As soon as he starts to grow, keep an eye on him to make sure the timeline is being followed
Talk to him about it if he takes longer than anticipated to finish a module so we can figure out what went wrong. Sometimes it appears that they are wasting their time on something that we may have asked them to perform but that we could entirely do without. If we are aware of what takes up more time, we can set priorities more effectively (Claytor, 2018).
The development cycle is probably too long if progress seems to be taking too long. To control how much work is accepted and when it will be assessed, think about utilizing an agile framework like Scrum or Kanban (eg. every week or every two weeks).
The work items should be “sized” so that they can be finished (i.e., coded, tested, and delivered into production) every 1-2 days. By doing this, we can lessen workload, advance through a backlog more quickly, and get much faster feedback on whether we’re creating the correct items
Finally, keep expectations in check
Software development is all about finding manageable solutions to challenging problems. Even if it’s likely that we won’t do everything by the deadline, we can decide to focus on finishing the tasks that will save we the most time and money (Linberg, 1999).
Software developers are typically slow when they work on anything for a long period, lose focus, aren’t working on something interesting, or are unclear of how working swiftly might benefit them (if they are in this situation).
You might find to be effective is to sit down with them, comprehend their issues (whether they are technical or not), document the work in forms that can be used, set smaller targets (deadlines), and keep track of my progress (I repeat same thing if required – just make sure that I am still fun).
Software developer could simply be slow for non-technical reasons
On occasion, software developer might not share their enthusiasm for the project they’re working on.
They frequently miss the “bigger picture” because we don’t always give them the full information.
If we can somehow get them excited about what he is a part of, it will serve as a drug. He won’t stop working until we have answered all of his questions.
However, we need to exert exactly as much effort as he does. He will start thinking of himself as the inferior developer the moment he realizes that we are the boss and he is just the man doing job for we.
References
Chatley, R., & Allerton, T. (2020). Nimbus: Improving the developer experience for serverless applications. Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Companion Proceedings, 85–88.
Claytor, F. L. (2018). Modeling Software Developer Expertise and Inexpertise to Handle Diverse Information Needs. Virginia Tech.
Linberg, K. R. (1999). Software developer perceptions about software project failure: a case study. Journal of Systems and Software, 49(2–3), 177–192.
Zhou, M., & Mockus, A. (2010). Developer fluency: Achieving true mastery in software projects. Proceedings of the Eighteenth ACM SIGSOFT International Symposium on Foundations of Software Engineering, 137–146.
