[cod1r]

I suffered with this problem quite often with my previous job. There would be something vague assigned to me and I didn't quite get what to do but I also felt like if I asked questions, it'd give off a vibe like I didn't know what I was doing so I would just start programming and making a bunch of assumptions.

That wasted a lot of time which is a lesson to be learned from.

I also struggled with self management.

[dcminter]

My superpower as a staff engineer was having zero shame in asking questions. Anything from "what does that abbreviation stand for?" through to "what will the traffic look like when we go live?" - mostly people are worried about looking ignorant, so weirdly this makes you look both knowledgeable and confident! I wish I'd known that when I was younger...

[roenxi]

Unfortunately it is a bit more subtle than that though:

(1) Questions reveal a lot about someone's state of mind, particularly if there are a lot of them. If someone is actually struggling and doesn't maintain a vague silence, the people around them will figure it out even faster. Arguably not a bad thing, hiding things is a weak strategy.

(2) There is a certain type of middle manager who fears clarity, because clarity leads to accountability and at some level they have identified that as a threat to their careers. It is prudent to be very careful what sort of questions to ask that manager - "what does that abbreviation stand for?" is fine, "what is the exact problem here and what do you want the solution to look like?" or "I don't understand, can you get into the details of why you think that?" can be unexpectedly controversial.

So there is a superpower in having zero shame in asking questions, but the real trick of it is being able to identify the set of inoffensive, basic questions that will move a project along. There is a large class of technically-reasonable-politically-imprudent questions that an inexperienced engineer might ask to their detriment. I've never been afraid of asking questions but if the mindset behind the question isn't fairly polished then there can be backlash and a most people learn to avoid questions rather than getting good at being mentally flexible.

[dcminter]

Ok, I was a little tongue in cheek, so I agree it's a bit more complicated than just asking any question that pops into my pretty little head.

But I do think that not worrying about whether people will think I'm ignorant for asking is a very important first step that I could have applied successfully when younger. Confidence is hard earned though.

When explaining stuff I've been working on to others I often tell them "what the fuck?" is a suitable question (to try and lower this barrier) :)

[temp0826]

I would often ask questions I knew the answer to (or mostly knew the answer to) just to get insight into someone's point of view, or to give insight into my point of view (usually coming from ops/administration/devops pov), and sometimes as a way to subtly point out that they are doing something terribly inefficient from the 10000 ft view (usually to more junior devs who have tunnel vision on their cog).

[abeyer]

> I wish I'd known that when I was younger...

