4 ms·

This is spot-on, and it's also true in organizations without stack ranking. It's actually not a cynical way to view your job. If what you do doesn't make an im

This is spot-on, and it's also true in organizations without stack ranking. It's actually not a cynical way to view your job. If what you do doesn't make an impact for customers and/or other teams in the organization, was it really worth doing? I've consistently seen that successful engineers focus on work that has an impact, and they are good at making it known. The first part is obviously good, but a lot of engineers disdain self-promotion. However, self-promotion is not a bad thing if you really are good at your job, because it opens up opportunities to have an even greater impact, which is good for you and for the company.

rizwan 8y ago
> If what you do doesn't make an impact for customers and/or other teams in the organization, was it really worth doing? The problem is that, at review time at Google, you have to be able to "quantify" the impact. Many types of impact are quantifiable (e.g. "Made server request scale from 100 query-per-second to 1,300 qps", "reduced code size by 30%", etc.). It's much harder to measure, say, the impact of a refactor where you made the code easier to reason about and more maintainable, so that future work can be done on it more easily. I witnessed the same thing at Google; I worked on a project that everyone joked only existed because the person who wrote it wanted promo, and the best way to get it was to design a very complex system, and convince others to adopt it. (He did get it, and promptly switched teams.) Some things have been made better, though. I've heard that going from L4 → L5 now involves much more influence from your manager, since they would know and, without quantifying something like a refactor, can speak to the positive impact you had in a project.
- gbustomtv5 8y ago
  You quantified what you said is hard to quantify. Measure commits/authors before and after a refactor.
  - rhymenoceros 8y ago
    The problem is that metric, like any metric, is both easy to game _and_ can provide misleading information. Measuring number of commits? Create fewer, larger commits. Measuring commit size? Pull in more third-party libraries, even where it does't make sense. Author count? Add more/less documentation and recruit or inhibit new devs depending on what your goal is. Not to mention the number of commits/authors before and after an arbitrary point in time might conflate a successful growing project with a project in a death spiral being passed around from group to group. It's a good idea, but in practice simple metrics like this often (but not always) devolve into prime examples of Goodhart's law.
    - twblalock 8y ago
      Ok, then find another way to measure developer productivity, or reliability in production, or customer features delivered. If you can’t find a measurable benefit to a refactoring (or anything else, really) then maybe it was not worth doing in the first place.
      - jmmcd 8y ago
        > find another way to measure developer productivity And solve the halting problem while you're at it
      - sdenton4 8y ago
        I was just yesterday discussing the opportunity cost of infrastructure changes, as a new team member was bemoaning our out of date patterns... A high impact infra change will often inconvenience dozens of people and distract from feature work... You know, the shit people actually care about... (this is analogous to how "Twitter, but written in Golang" appeals to approximately no one.)
      - derefr 8y ago
        In science, measuring things until you find a benefit is called p-hacking. Every extra test you do that splits your data along a different dimension, is another independent opportunity for "random chance" to look like positive signal. There is no programming project in existence with enough developers working on it, that developer-productivity data derived from a change to it would not be considered "underpowered" for the sake of proving anything.
- slededit 8y ago
  > It's much harder to measure, say, the impact of a refactor where you made the code easier to reason about and more maintainable, so that future work can be done on it more easily. I've also seen refactors that just made life difficult for everyone else with constant non-functional changes. In the end there is a lot of fashion in programming, and while some refactors are worthwhile most are not in my experience. The refactor is supposed to provide payoff in the future, but what normally happens is fashion changes and someone new comes by and says "this code is shit" and starts the process over. The supposed benefits never accrue.
technofiend 8y ago
>...but a lot of engineers disdain self-promotion. Assuming you're doing good work your boss should be your strongest advocate and trying to help get you recognized and promoted. But if you're not inclined to self-promote then it definitely hurts and lots of folks on HN say they suffer from some level of impostor syndrome. If someone thinks "Should I really be here, am I really good enough?" they may also overly discount the value of their work and think there is nothing worthy of promotion in both senses of the word.
walshemj 8y ago
Actually it is deeply cynical I have seen: People aggressively going for promotion and as my team leader said "but he hasn't done any real work for 6 months". I saw some one going for the first management level spend a million pounds of share holder money and 15 man years redeveloping a system in oracle - Because having a project worth > 1 million and with more than 10 staff was a tick box for promotion.
- technofiend 8y ago
  What is deeply cynical is the guy who discovered the corollary to "Never do work unless you can prove its value" which is "If you can disprove the value of someone else's work so much the better." He literally took notes on every employee of his peers and then trotted them out for negative feedback during the end-of-year ranking process. The resulting brinksmanship guaranteed his employees were ranked exactly the way he wanted. Ironic but he's now the head of a recruiting agency that purports to find top candidates via "big data" techniques yet he did his very best to subvert the system. So what exactly does he think he's datamining?
