> People have strengths and weaknesses; people have areas they've experienced before and things they've never done.
Nope, you can't reduce the differences between people's skills into "they had more years of experience with X (but fewer with Y)".
First, there are people who spent decades working with the same technologies, and still somehow failed to learn the essentials. Some people simply have almost zero curiosity and zero desire to self-improve. (Giving specific examples is risky, because they sound completely made up. An Oracle database expert, who doesn't understand the necessity of having a primary key? A Java developer who never heard about Map, so he kept implementing it over and over again as a set of methods, for each variable separately?) Being 10x more productive than these people is quite simple. But it is also possible to be 10x more productive than the average developer.
Just consider than "10x more productive" doesn't necessarily mean typing on the keyboard 10x faster. You can save time by using a library; this includes understanding and using the standard libraries instead of reinventing the wheel. You can save time by using the right abstraction, instead of copy-pasting all over the code. You can save other people's time by documenting the code you wrote. You can save testing time by writing unit tests. You can save everyone's time in the future by having a clear project architecture. -- Furthermore, you can increase the team's productivity by teaching your colleagues at least the basics of these skills.
There are people who are this good at the things they do regularly. (Which also happen to be the things I do regularly, so it is humiliating to see the level of skill I will probably never reach.) And they can still learn new things with at least the same speed as anyone else around them.
To clarify, I didn't mean to equate experience to skill in anyway whatsoever, as I tend to agree there is little correlation between the 2, especially when it comes to purely technical skills. I simply meant that someone who has seen a given problem, read the right article or studied the right area has some experience to share that someone who hasn't does not.
An Oracle database expert, who doesn't understand the necessity of having a primary key? A Java developer who never heard about Map, so he kept implementing it over and over again as a set of methods, for each variable separately?)
Neither of those examples surprise me that much. It’s not that uncommon that being able to produce something that vaguely works well navigating a messed up organization is what it takes to be productive. The bar on not being a totally messed up organization is low but tons of places don’t clear it.
Nope, you can't reduce the differences between people's skills into "they had more years of experience with X (but fewer with Y)".
First, there are people who spent decades working with the same technologies, and still somehow failed to learn the essentials. Some people simply have almost zero curiosity and zero desire to self-improve. (Giving specific examples is risky, because they sound completely made up. An Oracle database expert, who doesn't understand the necessity of having a primary key? A Java developer who never heard about Map, so he kept implementing it over and over again as a set of methods, for each variable separately?) Being 10x more productive than these people is quite simple. But it is also possible to be 10x more productive than the average developer.
Just consider than "10x more productive" doesn't necessarily mean typing on the keyboard 10x faster. You can save time by using a library; this includes understanding and using the standard libraries instead of reinventing the wheel. You can save time by using the right abstraction, instead of copy-pasting all over the code. You can save other people's time by documenting the code you wrote. You can save testing time by writing unit tests. You can save everyone's time in the future by having a clear project architecture. -- Furthermore, you can increase the team's productivity by teaching your colleagues at least the basics of these skills.
There are people who are this good at the things they do regularly. (Which also happen to be the things I do regularly, so it is humiliating to see the level of skill I will probably never reach.) And they can still learn new things with at least the same speed as anyone else around them.