5 ms·

One thing this essay doesn't weave together, despite bringing up a lot of the threads, is that timelines for upcoming work are often estimated based on the (unr

One thing this essay doesn't weave together, despite bringing up a lot of the threads, is that timelines for upcoming work are often estimated based on the (unrealistic) assumption that "you're going to leave me alone for long enough to get it done", which never happens. Instead, days get filled with discussions about future work, rehashes of previous discussions, identifying the bugs that junior developers have written, trying to convince management that the latest customer complaint has more to do with the fundamental laws of physics (e.g., network bandwidth limitations) rather than any actual issues with the software, etc... All of these are part of the job, but the conception of developers as "builders" worsens the issue because management does fundamentally believe that we spend most of our time "coding" when that couldn't be farther from the truth. And since we also want to imagine our days as filled with productive programming, we feed right back into the lie.

PretzelFisch 7y ago
I tell people now the estimate is for a week of work but I am coding 20% of the day...
- Buttons840 7y ago
  ... and what they hear is "I promise it will be done by next week".
  - pfranz 7y ago
    It just depends on where and how you want to spend your time. I've "micro-managed" myself to prove the point. I gave them that estimate up front--told them this was assuming I had dedicated time to work. After a week or two I went back at them with how much time I had spent, how far along, and if I was above/below my estimate. Only then did they push to clear my schedule so I could get the hours in. The problem is that is a huge time-suck and they don't really care about the minutiae either. For me the whole goal is to keep the responsibilities clear and unnecessary communication to a minimum and I feel like that's done by building trust and being clear.
amelius 7y ago
Yes. And the problem of giving more realistic planning is that management will say: "but [insert name of random coworker] can do it in half of that time!" Of course that coworker is dealing with the same problems as you do.
drewbug01 7y ago
> identifying the bugs that junior developers have written Bugs are written by all seniority levels of engineers. “To err is human,” after all. Junior developers hold no monopoly on mistakes.
- dmm 7y ago
  >> identifying the bugs that junior developers have written > Bugs are written by all seniority levels of engineers. Sure but the Senior devs are too arrogant to ask for help ;)
  - to11mtm 7y ago
    Sounds more like a mid level dev. IME Seniors aren't afraid to ask for help when it makes sense to.
- Kalium 7y ago
  If anything, it's been my experience that the bugs from the junior devs are often more obvious and easier to fix. Any junior dev can make a minor logic error. It takes a senior dev to mis-architect a whole system.
  - Aeolun 7y ago
    Junior devs can absolutely mis-architect a system if you give them enough leeway because they’re described to you as senior developers.
  - rurban 7y ago
    Normally it's the mid-level dev who mis-architects a system. It's called overarchitecturing. Seniors rarely overarchitecture.
    - watwut 7y ago
      Seniors both over architecture and underarchitecture.
pfranz 7y ago
I thought the article broke down those things rather well. It talks about how detrimental context shifting is, shifting priorities. In the part about how poor time estimates are, "No time is put in for meetings to go over requirements and make changes," not time is accounted for bugs, or the learning part about solving a problem.
drewcoo 7y ago
You can solve that problem honestly or not so honestly. I've worked in places where everyone knew to pad their time without telling the non-dev in the room. I've been happier with also estimating the ratio of time you spend doing tasks. Someone more senior should intend to spend less than 100% of their time on those tasks. Both of those work better than ignoring overhead or refusal to estimate, imho.
- JimboOmega 7y ago
  I don't think there's anything dishonest about estimating a task discounted for all the random org noise. It is annoying when your boss balks at your estimates using productivity when everything goes smoothly and there are no interruptions as the benchmark, though.
losteric 7y ago
Measuring and optimizing bottlenecks is a core agile idea. My team's process is to estimate and track dev non-dev time with our other sprint metrics at dev-day granularity. ie last sprint I estimated 2 non-dev days for product / design discussions, factoring in the meetings/doc writing/cost of mental randomization/etc. Planning and retrospective provide opportunities to reflect on reducing communication overhead within the team, and the metric is valuable for pushing back on top-down management-mandated overhead.
dmz73 7y ago
It may not be so much assumption that about being left alone but instead requirement to quote the time that will be used for billing. You can't pad that, it will be 20 days of work that client should pay for but that 20 days may be spread over next 3 months. Problem is that neither management or client hears that part even when they are repeatedly told multiple times.
_raoulcousins 7y ago
I'm always explicit when asked for an estimate. It's not the most political or business savvy answer, but I say things like "this will take 2 hours. On average I'll have two hours of focused time per day, so 10 days."
- overdrivetg 7y ago
  sorry for pedantry but you do mean "this will take 20 hours", yes?

