I didn’t say that anyone liked the process, but I assure you that the average autistic engineer would actually do worse in a more feeeform environment. They would like it more though.
I didn’t say that anyone liked the process, but I assure you that the average autistic engineer would actually do worse in a more feeeform environment. They would like it more though.
Of course, if you actually enumerate the "how" and not just the "what" in your ticketing system, you can get a much more realistic view. "Add foobar RPC server", "Hook auth into the foobar RPC server", "Add foobar subcommand to CLI", ...
I think everyone does better with a clear set of expectations, autism or not. That's why we do design docs, design reviews, and try to put a realistic set of work into the ticket tracker. I would say personally, though, 99% of the time I don't really need to do that to get a good result out of myself. I can just say "by next Tuesday I will have this subsystem done". Typically this is done with heroics rather than good planning (Monday becomes a longer-than-average workday), so I try to avoid it, but I definitely understand why people want a more freeform environment.
And some management type will say when you're halfway through 'add' that they'll cut 'delete', but it's impossible to automate anything without a delete option, so you implement it anyway during your testing and then they get mad.