This definitely is in the right direction, but leaves out a lot of very important things.

I think of a senior developer as someone who is effective. Roughly that means:

* 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.

* 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.

* 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.

* 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.

* 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.

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.

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.

So someone who would qualify as senior in one place, wouldn't be very effective elsewhere.

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 better than a bronze player.

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.

I overlooked the first "then/than", but a few sentences later you had another.

(make that 3 so far...browser closed)

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?

My mother has a doctorate in social work, they have an idea in her field of "Critical Reflexivity". The idea being that theory and frameworks are vitally important to learn, but at the end of the day every case and every practitioner is different. To be a great social worker, it is not enough to learn theory and apply it, that is just the starting point. What you need to do is apply theory, but reflect at every step of the way on how it is working. This lets you build your own theory of practice, tailored to the way you work with people, and to the sort of people you work with day to day.

That resonated with me quite a bit, I feel like what she described to me is something all great developers I know do instinctually. I think at the end of the day, that constant honest reflection is the single most important thing to do for us. Our profession loves to pull ideas from math and other hard sciences, but at least from my part of it (product/business development), I think we can learn just as much from social sciences, if not more.

So what does that mean to a developer? When you see a problem somewhere, don't just stop at identifying it, try to classify it. What other problems are like it? Why did it happen in the first place? Read a lot of books about how to build software, but when you implement things from those books, try to reflect on the idea behind the solution, not just the solution. When it is done, reflect on how it worked out, and how the code looks at the end, what you like and what you don't like. If you go back to it, try to remember your initial feelings, and see how it panned out.

One big one: talk with marketing and sales about marketing and sales things. It helps you look into engineering from the outside, and see the other side of the interface - it shows you the pain of missed deadlines, and the surprising benefit of having that one extra feature. It helps you put real value to the output, and gives you context for measuring the worth of things you're spending time on.