While I wouldn't say more people shouldn't do this more of the time, there is also a lot of social capital you have as a staff level person that makes it "easy" to do this. (and is part of why it's important to)

[libraryofbabel]

Was just about to say this. As a staff engineer your position is (or should be!) so secure that you can get away with asking all sorts of “dumb” questions that more junior engineers don’t want to ask. I will also regularly say things in meetings like “I don’t understand, can you take us through that again” or “can you remind me how <xyz thing> works?”. Sometimes this makes the difference between a meeting being useful and everyone just being confused but afraid to say so.

In an ideal world, juniors would all do this too, but I don’t blame them if they don’t. So it’s very important to do it if you have the social capital.

[gmane]

One of my favorite interview questions for senior positions is "Tell me about a decision you made that you would change in hindsight." Junior level people and people who are otherwise unfit for the role will try to give answers that minimize their responsibility or (worst case) have no examples. Senior level people will have an example where they can walk you through exactly how they messed up and what they would have done differently. Good senior level candidates examine their mistakes and are honest about them.

[kyralis]

I do this for everyone, not just senior positions. "If you were to start that again today, knowing everything you do now, what would you do differently?" is a question you can ask regardless of seniority. Even if they've only done some school projects, being able to look back and say "yeah, that could have gone better from the start" is a hugely valuable signal.

The details of how I ask it might change based on seniority, but that I ask it? No.

[hosh]

It’s also true that the kind of people who are ready for staff level work are already doing staff level work. While social capital is a factor, it isn’t necessarily accumulated because of title or experience.

The idea of “disambiguation” is itself ambiguous. The way I recognize other people solving problems at a staff level is we are communicating in terms of properties, constraints and tradeoffs. Crucially, these constraints are not necessarily business constraints, but rather, constraints inherent to an architecture. For example, queuing works for ordering because it append-only, and monotonic. So as soon as you have multiple queues (such as partitioning) or try to reorder it, it also loses its ordering guarantee. Does the problem require ordering?

The first couple chapters of Roy Fielding’s dissertation goes through this. The first time I tried reading it, I did not have experience to understand. It was a slog and I got little out of it. The next time I tried reading it, it was helping me gel and articulate things I had started observing from experience. I recognized that I had previously been so focused on architectural elements and that the properties and constraints were far more important. It is this that determines what is being traded off, and antipatterns pop out. Knowing properties and constraints allows me to quickly identify problems, and start the process of disambiguation. Many of the other staff or principal engineers I have chatted with communicate along these lines.

I don’t try to ask smart questions or dumb questions. I ask questions so that I can understand properties and constraints.

[I_AM_A_SMURF]

For sure, a staff engineer asking lots of question is "disambiguating" a junior engineer asking a lot of questions is asking somebody else to figure out his/her project. Which is kinda true in a sense, you don't give a super-vague project to an engineer who's just starting up for a reason.

[mooreds]

Yes, this is so powerful.

One of my favorite moves is to ask a question that I feel has an obvious answer and then say "what am I missing?" Sometimes I am right, other times I am missing something.

Either way I'm modelling:

- that it's okay to ask questions to which the answer seems obvious

- that it is totally fine not to know everything

[jofzar]

Mine is "I'm going to ask the stupid obvious question here", then ask the question.

[gerdesj]

In general people like to answer questions - it makes them/us feel mildly superior - hopefully in a good and positive way. You have to use some judgement on how to approach and engage.

Depending on who you are engaging with, a packet of Hobnobs (other socially acceptable bribes are available) might be needed or perhaps waiting until after lunch.

Now, your next mission is getting something done by making someone else think it was their idea in the first place. It might sound counter-intuitive: "How does that benefit me, they get the credit". Crack that conundrum and you will advance to the next level.

[ignoramous]

Reminds me of Jason Freedman's "I don't know": https://news.ycombinator.com/item?id=7334671 (2014) / https://archive.vn/Z7m9M

[eftychis]

100% this: if you go every axis of what differentiates staff from senior one will see deep down it is about asking questions: either yourself or helping others ask the right questions (e.g. mentoring, impact/are we solving the right problem, etc.)

[calmbonsai]

Eh, I'd say that's very org-cultural dependent.

Honestly, orgs that don't "get this" is why consultants exist.

[tintor]

Schools don't teach this to students.

[spike021]

I struggle with this a lot. I'm currently about ten years in to the career and technically at my org I'm a "senior".

One issue I have quite often is I'll know I have a problem with understanding something and so I ask my team but then the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging. I think a lot of the time I notice people conflate experience level with amount of context I have with something.

I'm still struggling with these kinds of challenges and I would readily admit it could be my own weakness but I also wonder if it's a team culture issue; but I've noticed this across my current org and my last one so maybe it's more of a me-problem.

[Cockbrand]

> [...] the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging.

This is definitely a cultural problem. You should get clear and non-judgmental answers to questions like these, because it should be regarded as absolutely normal that you can’t keep everything in your mind, or that you may have missed some context.

In a culturally healthy org, everybody supports each other.

[agumonkey]

usually what i did is to take an abstract spec, derive thick layers / modules to decompose the problem, and then look at the deadline to see what MVP i can draw in that space.

whenever that mvp is not what was expected, if i'm lucky enough, the decomposition allows for easy adjustements to match the need

[mateo411]

This is very common behavior. This is where a good manager can really help. They can recognize this is happening and then provide context.

One approach to deal with ambiguity is to write a short design doc, which writes down what you are trying to do, and all of the assumptions that you are making. If you don't understand the domain, some of your assumptions will probably be wrong. The stakeholder should be able to see that and provide guidance.