News for hackers. Stuff that matters.
Re:I suspect many task deadlines are designed to force engin... by klmadfejno on Wednesday September 16, 2020 @04:28PM (#24497396)
Number 2 is very important and not obvious. Give your manager options to choose from. It makes you a cooperative problem solver rather than someone who is pessimistic and can't manage deadlines. Shrugging and saying that scope management is the manager's job is equally as bad as the manager shrugging and saying implementation is the dev's job.

Applies to non-dev work as well.

Re:I suspect many task deadlines are designed to force engin... by sidlls on Wednesday September 16, 2020 @04:54PM (#24497774)
And what happens when your manager’s response is “you’re the expert, I expect you to decide these things?”

This industry is like any (every?) other: a minefield of incompetence and laziness interwoven with an unhealthy dose of unjustifiable arrogance.

Re:I suspect many task deadlines are designed to force engin... by TuringNYC on Wednesday September 16, 2020 @04:58PM (#24497821)
In some ways, that might be a good situation -- it means they are leaving all the trade-off decisions to you. If they are only specifying time and resources, you can trade scope, quality, debt.

If they are freezing time and resources and scope, and you dont have much room to move except with quality and debt. But those catch up. If that is the consistent trade-off, i'd go with my original recommendations: trade this stupidity for more salary or find a new employer with better management. Or seek the managerial position yourself and do a better job at it.

Re:I suspect many task deadlines are designed to force engin... by nthj on Wednesday September 16, 2020 @05:22PM (#24498098)
Always provide options and a recommendation.
Re:I suspect many task deadlines are designed to force engin... by CogitoCogito on Thursday September 17, 2020 @09:18AM (#24504237)
If this doesn't work, then I think the most important thing is to implement the most simplistic basic solution as fast as possible and then explicitly ask for feedback. Hard-code whatever portions that take time, but you're not worried about (e.g. database portions). Focus on the parts that are vague that you don't understand and provide a _concrete_ realization of the those vague ideas. This shifts decision-making responsibility away from you.

As a plus this also gives you the ability to more effectively gauge the difficulty of the rest of the project. The things you thought were simple might be much worse. And then as long as you get concrete feedback, you'll be able to much better predict the amount of time and effort required going forward.