3 ms·

Hell, I'd bet most developers do something similar. E.g. you're working on a ticket that's estimated for three days and you finish it at lunch time on the third

Hell, I'd bet most developers do something similar. E.g. you're working on a ticket that's estimated for three days and you finish it at lunch time on the third day. Do you immediately ask for more work or do you take it easy for the rest of the day?

geodel 6y ago
You are right. Specially in today's extreme JIRA culture where a day delay in 2 week work cause projects go red and 3 level reporting need hour long meeting on what's being done to remediate the situation urgently.
csharptwdec19 6y ago
If anything I've often seen the same thing happen in development, but from the other side. i.e. You never should have had this much work put in the sprint, but the business decided that Deadline Driven Development was a part of their 'Agile' process. You wind up with 13-21 points when you normally can only do 8. Naturally, corners are cut. Usually around unit tests. (And then everyone wonders why the tests are worthless)
- TeMPOraL 6y ago
  Yup. That's where what GP wrote comes into play, though in the opposite role than they meant. There are at least three reasons you need to pace yourself at work: One, peak capacity work is unsustainable over long term; there's no point in burning yourself out in the span of few months, because then you won't be doing anything at all. Two, if your managers try to set up the workload at the level of your observed performance (or worse, try to squeeze more work by assigning a bit more things to do than were done the last time), then if you start going on afterburners, you'll set up an unrealistic baseline that you'll be later held accountable to. That's where cutting corners will start. Three, systems with no slack are fragile. If everyone is constantly crunching and a genuine emergency pops up, nobody will be able to deal with it. There's probably some general principle in systems science that systems under full load are not optimal once you start doing risk analysis. Good managers understand that, and will actively prevent you from getting yourself overworked - as developers are sometimes prone to do.
  - mathieuh 6y ago
    Your second point conveys what I meant far better. I'm by no means saying one should be a shirker, I mean you should manage your managers by understanding that their role is to get the most work out of you as possible. Leaving yourself a little leeway is just common sense, as you say, if you're working yourself to the bone constantly and giving people the impression that that's just your standard level, eventually something's going to give, likely your mental health.
TeMPOraL 6y ago
Oh, you mean buffer time? But that drags your ratings down, not up. You do not look better by doing work slower. If you had an actual "ticket goal" to hit, then you'd be taking overtime, instead of buffer time.

geodel 6y ago

You are right. Specially in today's extreme JIRA culture where a day delay in 2 week work cause projects go red and 3 level reporting need hour long meeting on what's being done to remediate the situation urgently.

csharptwdec19 6y ago

If anything I've often seen the same thing happen in development, but from the other side. i.e. You never should have had this much work put in the sprint, but the business decided that Deadline Driven Development was a part of their 'Agile' process. You wind up with 13-21 points when you normally can only do 8. Naturally, corners are cut. Usually around unit tests. (And then everyone wonders why the tests are worthless)

TeMPOraL 6y ago
Yup. That's where what GP wrote comes into play, though in the opposite role than they meant. There are at least three reasons you need to pace yourself at work: One, peak capacity work is unsustainable over long term; there's no point in burning yourself out in the span of few months, because then you won't be doing anything at all. Two, if your managers try to set up the workload at the level of your observed performance (or worse, try to squeeze more work by assigning a bit more things to do than were done the last time), then if you start going on afterburners, you'll set up an unrealistic baseline that you'll be later held accountable to. That's where cutting corners will start. Three, systems with no slack are fragile. If everyone is constantly crunching and a genuine emergency pops up, nobody will be able to deal with it. There's probably some general principle in systems science that systems under full load are not optimal once you start doing risk analysis. Good managers understand that, and will actively prevent you from getting yourself overworked - as developers are sometimes prone to do.
- mathieuh 6y ago
  Your second point conveys what I meant far better. I'm by no means saying one should be a shirker, I mean you should manage your managers by understanding that their role is to get the most work out of you as possible. Leaving yourself a little leeway is just common sense, as you say, if you're working yourself to the bone constantly and giving people the impression that that's just your standard level, eventually something's going to give, likely your mental health.

TeMPOraL 6y ago

Oh, you mean buffer time? But that drags your ratings down, not up. You do not look better by doing work slower. If you had an actual "ticket goal" to hit, then you'd be taking overtime, instead of buffer time.