How developers do their best work, what protects flow state and what breaks it, why clear requirements matter especially for neurodiverse developers, and the real measure of a requirement's success.
The developer’s flow state
Developers prefer to solve technical problems rather than hash out incomplete or poorly formed requirements. They want to apply the breadth of their technical knowledge to design appropriate solutions and learn new skills along the way.
Developers also enjoy working in a “flow state” for extended periods of time, focusing on solving the problem at hand. Every software developer has experienced being so immersed in their work that hours literally flew by without being noticed. This is where the real enjoyment of software development lies.
When requirements break down
Picking up some work to find the underlying need hasn’t been fully articulated is annoying, although often easily addressed with a quick conversation. Continuing work to hit another blocker that can’t be as easily fixed is more irritating, requiring emails and perhaps more conversations. Sometimes, the work becomes completely blocked as the need for further analysis emerges. Seeking further clarification is required.
While some developers can perform the analyst role, they really shouldn’t have to. Instead, developers are most effective when they can resolve the right amount of detail upfront or early in their work, before proceeding with the software development relatively unhindered. Developers thrive when they can determine their own work schedule.
Working in a focused manner is not a ‘perk’ of being a software developer; instead, it’s an inherent part of working effectively on complex problems in complex domains. One unscheduled phone call or interruption, even just the threat of that, can be enough to break concentration. Being able to focus is a reasonable expectation for any knowledge worker.
Solution design and implementation
Software requirements describe what the software should do; a solution design defines precisely how it will be done. Software requirements avoid specifying solutions and implementation details where possible, allowing the requirements to proceed without undue concern for solution options too early in the process. However, once the software requirements have been written and agreed with the stakeholders, then a solution design can be produced.
Simple changes to an existing codebase don’t require a solution design because developers can extend it in a familiar pattern and work out the minor details themselves. Development standards and design patterns are leveraged. Slightly more complicated changes can still be delegated to the technical team, often overseen by a technical lead or in collaboration with another developer. Writing documentation and noting key architectural decisions is a pragmatic way to proceed.
New software projects, substantial changes to an existing application and complex functionality will require a more detailed consideration of the software design. A dedicated technical architect or an entire architecture function will usually be responsible for this. Several implementations may be possible, but the solution design clarifies which one to use. Large development projects, inexperienced developers and offshore development teams value having detailed designs to follow.
Requirements and neurodiverse developers
The flow state, the freedom to schedule one’s own day and the relief of working without unexpected blockers matter to every developer, but for some they matter more than most. Autistic and neurodivergent people are widely recognised as over-represented in technology roles, and the same ambiguity that merely irritates one developer can be a genuine source of hidden anxiety for another. Good requirements give certainty and structure, not just direction. Understanding why that matters so much to neurodiverse developers is part of understanding what good requirements really enable.
‘Can’t you just collaborate for once’ said the frustrated manager, perhaps not an uncommon experience for the developer it was directed at. But maybe they really could not collaborate, at least not in the way expected of them. Noisy office space, unstructured meetings, verbal instructions, business jargon and lack of written documentation might have been factors at play.
Around 1 in 6 people working in technology are believed to be autistic, a much higher rate than the general population (Tony Atwood, 2022). Neurodivergent traits can be incredibly valuable for technology workers, hence the increased prevalence; however, these individuals see, hear and process the world differently, sometimes drastically so. ADHD and other conditions often co-exist, adding to an already complex situation. Difficulties can arise, both interpersonally and at work, such that autism is a recognised disability under UK law.
Professional understanding, diagnosis, and access to support are relatively recent developments, not yet widespread, but certainly more prevalent than 20 years ago. Many neurodivergent individuals have lived their entire adult life flying under the radar, undiagnosed, unsupported and coping as best they can. I’ve worked with developers who fit this pattern exactly: highly capable, technically meticulous, and struggling with the informal, verbal, ambiguous side of team delivery. The reasons weren’t attitude or wilfulness. They were structural, and good requirements helped.
Certainty, structure and routine are everyday needs amongst neurodiverse individuals, coping mechanisms for high levels of hidden anxiety. By their very nature, software requirements reduce ambiguity and clarify what’s required. Good software requirements do this to a level sufficient for the developer to work without worry. A welcome relief for many individuals.
The real measure of success
The measure of good software requirements is whether developers can schedule their own day and work in a focused manner without unexpected blockers or the need for unplanned conversations. Ceremonies, appropriate conversations and alignment of work should only happen because they are valuable to the software developer, rather than imposed by a framework or overbearing agile coach.
This is also the right way to think about managing the developers themselves. Focus more on your process and tooling than on individuals. Clear structure, well-defined requirements, regular collaboration and a shared definition of done bring the transparency you seek without the temptation to micromanage. A well-functioning development team will more than make up for differences in individual performance, and good requirements are the foundation it stands on.