PretzelFisch 7y ago

I tell people now the estimate is for a week of work but I am coding 20% of the day...

Buttons840 7y ago
... and what they hear is "I promise it will be done by next week".
- pfranz 7y ago
  It just depends on where and how you want to spend your time. I've "micro-managed" myself to prove the point. I gave them that estimate up front--told them this was assuming I had dedicated time to work. After a week or two I went back at them with how much time I had spent, how far along, and if I was above/below my estimate. Only then did they push to clear my schedule so I could get the hours in. The problem is that is a huge time-suck and they don't really care about the minutiae either. For me the whole goal is to keep the responsibilities clear and unnecessary communication to a minimum and I feel like that's done by building trust and being clear.

amelius 7y ago

Yes. And the problem of giving more realistic planning is that management will say: "but [insert name of random coworker] can do it in half of that time!" Of course that coworker is dealing with the same problems as you do.

drewbug01 7y ago

> identifying the bugs that junior developers have written Bugs are written by all seniority levels of engineers. “To err is human,” after all. Junior developers hold no monopoly on mistakes.

dmm 7y ago
>> identifying the bugs that junior developers have written > Bugs are written by all seniority levels of engineers. Sure but the Senior devs are too arrogant to ask for help ;)
- to11mtm 7y ago
  Sounds more like a mid level dev. IME Seniors aren't afraid to ask for help when it makes sense to.
Kalium 7y ago
If anything, it's been my experience that the bugs from the junior devs are often more obvious and easier to fix. Any junior dev can make a minor logic error. It takes a senior dev to mis-architect a whole system.
- Aeolun 7y ago
  Junior devs can absolutely mis-architect a system if you give them enough leeway because they’re described to you as senior developers.
- rurban 7y ago
  Normally it's the mid-level dev who mis-architects a system. It's called overarchitecturing. Seniors rarely overarchitecture.
  - watwut 7y ago
    Seniors both over architecture and underarchitecture.

pfranz 7y ago

I thought the article broke down those things rather well. It talks about how detrimental context shifting is, shifting priorities. In the part about how poor time estimates are, "No time is put in for meetings to go over requirements and make changes," not time is accounted for bugs, or the learning part about solving a problem.

drewcoo 7y ago

You can solve that problem honestly or not so honestly. I've worked in places where everyone knew to pad their time without telling the non-dev in the room. I've been happier with also estimating the ratio of time you spend doing tasks. Someone more senior should intend to spend less than 100% of their time on those tasks. Both of those work better than ignoring overhead or refusal to estimate, imho.

JimboOmega 7y ago
I don't think there's anything dishonest about estimating a task discounted for all the random org noise. It is annoying when your boss balks at your estimates using productivity when everything goes smoothly and there are no interruptions as the benchmark, though.

losteric 7y ago

Measuring and optimizing bottlenecks is a core agile idea. My team's process is to estimate and track dev non-dev time with our other sprint metrics at dev-day granularity. ie last sprint I estimated 2 non-dev days for product / design discussions, factoring in the meetings/doc writing/cost of mental randomization/etc. Planning and retrospective provide opportunities to reflect on reducing communication overhead within the team, and the metric is valuable for pushing back on top-down management-mandated overhead.

dmz73 7y ago

It may not be so much assumption that about being left alone but instead requirement to quote the time that will be used for billing. You can't pad that, it will be 20 days of work that client should pay for but that 20 days may be spread over next 3 months. Problem is that neither management or client hears that part even when they are repeatedly told multiple times.

_raoulcousins 7y ago

I'm always explicit when asked for an estimate. It's not the most political or business savvy answer, but I say things like "this will take 2 hours. On average I'll have two hours of focused time per day, so 10 days."

overdrivetg 7y ago
sorry for pedantry but you do mean "this will take 20 hours", yes?