Comment by 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.