The Ambiguous Zone | Hacker News Reader

The Ambiguous Zone

bennorthrop.com

39 pointskiyanwang6 comments

An interesting thing I've observed in Silicon Valley is that it is precisely the ability to navigate ambiguous problems, not years of experience with particular tools or domains, by which we define seniority. A junior engineer is someone you have to spell it out for. A senior engineer can be pointed in a loosely defined direction. A staff+ engineer can point themselves at the highest impact things.

I think this is right, and I even think that some of what is often complained about in tech interviews is actually about testing for this.

Folks say "give me a take-home assignment I can code on my own" rather than "stressfully whiteboard in a time-crunch in front of people" but I think they often don't understand that this scenario isn't meant to elicit your best code, but to evaluate how you perform in a scenario where everything isn't crisply handed over to you to digest on your own time. Dealing with ambiguity - and asking questions to quickly get to sufficient clarity - is a bit part of that (other elements include literally dealing with dynamic collaboration and a bit of pressure)

If you actually resolve all ambiguity perfectly, you end up with: The program itself. The most important thing is clarifying the nature of the problem people want to solve; if you know that much, you can make some kind of headway with minimal churn and burn. Then get feedback, rinse, repeat.

I have seen cases - watching one right now, in fact - where mgmt tries to push a no-problem project through, just "well get the data and make some screens and things and whatever" and the only possible outcome is failure.

A good developer should ideally push their organization out of the ambiguous zone. Give feedback to whoever is writing requirements on the gaps.

Otherwise, if you are in that ambiguous zone regularly, either you are pioneering some super new innovative area, or your organization isn’t very good at software development as a whole.

One org I was at, the product managers constantly complained that developers couldn’t read their minds and automagically “know” all the non functional requirements, validations, etc. They were used to working with super senior devs who knew the space well, and could not adapt to devs who were more junior and also new to the industry vertical.

Don't want to get out too early. I remember the waterfall model. Can't go back up a waterfall.

My experience is that a lot of devs cannot or do not want to actually talk to users and learn how they use the software and what the need from it, and suggesting that they do this is considered an outrageous waste of precious dev time (I'm paid to code, not go to meetings). What's worse, is that a large part of the industry works to a set of tightly defined processes that are designed to buffer devs from users.

I am talking of course about scrum, story points, product managers, scrum masters, product owners, rituals, etc. All the crap and layers of indirection that sit between devs and the people who actually use the software.

Devs should be talking to and working with end users and building up an understanding of what users want and need from the software. I mean this literally. Actually sit with, work with, and talk to users, don't just communicate with them through an issue tracker.

You sometimes see this in early stage startups, but even startups often end up designing for VCs or designing to be acquired, rather than designing for users.

Yes users sometimes need training on how to communicate requirements, but it is up to devs to do this. Don't expect them to magically acquire this skill out of nowhere.

Reply on news.ycombinator.com