[DannyBee]

"Most inventors are not professors"

This is not a great example. In academia, that's because they are fundamentally different jobs in most cases.

Most of the professor roles are not teaching their research, and where they are, i would bet your best professors are the inventors. But most are researching x and teaching y.

By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.

The notion that people who refuse to mentor or attend meetings (assuming these are symptoms of the same "not team player" phenomenon, and not something else) are rockstars is, imho, pretty misguided.

Even if you assume the 10x people silliness is true, each person mentoring 2-3 new people and building them will make the organization more productive than your 10x person fairly quickly.

(Again, situation may be reasonably different if you only will have a team of one or two, etc)

[dtech]

> By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.

I don't agree, senior tasks are often much more high-level and related to figuring out requirements/stories, or their tasks are hard enough that explaining them to juniors is not the most productive.

[DannyBee]

I'm kind of confused here, so i feel like i missing something. The way this is written makes feel feel like you you don't think the junior devs need to become competent at those high level tasks over time? Otherwise, how do they become senior devs if not by things like "gradually delegate higher level work, see what happens, help them learn by mentoring them based on results". It's not like they read a book and suddenly know how to do that.

"hard enough that explaining them to juniors is not the most productive" I strongly doubt this. Most of the differences i've seen over the years are in approach to complexity, and not level of complexity themselves.