Junior and Senior Developer classification is legacy
Should only your senior staff be allowed to deploy to production? And do you keep junior developers away from certain parts of the codebase? You're creating "team debt"!
I think the classification of developers as junior or senior originates from a legacy mindset, and a world of legacy technology platforms.
What did it even mean?
A junior were not allowed to touch certain parts of a code base? Only senior developers can deploy to production?
Perhaps what really lies beneath is the understanding of keeping long term stability and processes in place, which is favored by senior developers, but it can also cause an entire codebase and team to become legacy!
Long term stability was a necessity before cloud, open source and web 2.0.
Perhaps we should use the titles to keep the senior developers maintaining the oldest part of the code base, and let junior developers start something new? But that is practically never how it is done, because senior developers must start the new project right to make sure we maintain our guidelines and processes.
So we do things as we did yesterday, because this is how we've always done it.
We all know technical debt, but a less spoken about problem is team debt, which is the problem of too many senior developers with no fresh thoughts on the table. It eventually leads to permanent technical debt, which is impossible to get out of without a full-on rewrite.
And you shouldn't ever re-write a program, should you? Of course you should, use a young team and do it in a fresh way. Make sure the senior developers gets uncomfortable and learns a new way of doing things.
It’s harder to read code than to write it.
That quote from Joel's post linked above is placed a little out of context, but forgive me and let me explain.
In the context of re-energizing the team with a stream of young thoughts, it is important to rally their motivation and create a self sustaining force. You can't do that by letting new people sit and read code for weeks on end or by only letting them fix bugs.
They need to produce, see something real that they produced and feel proud about it and make some mistakes.
This is part of "growing up" as a developer.
So by the time you have come around to understand the old legacy code base that Gordon wrote in 2007, you could've reproduced 50% of the most critical features by being smart with cloud and open source, and doing less.