4 ms·

I agree a lot with your comment. No amount of planning or estimates will ever change that a feature will be done when it's done. My previous job had about a 4t

I agree a lot with your comment. No amount of planning or estimates will ever change that a feature will be done when it's done. My previous job had about a 4th of the total work week dedicated to meetings. As someone with ADHD, this was very difficult for me. What made matters worse is that they were sometimes spread out and I could lose an entire day of productivity and I was just unable to work when my meds ran out and there was a shortage in the entire country (Mexico). I am now back to contracting and my client just lists out the requirements in a document and I code away and have been VERY productive. No meetings or calls since I have started working with them 3 weeks ago.

MattGaiser 5y ago
Especially when I am just seeing the feature request for the first time and it is an adjustment to some existing thing I did not code. We had a project a few months back where we used tech nobody on the team had used before. Had a fancy Gantt chart of where the schedule would be. It was shot to hell by day 3 and we spent hours trying to figure it out and gave up as it was never accurate.
commandlinefan 5y ago
> a feature will be done when it's done. PHB: "You're thinking like an engineer, not a manager." Dilbert: "In that case, we'll fix the bugs before we find them."
com2kid 5y ago
> No amount of planning or estimates will ever change that a feature will be done when it's done. I've been on teams where we got good enough at estimating that we were +/- a couple of hours each sprint on our burn down charts. Long tenure, good knowledge of the code, and a healthy amount of time spent on reducing technical debt all combine to make accurate estimations possible. Of course things can go awry in regards to partner team or 3rd party API integrations, those are always wild cards, but that is why you first do an exploratory task to figure out how hard integration will be (my current team calls these stories "spikes" in our workflow), which de-risks future estimates around the work. And it also makes more sense. "Spend this week learning how to use this API and figuring out its warts, then come back and give an estimate next week on how much work it'll be to get it up and running for real." A rather reasonable way to do things.

MattGaiser 5y ago

Especially when I am just seeing the feature request for the first time and it is an adjustment to some existing thing I did not code. We had a project a few months back where we used tech nobody on the team had used before. Had a fancy Gantt chart of where the schedule would be. It was shot to hell by day 3 and we spent hours trying to figure it out and gave up as it was never accurate.

commandlinefan 5y ago

> a feature will be done when it's done. PHB: "You're thinking like an engineer, not a manager." Dilbert: "In that case, we'll fix the bugs before we find them."

com2kid 5y ago

> No amount of planning or estimates will ever change that a feature will be done when it's done. I've been on teams where we got good enough at estimating that we were +/- a couple of hours each sprint on our burn down charts. Long tenure, good knowledge of the code, and a healthy amount of time spent on reducing technical debt all combine to make accurate estimations possible. Of course things can go awry in regards to partner team or 3rd party API integrations, those are always wild cards, but that is why you first do an exploratory task to figure out how hard integration will be (my current team calls these stories "spikes" in our workflow), which de-risks future estimates around the work. And it also makes more sense. "Spend this week learning how to use this API and figuring out its warts, then come back and give an estimate next week on how much work it'll be to get it up and running for real." A rather reasonable way to do things.