[HN Gopher] The Ambiguous Zone
       ___________________________________________________________________
        
       The Ambiguous Zone
        
       Author : kiyanwang
       Score  : 30 points
       Date   : 2023-03-28 06:57 UTC (1 days ago)
        
 (HTM) web link (www.bennorthrop.com)
 (TXT) w3m dump (www.bennorthrop.com)
        
       | closeparen wrote:
       | 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.
        
         | xyzelement wrote:
         | 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)
        
       | kerblang wrote:
       | 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.
        
       | [deleted]
        
       | Scubabear68 wrote:
       | 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.
        
         | m463 wrote:
         | Don't want to get out too early. I remember the waterfall
         | model. Can't go back up a waterfall.
        
         | [deleted]
        
       ___________________________________________________________________
       (page generated 2023-03-29 23:02 UTC)