> That's a failure at the management level, not the developer's level
Management don't necessarily accurately know how much effort the work will take. They can ask developers to estimate this, but even then it will not always be accurate.
The crux of movements like the agile movement (and management processes like scrum within it) are to make things more process orientated - management ensures employees work for x hours a week following a process, and adapts based on what output they produce (increasing resources if they want more output).
Product orientated processes (where managers tell employees they have to produce y output, and after that they can slack off or go home if they want to) might work if someone's job is to sit on a production line doing a well understood process, but it does not work well for software. I think both businesses and developers are better off for the trend to abandon such processes when it comes to software.
Given a process orientated environment, it is the prerogative of management to make sure everyone works as close as possible to their contracted number of hours - someone who is working less should rightly get called out on it. They may have finished their current task, but they should help someone with their task, or work on improving processes / infrastructure / addressing tech debt to make likely future work easier.
Not everyone needs to work the same number of hours in a process-orientated environment, but if they work less, that should be in their contract (and most likely they will get paid less than they would have if they worked longer) and not just the employee unilaterally deciding that.
Management don't necessarily accurately know how much effort the work will take. They can ask developers to estimate this, but even then it will not always be accurate.
The crux of movements like the agile movement (and management processes like scrum within it) are to make things more process orientated - management ensures employees work for x hours a week following a process, and adapts based on what output they produce (increasing resources if they want more output).
Product orientated processes (where managers tell employees they have to produce y output, and after that they can slack off or go home if they want to) might work if someone's job is to sit on a production line doing a well understood process, but it does not work well for software. I think both businesses and developers are better off for the trend to abandon such processes when it comes to software.
Given a process orientated environment, it is the prerogative of management to make sure everyone works as close as possible to their contracted number of hours - someone who is working less should rightly get called out on it. They may have finished their current task, but they should help someone with their task, or work on improving processes / infrastructure / addressing tech debt to make likely future work easier.
Not everyone needs to work the same number of hours in a process-orientated environment, but if they work less, that should be in their contract (and most likely they will get paid less than they would have if they worked longer) and not just the employee unilaterally deciding that.