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.
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 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.
> There's not some magic thing that a senior developer has that a junior developer is missing.
"They're just better" is a way of saying "this is magic and not quantifiable". If you cannot quantify what factors allow one developer to consistently deliver quality software on schedule, then you cannot grow your team in that direction, and are essentially rolling the dice.
I'm all for figuring out explicitly how to deliver software better, but pretending that implicit knowledge doesn't exist seems like folly.
(make that 3 so far...browser closed)
I have trouble with that one myself. :-)
http://www.grammar-monster.com/easily_confused/past_passed.h...
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.
But a senior has more experience with the "why" behind the coding. What are the requirements in terms of schedule, user experience, stability, maintainability, performance, development process, QA, etc. A junior can be great at one of these, but a senior has to take responsibility for all of them. So you need to understand the needs of all the stakeholders outside the dev team. (At least the basics; functional details deserve an expert of their own.)
