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)
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.
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.
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.
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.
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.
Point well taken, Abeyer. We are just a simple church building...but RPI's beautiful Voorhees Center looks more like "The Computer Cathedral". If you are ever in our area, come visit us.
Source? The wikipedia article makes it pretty clear that it was in response to the 9/11 attacks. It got delayed several times so it ended up taking 2 decades to implement, but Trump had little to do with it. The May 7, 2025 deadline was set back in 2022, under Biden.
To my knowledge the deciding factor between which state ids were considered compliant and which were not was whether the state required disclosing and documenting immigration status to get a drivers license. In theory there are other rules, but the rest of them were pretty universally followed already anyway.
In addition, the source you linked explicitly points out that the id standards were just one part of a bill that "would repeal the provisions regarding identification documents in IRTPA, replace them with a version that would set the federal standards directly rather than in negotiation with the states, and would make various changes to US immigration law regarding asylum, border security and deportation."
> UX which requires more thought and skill, but is way more powerful. Human devs are mostly too lazy to use
Really? My thinking is more that human devs are way too likely to sink time into powerful but complex tools that may end up being a yak shave with minimal/no benefit in the end. "too lazy to use" doesn't seem like a common problem from what I've seen.
Not that the speed of an agent being able to experiment with this kind of thing isn't a benefit... but not how I would have thought to pose it.
Most of the blue collar coworkers I've had knew full well that you just needed to add some hydrocodone into the mix and you'd be fine w/ a few hundred mg on the acetaminophen for a full shift.
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)
reply