3 ms·

Trivial to be top 5 percent of the general population at programming Possible to be top 5 percent of the programmers Very difficult to be in the top 5 percent

by rr808 5y ago

Trivial to be top 5 percent of the general population at programming Possible to be top 5 percent of the programmers Very difficult to be in the top 5 percent of FANG programmers Nearly impossible to be in the top 5 percent of Google Principal engineers

thisisonthetest 5y ago
I would counter with the idea that seniority and programming ability are inversely proportional via The Gervais Principal (mentioned on hn again just recently)
- solveit 5y ago
  Principal Engineers at Google know their stuff, a viral blogpost notwithstanding.
  - eru 5y ago
    That blogpost doesn't even contradict this. In the terms of that article, Principal Engineers would perhaps be classified as 'losers'. > The Gervais principle differs from the Peter Principle, which it superficially resembles. The Peter Principle states that all people are promoted to the level of their incompetence. It is based on the assumption that future promotions are based on past performance. The Peter Principle is wrong for the simple reason that executives aren’t that stupid, and because there isn’t that much room in an upward-narrowing pyramid. They know what it takes for a promotion candidate to perform at the to level. So if they are promoting people beyond their competence anyway, under conditions of opportunity scarcity, there must be a good reason. > Scott Adams, seeing a different flaw in the Peter Principle, proposed the Dilbert Principle: that companies tend to systematically promote their least-competent employees to middle management to limit the damage they can do. This again is untrue. The Gervais principle predicts the exact opposite: that the most competent ones will be promoted to middle management. Michael Scott was a star salesman before he become a Clueless middle manager. The least competent employees (but not all of them — only certain enlightened incompetents) will be promoted not to middle management, but fast-tracked through to senior management. To the Sociopath level. From https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/ https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-... To be clear: I mean to imply no opinion on whether 'The Gervais Principle' is true nor applicable. I'm just saying that 'The Gervais Principle' is perfectly compatible with Principal Engineers at Google knowing their stuff.
  - xigoi 5y ago
    Well, they clearly don't know how to make a web app for accessing cloud storage work decently fast…
    - barrkel 5y ago
      Doing that at a startup would be easy, since you control the whole stack and can tune it to the use case, and almost certainly don't have problems of scale. It's 90% getting the technical stuff in place, assuming you have the budget. Doing it at a place like Google is a different matter. The job isn't tuning a stack. It's coordinating multiple teams that own different services, and trying to make general-purpose services and frameworks work especially well for a specific case, even in the face of competing demands and standardization forces. It would be 90% political, and the task-specific differentiation required may simply be insurmountable - the extra wrinkles for your use case might cost more in complexity and reliability than it's worth.
      - disgruntledphd2 5y ago
        To be fair though, that's wholly within the scope of what one would expect a Principle Engineer to do.
    - Jensson 5y ago
      What makes you think a Principal engineer is tasked with that? Principal engineers do mostly stuff like create new infrastructure technology like spanner, or machine learning frameworks, or similar stuff. Google doesn't have that many principal engineers, they correspond to director on the manager ladder, but there are way fewer principal engineers than directors as it is much harder to climb the contributor ladder than the manager ladder. Most Google products doesn't have a single principal engineer on the team.
      - UncleMeat 5y ago
        Drive almost certainly has an L8 on the team somewhere. It is a big product. And it could be the case that "find a completely new indexing structure that makes drive search and folder navigation 10x faster" is a L8 task. Drive is indeed a lot slower than I'd personally like and a lot of that comes down to the way that indexing works when you cannot group users together, which is at the very core of the product.
- ssteeper 5y ago
  The Gervais Principle is literally a joke
  - twoxproblematic 5y ago
  - LAC-Tech 5y ago
    Was it meant as a joke?
karmakaze 5y ago
One way that I've always found ways to skew this is to not restrict yourself strictly to 'programming' however you define it. Always treat the problem as a one-off where everything is 'in bounds' for the solution space. This approach lets me solve problems where the top 5% have not found a solution because they were looking at certain pure problems and not the practical ones at hand.
- karmakaze 5y ago
  Two other superpowers: (1) don't try to impress yourself or anyone else with the sophistication of your solutions, in fact do the opposite finding simple mechanisms that fit the problem. When you do this well, the solution looks simple, and makes the original problem seem much less hard. People don't do this because there's little credit to be had in a simple solution to a non-hard problem. Just keep in your own mind that it was a hard problem and finding that simple solution wasn't easy. With repeated practice, this means you can solve more difficult problems than others because you operate at a lower ratio of solution-complexity:problem-complexity. This is how you deal with intrinsic complexity rather than incidental. (2) Do not think procedurally (like a machine) in time steps. Think in invariants, decompose into independent logical partitions, ensure that logic is composable. When we say make code easy to 'reason about' we want to be able to, at each level, understand only what the subparts are doing, not how, and that those parts do not interfere with each other. If you repeat this at every level, you need to keep far less in your 'working memory' compared to problems that have deep implementations to keep in mind to understand and use properly. Related to this, relate the implementation structure to a conceptual model, and don't be compelled to make the conceptual model into concrete form, that tends to only add incidental complexity. People tend to do this because the conceptual model is cool and beautiful and would like to be able to show it, see it. Whenever you see a deep implementation stack that seems excessive and unnecessary there was probably a simpler implementation where each concept didn't have to be an explicit piece of architecture. Again this is very much less code, and less impressive to the unenlightened, but don't concern yourself with that, lose the ego (or rather feed it yourself instead of externally), only focus on solving hard problems with simple, underappreciated solutions.
