RE: estimations as a team leader- I usually "estimate" (and I use the term loosely here) first by using a relative scale i.e. 1-5, 1-10, and then when planning a work period out for someone I'll budget an amount of time depending on the developer. The time budget isn't something that the client should be basing expectations on or even looking at, it's a way to curb developers going off the rails and banging on the same thing for 3-4 days.
The key is once they hit their hourly "budget" they should submit what they've done either because it's done, or because they need more guidance from an alternative mind to get nudged in the right direction or overcome some perceived difficulty. It most importantly forces them to take a break and work on something else- often this will get them "unstuck" by itself.
These things can happen no matter what the team structure, but I find it most common when dealing with contracted developers. Their incentive structure isn't naturally such that it emphasizes things like limiting time spent on a task, unless maybe they happen to be extremely self motivated and overqualified.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
RE: estimations as a team leader- I usually "estimate" (and I use the term loosely here) first by using a relative scale i.e. 1-5, 1-10, and then when planning a work period out for someone I'll budget an amount of time depending on the developer. The time budget isn't something that the client should be basing expectations on or even looking at, it's a way to curb developers going off the rails and banging on the same thing for 3-4 days.
The key is once they hit their hourly "budget" they should submit what they've done either because it's done, or because they need more guidance from an alternative mind to get nudged in the right direction or overcome some perceived difficulty. It most importantly forces them to take a break and work on something else- often this will get them "unstuck" by itself.
These things can happen no matter what the team structure, but I find it most common when dealing with contracted developers. Their incentive structure isn't naturally such that it emphasizes things like limiting time spent on a task, unless maybe they happen to be extremely self motivated and overqualified.