I consider myself one if these developers, aka a rockstar developer, although my rate is probably 2-4x based on (QA passed) number of work tickets I do Vs colleagues of same pay grade.

I have 25 years in the industry doing the same thing across multiple fields so I tend to understand a good (never the mythical best) approach to a problem, but I'm a quiet guy who doesn't speak up much.

The real pain comes when in design meetings and you can see people, usually less experienced leads, making mistakes, or having meetings trying to understand problems that you'd already figured out weeks ago. You try to bring the horse to water but often it just won't drink.

In ~30% of cases I later get called in to fix design level issues a system has when they've run out of ideas and are getting desperate, e.g. a security model that can't handle cross org/company resource access. At this point fixing it is a lot of work over many months.

I also get called in when the team leads have no idea how to spike something that is technically difficult or not in their problem domain and nobody else wants to touch. E.g. older Java devs that have no idea how to stream data from a SQL db over websockets accessed with a GraphQL API. If you're thinking this is easy, yes it is, however the devil is in the detail (working around incomplete callback Graphql specs, ORM frameworks bypass needed for performance, choice of streaming framework to use, custom db view and performance impact etc etc.)

Unfortunately, this advertising of ability or criticising design can, even with best intentions, come off as arrogance - to a good degree it is. It also breeds resentment, hence why I often keep quiet, and don't put my hand up when they ask if anybody in the team has (non contract specified) skills, because team welfare and knowledge sharing is more important than the individual for companies, and it's easier for others to maintain work they've designed themselves from the ground up.

Really liked Jon talking about the importance of experience in development. I just wanted to add that it’s also important to consider experience on the system. Even the most talented developers will need time to find their feet if they’ve only worked with a system for a few months.

So don’t treat developers as replaceable resources! If you fire an experienced team because you found some cheaper bums on seats elsewhere, you’ll usually pay the price!

What does the phrase "rare as the famous rocking horse byproduct" refer to?