If I understand properly, that thread is just a description of a 10x developer is an hypothetical superhero, a genius engineer.
Those persons actually exist for specific projects of low and medium complexity. In the majority of the cases they achieve that quality with the years of maintaining the software. In some cases they are the leaders of such projects, in many other cases they are the creators.
They are the ultimate solution for project managers with low managing skills, less people to control and a simplified communication process. They look for 10x engineers but they actually perform like 8x, worth like 15x and they are paid like 2x.
This is just the dream of some low-quality managers. It should not be taken as an strict goal to reach by the engineers.
From my point of view, the key is not about the people itself. It is more important is how the company manages the information. What makes the engineers 10x is the knowledge they have over the business logic, the application and the IT layer. Sharing that information from top to bottom would make regular engineers with a balanced life, to perform more than 10x.
I strongly believe that not body is inherently better than other, it is just a matter of how much information they have acquired and how that information was shaped in their brains.
In some companies the CEOs, CTOs, are paid 100x or 200x and the value is because they worth it. But not because they are super heroes, it is because the information they have over the business logic, the application or the Technology that the companies uses to operate.
Subordinates are intended to do just the little part they are concerned without having an overall view of the context. Some years ago, I was hired by a company that had a complex system, no requirements written, no description of the processes, no comments in the code, ... I had to figure it out everything just by reading the code. I understood soon that was intentional, and my chief was pleased that I did ask everything because that made him feel more valuable.
Instead of explaining the logic, he used to translate the task to explanations like: "You just have to put a button here, a database field here, and make the calculation with this formula". I did quit as soon as possible, because I felt that like blind programming
There is an interesting development paradigm called Domain Driven Design that seems to look for the mechanism of sharing all the knowledge of Business Logic (the problem domain) and quickly broadcast its changes to the engineers (Event Sourcing and Event Storming).
There is also a programming paradigm called Feature Oriented Programming that models the domain features by mean of entities that can automate the software creation or generate part of them. This seems to be an attempt to model reusable structures (which represent the projection of the concepts of the problem domain) and combine them to get the product.
We also have the last advances in Devops, with technologies that aids the build, develop, test, and package into reusable deployment units that can be customized and combined during provisioning by mean of managed configurations.
If one focus on the big picture that is Enterprise Architecture, everything seems like an attempt of cross-sharing information of its layers (Strategy, Business, Application, Technology, Implementation and Migration) in the form of reusable structures of lower complexity that can be combined in different contexts by engineers.
If we keep in mind that engineering is not focused into discovering new knowledge (that is science), just to apply the knowledge for build solutions... then we agree that everything is trending to give more X to the performance of regular engineers.
So please everybody stay quiet, just stay tuned and do not pretend to be a genius or 10x engineers... If we keep us up-to-date with the trends we will soon become all 100x ones.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If I understand properly, that thread is just a description of a 10x developer is an hypothetical superhero, a genius engineer.
Those persons actually exist for specific projects of low and medium complexity. In the majority of the cases they achieve that quality with the years of maintaining the software. In some cases they are the leaders of such projects, in many other cases they are the creators.
They are the ultimate solution for project managers with low managing skills, less people to control and a simplified communication process. They look for 10x engineers but they actually perform like 8x, worth like 15x and they are paid like 2x.
This is just the dream of some low-quality managers. It should not be taken as an strict goal to reach by the engineers.
From my point of view, the key is not about the people itself. It is more important is how the company manages the information. What makes the engineers 10x is the knowledge they have over the business logic, the application and the IT layer. Sharing that information from top to bottom would make regular engineers with a balanced life, to perform more than 10x.
I strongly believe that not body is inherently better than other, it is just a matter of how much information they have acquired and how that information was shaped in their brains.
In some companies the CEOs, CTOs, are paid 100x or 200x and the value is because they worth it. But not because they are super heroes, it is because the information they have over the business logic, the application or the Technology that the companies uses to operate.
Subordinates are intended to do just the little part they are concerned without having an overall view of the context. Some years ago, I was hired by a company that had a complex system, no requirements written, no description of the processes, no comments in the code, ... I had to figure it out everything just by reading the code. I understood soon that was intentional, and my chief was pleased that I did ask everything because that made him feel more valuable.
Instead of explaining the logic, he used to translate the task to explanations like: "You just have to put a button here, a database field here, and make the calculation with this formula". I did quit as soon as possible, because I felt that like blind programming
There is an interesting development paradigm called Domain Driven Design that seems to look for the mechanism of sharing all the knowledge of Business Logic (the problem domain) and quickly broadcast its changes to the engineers (Event Sourcing and Event Storming).
There is also a programming paradigm called Feature Oriented Programming that models the domain features by mean of entities that can automate the software creation or generate part of them. This seems to be an attempt to model reusable structures (which represent the projection of the concepts of the problem domain) and combine them to get the product.
We also have the last advances in Devops, with technologies that aids the build, develop, test, and package into reusable deployment units that can be customized and combined during provisioning by mean of managed configurations.
If one focus on the big picture that is Enterprise Architecture, everything seems like an attempt of cross-sharing information of its layers (Strategy, Business, Application, Technology, Implementation and Migration) in the form of reusable structures of lower complexity that can be combined in different contexts by engineers.
If we keep in mind that engineering is not focused into discovering new knowledge (that is science), just to apply the knowledge for build solutions... then we agree that everything is trending to give more X to the performance of regular engineers.
So please everybody stay quiet, just stay tuned and do not pretend to be a genius or 10x engineers... If we keep us up-to-date with the trends we will soon become all 100x ones.