Why knowing nothing about everything doesn't make you 'senior'

The cliched view of what makes you senior in the world of software engineering is that you just know more about something than everyone else. You’re the in-house expert on whatever tech stack you’re working with, and getting seniority means knowing ever-increasing detail about that stack over time.

The other view is that seniority is knowing about more things - not only are you the expert on the latest Javascript framework, but you also know Kubernetes end to end, and can optimise a database structure for shits and giggles when the need arises.

Both of those concepts have flaws. Knowing more about everything has finite bounds - there’s just a physical limit to how wide a range of topics one brain can stay current on. Knowing everything about something also has diminishing returns - very few roles in development consist of needing ultra-detailed knowledge of every last edge case of a framework, to the exclusion of everything else.

On the one hand, you can know everything about nothing. On the other, you can know nothing about everything.

The mental model of seniority that’s evolved in my mind doesn’t have much to do with the amount of things you know about something, or the range of somethings. Instead, it’s about your ability to change and refocus your mental scale when dealing with complexity.

[A caveat. This concept only considers technical seniority, in other words expertise. That’s only part of what being senior in a software development role is about - this says nothing about the people side of things. Of the two, expertise in dealing with people is the more important, but I’m not convinced that a Grand Unified Theory combining both is either practical or sensible.]

Changing scales

By scale, I mean the level of detail that you’re working at. Biology has the concept of the ecosystem, which translates well to software. Imagine you’re zoomed into an insect eating a leaf. Then you zoom out slightly, and there’s a rodent about to eat the insect. Zoom back another step and there’s a bird of prey about to drop out of the sky to eat the rodent.

Everything is interconnected, too - if there aren’t enough leaves to go around, there will be fewer insects, and fewer rodents, and fewer birds of prey. The ecosystem connects everything together - changes at one level ripple through causing changes at other levels.

Software development is often about making very small changes in very specific places. Changing a value in a database field could be as literal as flipping a bit from on to off. Or unit-testing a function to by setting up a given set of inputs and verify that a specific result is returned. That’s focussed, intense, micro-scale work. It’s where we seek the coding flow-state - getting “in the zone” where the code almost writes itself and hours seem to pass in microseconds.

Ecosystems and contexts

But those micro-level code changes exist in an ecosystem, too - changing the value of a database field updates the user entity. The user entity encapsulates the concept of a user and how they relate to the system. The database acts as a service to the code that changes the value.

Those services sit within an operational context. The operational context includes very small elements, down to the level of examining the source IP in a packet to determine if the rule is satisfied and the traffic should be passed. But services need to be scaled, so suddenly there are multiple instances of database services. But down at the micro-level, as soon as we have multiple instances of databases, we have to worry about consistency of records.

Zooming in and out

The point is that to understand the “system”, you have to be able to constantly change the scale of your focus - from large-scale, soft and fluffy concepts like “does this app deliver the right user experience” to “can I be sure that traffic on these ports is blocked on that VPC?”

The more senior you are in a development environment, the more changes of scale you have to deal with on a daily basis. Instead of focussing closely on just one small thing, you’re suddenly responsible for lots of them. But responsibility means not only understanding the “how” something works, but also the “why” - how that thing fits into the big picture both technically and organisationally. Often even politically, too.

As developers this is something we do unconsciously all the time already. Some people turn out to be good at it without ever needing to really think about what they’re doing. I’m not convinced I fall into that category, so over time I’ve come up with a couple of processes - hacks, really - to try to figure things out.

The big picture

The first is to try to get a unified picture of what the components that I’m dealing with are, and how they fit together at various scale levels. It’s a case of asking “how does this component fit into the big picture?” “what does it talk to?” “how does it come into existence”? “how and when does it disappear?” Physically, that looks like lots of diagrams with lots of boxes and lots of arrows - one way of thinking about this is as the C4 process without the terminology overhead.

Spinning it around

The second approach builds on the first. You need to be able to rotate that model in your mind to view it from the perspective of the different actors in your environment. How do things fit together if you’re looking at it from the user’s perspective? How does an HTTP request make its way through the various services? How do things look if I imagine myself as data flowing through?

If you’re explicit with yourself about the perspective you’re taking right now, and what scale level you’re dealing with, you’ve got a a fighting chance of being able to tell if you’re looking at things in the right way.

Communicating versus bullshitting

The question I haven’t got an answer for is how it’s possible to objectively assess someone’s capabilities for doing all of this, without working with them over an extended period of time. Being able to do the mental gymnastics is one thing, but communicating them is a whole other. There’s a fine and subtle line between being a skilled communicator and being a skilled bullshitter.