whoomp12342 5y ago
yeah but how do you event quantify such a thing?

by rr808 5y ago

thisisonthetest 5y ago

I would counter with the idea that seniority and programming ability are inversely proportional via The Gervais Principal (mentioned on hn again just recently)

solveit 5y ago
Principal Engineers at Google know their stuff, a viral blogpost notwithstanding.
- eru 5y ago
  That blogpost doesn't even contradict this. In the terms of that article, Principal Engineers would perhaps be classified as 'losers'. > The Gervais principle differs from the Peter Principle, which it superficially resembles. The Peter Principle states that all people are promoted to the level of their incompetence. It is based on the assumption that future promotions are based on past performance. The Peter Principle is wrong for the simple reason that executives aren’t that stupid, and because there isn’t that much room in an upward-narrowing pyramid. They know what it takes for a promotion candidate to perform at the to level. So if they are promoting people beyond their competence anyway, under conditions of opportunity scarcity, there must be a good reason. > Scott Adams, seeing a different flaw in the Peter Principle, proposed the Dilbert Principle: that companies tend to systematically promote their least-competent employees to middle management to limit the damage they can do. This again is untrue. The Gervais principle predicts the exact opposite: that the most competent ones will be promoted to middle management. Michael Scott was a star salesman before he become a Clueless middle manager. The least competent employees (but not all of them — only certain enlightened incompetents) will be promoted not to middle management, but fast-tracked through to senior management. To the Sociopath level. From https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/ https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-... To be clear: I mean to imply no opinion on whether 'The Gervais Principle' is true nor applicable. I'm just saying that 'The Gervais Principle' is perfectly compatible with Principal Engineers at Google knowing their stuff.
- xigoi 5y ago
  Well, they clearly don't know how to make a web app for accessing cloud storage work decently fast…
  - barrkel 5y ago
    Doing that at a startup would be easy, since you control the whole stack and can tune it to the use case, and almost certainly don't have problems of scale. It's 90% getting the technical stuff in place, assuming you have the budget. Doing it at a place like Google is a different matter. The job isn't tuning a stack. It's coordinating multiple teams that own different services, and trying to make general-purpose services and frameworks work especially well for a specific case, even in the face of competing demands and standardization forces. It would be 90% political, and the task-specific differentiation required may simply be insurmountable - the extra wrinkles for your use case might cost more in complexity and reliability than it's worth.
    - disgruntledphd2 5y ago
      To be fair though, that's wholly within the scope of what one would expect a Principle Engineer to do.
  - Jensson 5y ago
    What makes you think a Principal engineer is tasked with that? Principal engineers do mostly stuff like create new infrastructure technology like spanner, or machine learning frameworks, or similar stuff. Google doesn't have that many principal engineers, they correspond to director on the manager ladder, but there are way fewer principal engineers than directors as it is much harder to climb the contributor ladder than the manager ladder. Most Google products doesn't have a single principal engineer on the team.
    - UncleMeat 5y ago
      Drive almost certainly has an L8 on the team somewhere. It is a big product. And it could be the case that "find a completely new indexing structure that makes drive search and folder navigation 10x faster" is a L8 task. Drive is indeed a lot slower than I'd personally like and a lot of that comes down to the way that indexing works when you cannot group users together, which is at the very core of the product.
ssteeper 5y ago
The Gervais Principle is literally a joke
- twoxproblematic 5y ago
- LAC-Tech 5y ago
  Was it meant as a joke?

karmakaze 5y ago

One way that I've always found ways to skew this is to not restrict yourself strictly to 'programming' however you define it. Always treat the problem as a one-off where everything is 'in bounds' for the solution space. This approach lets me solve problems where the top 5% have not found a solution because they were looking at certain pure problems and not the practical ones at hand.

karmakaze 5y ago
Two other superpowers: (1) don't try to impress yourself or anyone else with the sophistication of your solutions, in fact do the opposite finding simple mechanisms that fit the problem. When you do this well, the solution looks simple, and makes the original problem seem much less hard. People don't do this because there's little credit to be had in a simple solution to a non-hard problem. Just keep in your own mind that it was a hard problem and finding that simple solution wasn't easy. With repeated practice, this means you can solve more difficult problems than others because you operate at a lower ratio of solution-complexity:problem-complexity. This is how you deal with intrinsic complexity rather than incidental. (2) Do not think procedurally (like a machine) in time steps. Think in invariants, decompose into independent logical partitions, ensure that logic is composable. When we say make code easy to 'reason about' we want to be able to, at each level, understand only what the subparts are doing, not how, and that those parts do not interfere with each other. If you repeat this at every level, you need to keep far less in your 'working memory' compared to problems that have deep implementations to keep in mind to understand and use properly. Related to this, relate the implementation structure to a conceptual model, and don't be compelled to make the conceptual model into concrete form, that tends to only add incidental complexity. People tend to do this because the conceptual model is cool and beautiful and would like to be able to show it, see it. Whenever you see a deep implementation stack that seems excessive and unnecessary there was probably a simpler implementation where each concept didn't have to be an explicit piece of architecture. Again this is very much less code, and less impressive to the unenlightened, but don't concern yourself with that, lose the ego (or rather feed it yourself instead of externally), only focus on solving hard problems with simple, underappreciated solutions.

whoomp12342 5y ago

yeah but how do you event quantify such a thing?