>> A quiet place to work >> Clear instruction about tasks. Vagueness does not work. >> No sudden surprises at the work place. >> Written instructions for work that requires a sequence of tasks. Provide a “pilot’s checklist.” >> Correct social mistakes in a clear, calm, direct manner. Hints do not work.
I'll bet 7 out of 10 developers would agree with Grandin's requirements for an autistic-friendly business environment.
What kind of programmer are you? The following are the two things I would think programmers would want least:
* Clear instruction about tasks. Vagueness does not work. * Written instructions for work that requires a sequence of tasks. Provide a “pilot’s checklist.”
The former because the alternative is a huge checklist of features from sales and/or a horrendous design-by-committee architecture. The latter because, well, you're a programmer. If somebody was able to write the sequences of tasks
When I hire programmers, I want programmers that can take vague requirements, apply their intelligence and experience, and provide a solution that works well and can evolve*. Sometimes this might mean the ability to convince me my requirements are ill-considered. If they aren't self-motivated and self-directed, they're wasting my time.
That's fine if you have a small team that can communicate and work well together, but on larger projects the overhead makes that kind of collaboration impossible and having everyone running off and producing their own solutions is a recipe for disaster and you'll end up with people arguing over how it should be done and an utter nightmare when it comes to integrating the various pieces. Sometimes its a lot easier to iron out the requirements, produce a very detailed design, and only leave minor implementati
... six months later you've built the prototype of those ironed-out-requirements and detailed-design to find it is not what the customer actually wanted.
I have yet to see any problem, however complicated, which, when
you looked at it in the right way, did not become still more complicated.
-- Poul Anderson
Autistic-friendly business environment (Score:5, Insightful)
>> A quiet place to work
>> Clear instruction about tasks. Vagueness does not work.
>> No sudden surprises at the work place.
>> Written instructions for work that requires a sequence of tasks. Provide a “pilot’s checklist.”
>> Correct social mistakes in a clear, calm, direct manner. Hints do not work.
I'll bet 7 out of 10 developers would agree with Grandin's requirements for an autistic-friendly business environment.
Re:Autistic-friendly business environment (Score:5, Insightful)
I don't consider them autism friendly environment rules, I consider them to be business friendly environment rules.
Re: (Score:0)
What kind of programmer are you? The following are the two things I would think programmers would want least:
* Clear instruction about tasks. Vagueness does not work.
* Written instructions for work that requires a sequence of tasks. Provide a “pilot’s checklist.”
The former because the alternative is a huge checklist of features from sales and/or a horrendous design-by-committee architecture. The latter because, well, you're a programmer. If somebody was able to write the sequences of tasks
Re: (Score:2)
When I hire programmers, I want programmers that can take vague requirements, apply their intelligence and experience, and provide a solution that works well and can evolve*. Sometimes this might mean the ability to convince me my requirements are ill-considered. If they aren't self-motivated and self-directed, they're wasting my time.
That's fine if you have a small team that can communicate and work well together, but on larger projects the overhead makes that kind of collaboration impossible and having everyone running off and producing their own solutions is a recipe for disaster and you'll end up with people arguing over how it should be done and an utter nightmare when it comes to integrating the various pieces. Sometimes its a lot easier to iron out the requirements, produce a very detailed design, and only leave minor implementati
Re: (Score:2)
... six months later you've built the prototype of those ironed-out-requirements and detailed-design to find it is not what the customer actually wanted.