In my experience, it's easy for developers (me included) to hang out at either end of the following spectrum:
On the left is when we stay in our lane. We're given a requirement, we interpret the requirement, and then we make it so. Easy peasy. But what's that? The requirement didn't mention validation and it's a form submission screen? Must be it's not needed! We just do what we're told. And likely we're not this pedantic, but the point is that it's comfortable at this end. We get work done, and we don't make waves. If something isn't right, we were just following orders.
On the other end is when we go rogue. We find some "requirement" that might be useful (but no one really asked for), or some new approach or technology that's interesting or "hot", and then spend the entire sprint in our coding cave joyfully building it out. Will it actually help the project? Err...maybe? Regardless though, it'll be fun, because we love nothing more than smooth sailing - not being beholden to the ideas, thoughts, or reservations of others (well, that is, until they see our 4k-line pull request!).
Unfortunately, in neither of these states does valuable work get done. I mean...sure, something is produced, but it's rarely the right thing - i.e. the thing the users or the business actually needs. Because this "right" thing is really hard to figure out. It requires understanding the business context, priorities, and time constraints. It requires understanding the needs, preferences, and behaviors of the users. And it requires understanding the existing implementation and the scope and impact of what is to be built. All of this must be hashed through to get it "right", and this "hashing through" process is what happens in the Ambiguous Zone. It's messy and frustrating, but it is the only way to produce something of real value.
The most effective developers I've worked with understand this, and are adept navigating this zone. They are curious about the perspectives and needs of other stakeholders, and ask good questions. They push back when things don't make sense, but do so tactfully. And they understand the realities of building software in an industry context, where there are budgets, deadlines, and other less-than fun realities. They don't expect everything is perfectly spelled out for them (whether by designer, business analyst, or architect), because they know, as the one closest to the implementation, they have a crucial perspective to voice. But they also know they don't have all the answers. In other words, they know that building the right software is a back-and-forth, collaborative process.
But not every developer or team works well in this Ambiguous Zone. And there is a tell-tale sign when it's being avoided: the conspicuous lack of discussion. When we're either doing only what we're told or only what we want, we have no need to talk with others. It's all laid out for us, either in a requirements spec or in our heads. If we do happen to meet, there is no disagreement, no requests for clarification, no passionate exchanges. And while it's alluring to think this quietude is a sign of efficiency or productivity (meetings suck, amiright!), it's NOT. Instead, it's a sign the team is avoiding the Ambiguous Zone, and the end product will be off target.
It's understandable though why we would avoid it - it's both risky and frustrating in there! First, we know that there's a real chance we may never make it out. We'll flounder in meeting after meeting with no resolution, and never get to build anything. (At least when we do what we're told or what we want, something gets produced.) It's also very hard to operate within the Ambiguous Zone, because it means navigating the imprecisions and imperfections of other human beings. This was tricky in "normal times", but probably more so in a remote-first environment (without the benefit of hallway conversations or other in-person interactions that build trust and enable quick information flow). Without these discussions, we don't understand the context, we don't voice our perspective, and we often don't find the right solutions.
My sense is that the Ambiguous Zone is an inconvenient truth about programming in industry. We're often driven to the field because it's deterministic and precise, but when we get here, it's much more fuzzy than we expect. In other words, there's a mismatch between the perception and the reality. Just look how we interview. We ask candidates to solve esoteric programming puzzles (i.e. do what you're told) or assess whether they built some interesting side project (i.e. do what you want), but rarely do we evaluate whether they can navigate ambiguity in a collaborative setting, which is just important to being an effective developer in the "real world". As an industry, we should emphasize, encourage, and train for this more. Happy to hear your thoughts!
