3 ms·

Deadlines are hard to talk about when you have radically differently skilled developers. Sure, it may take some on the team a half hour to do some work, but fo

Deadlines are hard to talk about when you have radically differently skilled developers. Sure, it may take some on the team a half hour to do some work, but for others, it will take two weeks. You hope that over time everyone improves, but that’s just not what happens in reality with bad eggs.

nis0s 2y ago
> Sure, it may take some on the team a half hour to do some work, but for others, it will take two weeks. That seems like an egregious difference, and I don’t think should be mentioned in such an off hand manner. Why doesn’t your team train people? FYI, training doesn’t need to be hands-on, I think it’s often better to give employees education/training budgets. Technical team leads should be able to identify someone’s gaps, and make recommendations. Or maybe it’s better to let someone go instead of wasting their time in a no-growth environment.
- geraldwhen 2y ago
  You can lead a horse to water, but that’s it. And firing is politically impossible where I am. If someone chooses not to improve, or simply does not, there are no repercussions.
- noprocrasted 2y ago
  > Why doesn’t your team train people? It's not a matter of training, it's a matter of lack of rewards and mismatched incentives. The reward for good work is generally more work and a "token" raise at best that is never proportional with the value you added. The market has converged on a baseline of what is typically expected out of a given role. Now sure, we can argue (and I personally agree) that said baseline has become absolutely terrible, but we shouldn't blame the people for that. If your objective is to be an employee and engineering is purely a means to an end (to earn a salary as said employee), then delivering the baseline and getting the baseline salary is all you need to do. Any effort beyond that is a waste of time that can rather be spent on hobbies/family/etc because it will not be adequately rewarded. It only makes sense to go beyond the baseline if you want to learn and have a plausible way to monetize that extra experience (outside of this current job). If you want to build your own product, do consulting, etc.
Falimonda 2y ago
The solution is to let developers lead the conversation about estimates instead of management pulling deadlines out of thin air. If the developers can't agree on an estimate it typically means that the requirements are unclear or misunderstood, or some of the developers are better equipped for the work.
- geraldwhen 2y ago
  I’m saying among the X developers doing the work, the skill gap is so large that estimate must shift an order of magnitude.
  - gardenhedge 2y ago
    Then you estimate work shadowing/supporting as part of the work

nis0s 2y ago

> Sure, it may take some on the team a half hour to do some work, but for others, it will take two weeks. That seems like an egregious difference, and I don’t think should be mentioned in such an off hand manner. Why doesn’t your team train people? FYI, training doesn’t need to be hands-on, I think it’s often better to give employees education/training budgets. Technical team leads should be able to identify someone’s gaps, and make recommendations. Or maybe it’s better to let someone go instead of wasting their time in a no-growth environment.

geraldwhen 2y ago
You can lead a horse to water, but that’s it. And firing is politically impossible where I am. If someone chooses not to improve, or simply does not, there are no repercussions.
noprocrasted 2y ago
> Why doesn’t your team train people? It's not a matter of training, it's a matter of lack of rewards and mismatched incentives. The reward for good work is generally more work and a "token" raise at best that is never proportional with the value you added. The market has converged on a baseline of what is typically expected out of a given role. Now sure, we can argue (and I personally agree) that said baseline has become absolutely terrible, but we shouldn't blame the people for that. If your objective is to be an employee and engineering is purely a means to an end (to earn a salary as said employee), then delivering the baseline and getting the baseline salary is all you need to do. Any effort beyond that is a waste of time that can rather be spent on hobbies/family/etc because it will not be adequately rewarded. It only makes sense to go beyond the baseline if you want to learn and have a plausible way to monetize that extra experience (outside of this current job). If you want to build your own product, do consulting, etc.

Falimonda 2y ago

The solution is to let developers lead the conversation about estimates instead of management pulling deadlines out of thin air. If the developers can't agree on an estimate it typically means that the requirements are unclear or misunderstood, or some of the developers are better equipped for the work.

geraldwhen 2y ago
I’m saying among the X developers doing the work, the skill gap is so large that estimate must shift an order of magnitude.
- gardenhedge 2y ago
  Then you estimate work shadowing/supporting as part of the work