derefr 8y ago
> If what you do doesn't make an impact for customers and/or other teams in the organization, was it really worth doing? If what you are doing isn't making an impact, why is it being assigned to you in the first place? Or, to put that another way: a worker is hired to do things. Their comparative advantage is in doing; time they spend in any other role than doing is labor that would have been better allocated/delegated to someone else, to clear them up for more doing. (It's very clear when you think of high-status "workers"—for example, surgeons. Time the surgeon spends inside the OR is worth tens of thousands of dollars; time they spend outside the OR isn't worth anything. If you can hire an administrative assistant for $30/hr to take admin-work off the shoulders of the surgeon, to ensure that the surgeon spends even one more hour inside the OR per week, then the admin assistant has paid for themselves.) A manager, meanwhile, is hired to prioritize, delegate, lubricate channels of communication, ensure their team of workers has the resources it needs to "do", and then defend the workers from anything that would take away from their "doing" time. These tasks are the manager's wheelhouse; it's where their own comparative advantage lies. Time a worker spends managing themselves is company money wasted, because a manager would have been able to get that work done far more effectively, for less effort and time input. You don't want a doctor spending time reading charts to triage patients (i.e. assigning work to themselves.) The intake nurse does that. And you don't want the intake nurse spending time trying to diagnose someone after taking their symptoms. That's what the doctors are for. Each role has their comparative advantage. Let the roles bleed together, and overhead goes up while lives saved goes down. Why do "old" organizations like hospitals understand comparative advantage better than FAANG? Why isn't it seen as a failure of management to prioritize effectively when everybody isn't always doing the most important thing they could be doing at that moment?
- lifeisstillgood 8y ago
  Why do "old" organizations like hospitals understand comparative advantage better than FAANG? Why isn't it seen as a failure of management to prioritize effectively when everybody isn't always doing the most important thing they could be doing at that moment? reply That's so good i want to steal it for a chapter in my book
- mulmen 8y ago

rizwan 8y ago

> If what you do doesn't make an impact for customers and/or other teams in the organization, was it really worth doing? The problem is that, at review time at Google, you have to be able to "quantify" the impact. Many types of impact are quantifiable (e.g. "Made server request scale from 100 query-per-second to 1,300 qps", "reduced code size by 30%", etc.). It's much harder to measure, say, the impact of a refactor where you made the code easier to reason about and more maintainable, so that future work can be done on it more easily. I witnessed the same thing at Google; I worked on a project that everyone joked only existed because the person who wrote it wanted promo, and the best way to get it was to design a very complex system, and convince others to adopt it. (He did get it, and promptly switched teams.) Some things have been made better, though. I've heard that going from L4 → L5 now involves much more influence from your manager, since they would know and, without quantifying something like a refactor, can speak to the positive impact you had in a project.

gbustomtv5 8y ago
You quantified what you said is hard to quantify. Measure commits/authors before and after a refactor.
- rhymenoceros 8y ago
  The problem is that metric, like any metric, is both easy to game _and_ can provide misleading information. Measuring number of commits? Create fewer, larger commits. Measuring commit size? Pull in more third-party libraries, even where it does't make sense. Author count? Add more/less documentation and recruit or inhibit new devs depending on what your goal is. Not to mention the number of commits/authors before and after an arbitrary point in time might conflate a successful growing project with a project in a death spiral being passed around from group to group. It's a good idea, but in practice simple metrics like this often (but not always) devolve into prime examples of Goodhart's law.
  - twblalock 8y ago
    Ok, then find another way to measure developer productivity, or reliability in production, or customer features delivered. If you can’t find a measurable benefit to a refactoring (or anything else, really) then maybe it was not worth doing in the first place.
    - jmmcd 8y ago
      > find another way to measure developer productivity And solve the halting problem while you're at it
    - sdenton4 8y ago
      I was just yesterday discussing the opportunity cost of infrastructure changes, as a new team member was bemoaning our out of date patterns... A high impact infra change will often inconvenience dozens of people and distract from feature work... You know, the shit people actually care about... (this is analogous to how "Twitter, but written in Golang" appeals to approximately no one.)
    - derefr 8y ago
      In science, measuring things until you find a benefit is called p-hacking. Every extra test you do that splits your data along a different dimension, is another independent opportunity for "random chance" to look like positive signal. There is no programming project in existence with enough developers working on it, that developer-productivity data derived from a change to it would not be considered "underpowered" for the sake of proving anything.
