> I agree with all of your characterizations. I couldn't spend year after year doing maintenance grunt work. Luckily, I get health benefits through my wife's job so I can jump back and forth between full time and contract work with abandon.
I understand but maintenance/refactoring grunt work is technically necessary which is why I think going for 100% top performers is a bad hiring strategy for a business is all. Systems need to be refactored regularly to maintain business logic consistency between services, remain stable as the ecosytsem they communicate with changes, and be secured.
> Yeah I know everyone considers themselves to be above average, but I'm the tech lead for my company so by job title and responsibility, I think I'm qualified to say that.
I believe you. I'm not here to argue ability, just the strategic merit of focusing on top performers.
> But I guess I need a more nuanced opinion. I wouldn't want to be on a team where my peers are mediocre at this point in my career. There is a difference in my mind between a "mediocre" developer and an "inexperienced" developer. A mediocre developer is one that isn't where they should be in terms of competence and expertise based on their years of experience.
Ah, and I think this might be a miscommunication partially as well.
To me there are basically 4 buckets of developers:
1) Top Performers (2X+ Developers. Highly skilled but tend to focus on personal growth. Tends to ignore long term pain points because they just will not be there that long.)
2) Mediocre (.75-1.5X Developers who should be used to do the non-architectural grunt work and refactoring. They tend to want to stick with an employer long term and tend to focus on medium to long term effectiveness because they'll feel the pain of deviation from that.)
3) Incompetent Developers (Experienced developers with little to negative net value who probably should really be looking for a new career. Or anyone who else who is substantially below the Mediocre range for their experience level / pay expectations. )
4) Inexperienced Developers (Little to negative net value who will probably need a couple years experience before you really know if they are a top performer or mediocre.)
> Even worse, is an "experienced" developer who makes horrible architectural decisions.
That is probably the single most painful experience in every software developer's career. Poor architectural decisions that cannot be properly refactored due to budget constraints. The number of times I've seen an incompetent developer break primary keys during a system integration/transition is too numerous to count.
I question the association between maintenance and mediocrity. It’s much easier to start a new project than to work effectively with a large codebase you didn’t write.
You'll notice the people that consider themselves top performers that responded to this post lean towards moving on rather than doing primarily maintenance work for years on end. I've seen similar sentiments echoed by others, hence the distinction.
Some people are starters. Some are finishers. Some are maintainers. Few are good at all 3. Most people seem to label fast starters as "top performers". But you can be a "top performer" in any category.
However, I would claim that if you never do maintenance work, you don't really know if what you're writing is crap.
I agree with you on that last bit as I'm basically a sysadmin/dev that gets stuck maintaining the systems when "top performers" move on to the next project. ;)
I understand but maintenance/refactoring grunt work is technically necessary which is why I think going for 100% top performers is a bad hiring strategy for a business is all. Systems need to be refactored regularly to maintain business logic consistency between services, remain stable as the ecosytsem they communicate with changes, and be secured.
> Yeah I know everyone considers themselves to be above average, but I'm the tech lead for my company so by job title and responsibility, I think I'm qualified to say that.
I believe you. I'm not here to argue ability, just the strategic merit of focusing on top performers.
> But I guess I need a more nuanced opinion. I wouldn't want to be on a team where my peers are mediocre at this point in my career. There is a difference in my mind between a "mediocre" developer and an "inexperienced" developer. A mediocre developer is one that isn't where they should be in terms of competence and expertise based on their years of experience.
Ah, and I think this might be a miscommunication partially as well.
To me there are basically 4 buckets of developers:
1) Top Performers (2X+ Developers. Highly skilled but tend to focus on personal growth. Tends to ignore long term pain points because they just will not be there that long.)
2) Mediocre (.75-1.5X Developers who should be used to do the non-architectural grunt work and refactoring. They tend to want to stick with an employer long term and tend to focus on medium to long term effectiveness because they'll feel the pain of deviation from that.)
3) Incompetent Developers (Experienced developers with little to negative net value who probably should really be looking for a new career. Or anyone who else who is substantially below the Mediocre range for their experience level / pay expectations. )
4) Inexperienced Developers (Little to negative net value who will probably need a couple years experience before you really know if they are a top performer or mediocre.)
> Even worse, is an "experienced" developer who makes horrible architectural decisions.
That is probably the single most painful experience in every software developer's career. Poor architectural decisions that cannot be properly refactored due to budget constraints. The number of times I've seen an incompetent developer break primary keys during a system integration/transition is too numerous to count.