The Ambiguous Zone

March 20th 2023

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!

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (6)
Dan G.
March 20, 2023
One thing that came to mind reading it was about how that scale shifts based on how the team/management responds, though that would say more about the management than the devs.

Like, the scale is set around the idea that communication is open and welcome - in an environment where you're expected to do as your told with requirements and such, even asking probing questions and trying POCs can be seen as going rogue. Though I think that still ends up with the same result of being off target since the discussion is disallowed instead of just not happening.
Thanks Dan! Totally agree...and missed this point. It's often that developers would ideally like to be in the Ambiguous Zone, but the organization doesn't value this...and just wants them to do what they're told.
March 24, 2023
I agree with Dan. Leadership is usually why this breaks down. And it makes sense because they’re leading the efforts.

But also, there is very little lessons put into effective collaboration in schools. I’ve learned better ways of collaborating through creative projects. An example, if you do improv (I don’t), the first thing they teach is “yes and.” It’s a little tool to encourage listening, something I find tech and product leaders “don’t have time” for.

Fix your leadership and the benefits will trickle down.
Thanks for the comment and agreed. A friend ran an improv workshop for our company years back, and we learned the "yes and" approach...and it was really cool/useful.
March 29, 2023
As you allude to, silence isn't always golden and it can point to a lack of good questions, lack of curiosity and lack of ability to push back tactfully when things don't make sense.

In my experience there's little priority put on helping teams and individuals communicate effectively. It is often seen as being "touchy-feely".

It's not rocket science and with a bit of practice can make big improvements (with the big caveat the psychological safety is present!).

What would be interesting would be to find a way to measure the cost of silence or poor comms in the ambiguous zone...
Great points...and I think you're right...when people don't feel like it's safe/acceptable to voice their opinions, they'll stay silent. And agreed that we should put a higher priority on this. The developers with the better "touchy-feely" skills often are the most effective, IMHO.
March 31, 2023
Good thoughts. I think navigating the "ambiguous zone" is definitely an undervalued skill.

I'm not sure this was any easier in "normal times" though. Back in the day when in-person meetings were insisted upon, I would have had to get on a plane to figure out requirements whilst horribly exhausted and jet-lagged, hunched over a laptop in an unfamiliar environment. Now that everyone is used to async communications, it's easier for me to pull together the right people into an quick discussion to figure things out.
Ben're totally right. In some ways, remote communication can be way more efficient and less frustrating than in person. Curious if you (or anyone) has observed developers being a little more compliant in remote-first environments though - more "keep your head down" and "stay in your lane". That's been my observation, but might not be representative of anything.
April 03, 2023
It is painful to create a 4k-line pull request and be rejected because of a lack of communication. In my experience, it is effective to get the system owner's confirmation before starting such massive changes.
Yup, totally agree. And if the owner is willing to step in the Ambiguous Zone, then getting the confirmation should involve a little back-and-forth (questions, comments, ideas, etc.).

Thanks for the comment.
April 04, 2023
I saw a meme[1] on /r/ProgrammerHumor today that reminded me of some of the sentiments here.

I suppose developers that navigate your Ambiguous Zone effectively could be considered savvy in the field, and will continue to be relevant long-term.

Lol. I have not seen that, but will be sending that to people. :) Thanks.