3 ms·

> Throughout this initial period there are standup updates of the form “I’m exploring X, or working through problem Y, but should have something for others to t

> Throughout this initial period there are standup updates of the form “I’m exploring X, or working through problem Y, but should have something for others to take a look at soon” What is really going on is the developer has basically been given permission to not turn anything in. They are spending maybe an hour a day actually exploring/working on the issue and the rest of the day they are working on their own pet projects, playing games, watching netflix, whaterver. Heck, they might even spend just one day doing all their "exploring" and then see how long after that they can just show up for standup and extend out the "exploring" phase while doing whatever they want the rest of the day.

salt-thrower 5y ago
I think that's an overly harsh take. I've fallen prey to the pattern the author describes many times, and I inevitably end up making updates like that because I feel bad that work isn't getting done, which fuels a procrastination doom loop of anxiety and avoidance until I rip the bandaid off and hustle to make up the missing work. It sounds like you've never experienced this, and that's great for you, but don't discount what the author is saying. It rings uncannily true to me, and it sucks when it happens.
- nuancebydefault 5y ago
  Exactly. It is very easy to fall into the trap the author describes, for junior as well as senior engineers. Managers should ask for feedback early on in the process. This could be a first draft of the architecture or even a simple bullet list of assumptions and considerations. A look at that info by a fellow engineer or a product owner can highly impact the set of requirements, the design or the way of implementing.
leeoniya 5y ago
it really depends on what you're working through. i do this on occasion while experimenting and thinking through an architectural design. what matters is whether the end result is representative of the time spent on iteration and writing thrown-away prototypes. i will often not start writing code until a reasonable path is formed in my head, and then i may write a prototype that doesnt work out and have to loop back and rethink various aspects. it may take a week with nothing but vague updates in daily standups, but then something awesome to show that has gone through a bunch of private "pre-alphas". > For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. this really only applies if you: A) dont have a history of delivering quality solutions to non-trivial problems B) refuse to ask for help/feedback when you actually need it typically, the rest of the team is working on other things. there would be little value in me pushing various crappy prototypes just for the sake of providing updates that only serve to distract people with information that will be out of date in 24hrs. "too many cooks in the kitchen" is a real thing, too.

salt-thrower 5y ago

I think that's an overly harsh take. I've fallen prey to the pattern the author describes many times, and I inevitably end up making updates like that because I feel bad that work isn't getting done, which fuels a procrastination doom loop of anxiety and avoidance until I rip the bandaid off and hustle to make up the missing work. It sounds like you've never experienced this, and that's great for you, but don't discount what the author is saying. It rings uncannily true to me, and it sucks when it happens.

nuancebydefault 5y ago
Exactly. It is very easy to fall into the trap the author describes, for junior as well as senior engineers. Managers should ask for feedback early on in the process. This could be a first draft of the architecture or even a simple bullet list of assumptions and considerations. A look at that info by a fellow engineer or a product owner can highly impact the set of requirements, the design or the way of implementing.

leeoniya 5y ago

it really depends on what you're working through. i do this on occasion while experimenting and thinking through an architectural design. what matters is whether the end result is representative of the time spent on iteration and writing thrown-away prototypes. i will often not start writing code until a reasonable path is formed in my head, and then i may write a prototype that doesnt work out and have to loop back and rethink various aspects. it may take a week with nothing but vague updates in daily standups, but then something awesome to show that has gone through a bunch of private "pre-alphas". > For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. this really only applies if you: A) dont have a history of delivering quality solutions to non-trivial problems B) refuse to ask for help/feedback when you actually need it typically, the rest of the team is working on other things. there would be little value in me pushing various crappy prototypes just for the sake of providing updates that only serve to distract people with information that will be out of date in 24hrs. "too many cooks in the kitchen" is a real thing, too.