This definitely is in the right direction, but leaves out a lot of very important things.<p>I think of a senior developer as someone who is effective. Roughly that means:<p>* Planning: Ability to take on large, ill-defined problems, define them, break them up, and execute the pieces. A senior developer can take something big and abstract and run with it. They will come up with a few options, discuss them with the team and implement them.<p>* Execution: When something is planned a senior dev can execute quickly. They make tradeoffs, and they know why. They know where to be dogmatic and where to be pragmatic. They also can code well obviously.<p>* Communication: Effective developers are great communicators. They probably overcommunicate, gather feedback on non-trivial things, and thoroughly investigate feedback received. People often will say "give me feedback" but what that means is "tell me why my solution is right." For senior developers it's "poke holes in my solution." This can be very evident in pull requests -- junior devs can easily become attached to their solution, become myopic, and be unable to take feedback.<p>* Leadership: They are aware they're on a team. They view it as a part of their responsibility to mentor others. This can range from pair programming with junior devs, to taking unglorious tasks of writing docs or tests or whatever else needs to be done.<p>* And finally, they've been burned a lot. They can foresee where the problems will be before a single line of code is written, because earlier in their career they've been burned by a lot of things. An intermediate dev (or perhaps a junior dev) has been burned by poor spaghetti code, and has swung over to nailing everything with the GoF hammer.<p>Another thing that I have noticed how much of the above applies to senior designers as well.
Something that I think gets missed often from these discussions is the idea of different definitions of 'senior' in different contexts. If you're working at Google on search algorithms, it doesn't matter how good a communicator you are, if you aren't technical enough to understand the work and think about how to improve it, it's not much use.<p>Conversely, if you're a brilliant architect but aren't great at being very pragmatic and hacking stuff out, you might not add much value to a lot of smaller webshops.<p>So someone who would qualify as senior in one place, wouldn't be very effective elsewhere.<p>And as developers, we can try and identify our own interests and skills and find work that fits these.
I know you admit that it's a gross oversimplification but this kind of talk still bothers me a lot. It's a lot like when, to use a (honestly shoddy) metaphor, people talk about rankings in a video game like League of Legends. Some times you'll hear talk like "the difference between a bronze and silver player is game sense!" or "objectives control!" or "mechanics!". The truth is it's all of these things and none of them. A silver player is simply <i>better</i> than a bronze player.<p>I think the same goes here. There's not some magic thing that a senior developer has that a junior developer is missing. They are simply, overall, better.
What are some tactics you can use as a junior/intermediate developer in a company with a lack of senior developers to mitigate the risks you discussed and foster growth?