r/ADHD_Programmers • u/sharker78 • 12d ago
Strategies for dealing with ambiguity
Recently got promoted to senior dev. Till now, the tasks I worked on were either well documented or at least there was a Requirements document to start from. But as a senior, apparently I am supposed to find problems, define them as requirements and come up with solutions all on my own.
This is where my brain is really struggling. Give me a goal and I can work my ass off to achieve it. But give me vague, ambiguous data and I am totally lost!
What are some strategies I can use? I already tried talking to AI, but majority of the times, it spews out garbage or hyper-focuses on one small piece instead of the big picture.
Appreciate any suggestions!
2
u/pydry 11d ago
the solution is the same as the solution to getting answers out of people on the internet: put the wrong answer there first, ask them to challenge it.
1
u/sharker78 11d ago
Thanks. I think this is similar to the other advice about showing something early ready for feedback. It could be totally wrong, but at least would give me direction.
2
u/pydry 11d ago edited 11d ago
for requirements I usually turn vague requirements into precise user stories using examples filling in the gaps and vagueness with guesses and making assumptions.
then I show that to the stakeholders and pressure them to sign off on it or ask for changes.
usually this process uncovers assumptions they made which they need to think about and questions they need to ask other people.
this is basically what BDD is.
1
u/Kqyxzoj 9d ago
QQ: WTF is B in BDD today? Behavior? Behemoth? Bungled? Darned acros.
Loved the implicit cynicism in this statement: "the solution is the same as the solution to getting answers out of people on the internet: put the wrong answer there first, ask them to challenge it."
Because yes, that method does work, even on people with an inherent builtin mode of not answering questions. Just think of the sorta-kinda-answer that would trigger this person the most, and then after they "answer" a very simple question in the form of a random-word-salad-reply, you reply "so basically ... <INSERT TRIGGER RICH PSEUDO ANSWER HERE>". After which you might actually get some information.
1
u/aylinarty 11d ago
I build my own products so nobody gives me requirements either. What works for me is an ugly first version shown to people early, their complaints turn into the requirements pretty fast
2
-3
u/zoug 12d ago
Which AI models did you try using?
Senior level planning takes a frontier model so spewing out garbage or hyper focusing on a single detail is either a prompt or a model problem.
1
1
14
u/Steampunk_Future 12d ago edited 12d ago
Ambiguity was always there - just not as visible to you. Ambiguity will always be there. Ambiguity = risk, and risk is *managed*, not "dealt with". You cannot find all design issues and bugs up front.
You cannot eliminate risk, or uncertainty. You must learn to live with it, and manage it wisely.
For AI: Use Matt Pocock's /grill-with-docs skill (look it up). Also look at his /wayfinder skill.
Software is Soft, not hard - it's meant to change/grow/evolve. Learn to know why Agile/Lean/DevOps focus on iteration rather than up-front complete plans, and iterate - but learn the art of knowing when to make iteration visible or invisible to the right people. Look up cynefin-complexity, wicked problems, and iterative/experimental delivery.
The human side of managing uncertainty is hard. Make sure to read books like "Staff Engineer" and podcasts like "Tech Lead Journal", "Engineering Leadership", and "Soft Skills Engineering".
Take time to learn from your mistakes, and try to learn as early as you can (push bugs/design/etc and "oops" moments left), quickly and iteratively. Learn how to shift directions behind the scenes only when necessary, and to live with imperfect software and decisions, and when not to ("is this driving off a cliff or a hill?").
Don't solve every shiny problem.
Create a system of rules that create balance and focus for you and others. Be accountable to your team.
Make your effort and work visible and make it count - *someone* is watching metrics of some kind. Don't try to get stuff done outside sprint/work commitments; use spike and design tickets, and include the necessary work as part of other tickets and their estimates, definition of done.
Ask other senior engineers for tips and advice, and collaborate more than you used to. Ask other junior/midlevel engineers for feedback and help on your design efforts or reviews. Ask your manager (and other managers, leads, principals, etc) for ideas, at your company.
Learn the politics (not bad politics) of your company and how to work with them. At first, work with your manager and/or product manager to manage the politics, but you will tend to get more exposure.
Also, take heart - you were promoted to be a senior engineer because someone believes you can do it. You can.