slededit 8y ago
> It's much harder to measure, say, the impact of a refactor where you made the code easier to reason about and more maintainable, so that future work can be done on it more easily. I've also seen refactors that just made life difficult for everyone else with constant non-functional changes. In the end there is a lot of fashion in programming, and while some refactors are worthwhile most are not in my experience. The refactor is supposed to provide payoff in the future, but what normally happens is fashion changes and someone new comes by and says "this code is shit" and starts the process over. The supposed benefits never accrue.

technofiend 8y ago

>...but a lot of engineers disdain self-promotion. Assuming you're doing good work your boss should be your strongest advocate and trying to help get you recognized and promoted. But if you're not inclined to self-promote then it definitely hurts and lots of folks on HN say they suffer from some level of impostor syndrome. If someone thinks "Should I really be here, am I really good enough?" they may also overly discount the value of their work and think there is nothing worthy of promotion in both senses of the word.

walshemj 8y ago

Actually it is deeply cynical I have seen: People aggressively going for promotion and as my team leader said "but he hasn't done any real work for 6 months". I saw some one going for the first management level spend a million pounds of share holder money and 15 man years redeveloping a system in oracle - Because having a project worth > 1 million and with more than 10 staff was a tick box for promotion.

technofiend 8y ago
What is deeply cynical is the guy who discovered the corollary to "Never do work unless you can prove its value" which is "If you can disprove the value of someone else's work so much the better." He literally took notes on every employee of his peers and then trotted them out for negative feedback during the end-of-year ranking process. The resulting brinksmanship guaranteed his employees were ranked exactly the way he wanted. Ironic but he's now the head of a recruiting agency that purports to find top candidates via "big data" techniques yet he did his very best to subvert the system. So what exactly does he think he's datamining?

derefr 8y ago

> If what you do doesn't make an impact for customers and/or other teams in the organization, was it really worth doing? If what you are doing isn't making an impact, why is it being assigned to you in the first place? Or, to put that another way: a worker is hired to do things. Their comparative advantage is in doing; time they spend in any other role than doing is labor that would have been better allocated/delegated to someone else, to clear them up for more doing. (It's very clear when you think of high-status "workers"—for example, surgeons. Time the surgeon spends inside the OR is worth tens of thousands of dollars; time they spend outside the OR isn't worth anything. If you can hire an administrative assistant for $30/hr to take admin-work off the shoulders of the surgeon, to ensure that the surgeon spends even one more hour inside the OR per week, then the admin assistant has paid for themselves.) A manager, meanwhile, is hired to prioritize, delegate, lubricate channels of communication, ensure their team of workers has the resources it needs to "do", and then defend the workers from anything that would take away from their "doing" time. These tasks are the manager's wheelhouse; it's where their own comparative advantage lies. Time a worker spends managing themselves is company money wasted, because a manager would have been able to get that work done far more effectively, for less effort and time input. You don't want a doctor spending time reading charts to triage patients (i.e. assigning work to themselves.) The intake nurse does that. And you don't want the intake nurse spending time trying to diagnose someone after taking their symptoms. That's what the doctors are for. Each role has their comparative advantage. Let the roles bleed together, and overhead goes up while lives saved goes down. Why do "old" organizations like hospitals understand comparative advantage better than FAANG? Why isn't it seen as a failure of management to prioritize effectively when everybody isn't always doing the most important thing they could be doing at that moment?

lifeisstillgood 8y ago
Why do "old" organizations like hospitals understand comparative advantage better than FAANG? Why isn't it seen as a failure of management to prioritize effectively when everybody isn't always doing the most important thing they could be doing at that moment? reply That's so good i want to steal it for a chapter in my book
mulmen 8y ago