3 ms·

I think it has a lot to do with wanting to have your cake and eat it too. Supposing you literally “just write code,” there’s a ceiling to how much impact you c

I think it has a lot to do with wanting to have your cake and eat it too. Supposing you literally “just write code,” there’s a ceiling to how much impact you can have. One person can only hold so large of a program (or so many small programs) in their head, and if you are on a project that reaches a certain size you have to start working with other humans to maintain it, and thus the need for technical leadership and/or people management begins. One of the basic ideas of good management is that a good manager is a multiplier. Suppose you have a team of ten, and individually they can each ship 8 “points” of work in a week. If you turn one of those people into a great manager you lose 8 points of direct work, but everyone else now ships 12 points per week, and you’ve gone from 80 to 108 points in a week. You could now say the manager is responsible for the 28 point gain. Similarly with a technical leadership role, doing the architecture and teaching work can multiply the effectiveness of many other people, leading to greater impact than any one individual could have. When you look at it like this, it’s obvious why these higher impact “multiplier” roles get more prestige and pay than the best individual coders. And I think that’s the dilemma. The real question - for many of us, anyway - is do you gain more satisfaction from the higher impact role and the perks that come with it, or from the sheer joy of the hands-on work that got you into this field in the first place. Its really difficult. I saw some other posters talking about rotating the responsibilities around - ie. leading sometimes and working in the trenches sometimes, and I really understand the appeal of that. That said, I’m not sure if it’s practical beyond the first “rung of the leadership ladder” or so, because leadership is itself a very challenging craft that takes a lot of focus and effort to master. What appeals to me more, but I haven’t seen yet in practice, is for orgs to let their technical leadership (both on the architect and people management sides) take periodic “coding sabbaticals,” or something along those lines. The main idea being that periodic returns to the hands-on work will help keep you sharp, up-to-date, and effective as a technical leader. The biggest problem with that is that it’s not always easy to just plug a “substitute leader” into the org chart while you’re on sabbatical.

deleted 8y ago
[deleted]
revvx 8y ago
> Supposing you literally “just write code,” there’s a ceiling to how much impact you can have I'm don't see why a single person can't have a ton of impact merely as a coder. I mean, this whole website is dedicated to (mostly) discussing tech startups and how (mostly) software disrupts and help scale outdated business models. Isn't the software-making business model also ripe for that disruption, at least in a smaller scale? Couldn't a single coder (or a small team) help an organization get some competitive advantage when it comes to tools. Or even programming languages? Why does ALL the innovation has to come from outside in our industry? Fred Brooks talks about "The Toolsmith" it the "Surgical Team" chapter in Mythical Man-Month, and how "the tool-builder will often construct specialized utilities, catalogued procedures, macro libraries". Facebook made React, Apple made Swift, Google has dozens of those. And the teams doing those tools aren't that huge. Why don't we try new things instead of letting good coders go away or making them stop coding?
- ithkuil 8y ago
  Yes and, if you're into it, you can model the effectiveness of those teams/projects in terms of productivity multipliers for other teams that use them.
- fastball 8y ago
  > One person can only hold so large of a program (or so many small programs) in their head Many programs can be small. But many of them cannot. For the larger programs, management is generally needed.
- cml11 8y ago
  I agree, but this website was dedicated to startups once upon a time. Now the dogma is that a single coder can do nothing and you need a "force multiplier". The multiplicand, which can be low or negative, does not matter to the vocal subset of talkers (often with vested interests) that has overrun HN.
- badfrog 8y ago
  > Couldn't a single coder (or a small team) help an organization get some competitive advantage when it comes to tools. Or even programming languages? Sort of, but: 1) Knowing what to build requires deep knowledge of that the other engineers in your company are struggling with. Figuring this out requires a lot of time spent meeting with people and doing other things that would be considered more management than coding. 2) If the thing you build is good, it's going to start getting a ton of feature requests. Your company will decide that it's worth investing in, and suddenly you're either managing a team or somebody else is managing you and running "your" project.
thaumasiotes 8y ago
> You could now say the manager is responsible for 28 of those points. You could, but that would be a weird thing to say. 36 would make a lot more sense.
- burlesona 8y ago
  Haha, good point. I edited my comment to reflect what I was thinking, which is that the manager created a 28 point gain. :)
  - thaumasiotes 8y ago
    The manager still created a 36 point gain. The policy of hiring one less worker and one more manager created a 28 point gain, of which 36 come from the manager and -8 come from the missing worker. (Or, if you hire the manager and then fire the worker, 40 come from the manager and -12 come from the missing worker. Which one makes more sense depends on the analysis you're trying to do. In either case the manager is currently producing 36 points.)
danmaz74 8y ago
If as an individual contributor you produce 8 points per week, as a manager you're not going to get other team members to produce 12 - unless they are much better developers than you were in the first place. What you can do, instead, is allowing your devs to stay at the maximum of their productivity even as the team grows - which is a challenge. And, even more importantly, you should ensure that those "points" that they develop actually contribute to the team's goals.
- burlesona 8y ago
  I agree with what you’re saying. When trying to coin an example I was imagining a team of ten with little in the way of focus and leadership, which means a lot of interrupts, conflicts, and changes in direction (ie lost points), compared to the same team with an effective leader clearing the way for them operate as you describe. It’s admittedly a contrived example. The interesting thing is that at that team size you really only need to have each team member “gain 1 point” for the “manager switch” to be “worth it” since 9x9 > 10x8. The point being that as the number of humans, good leadership is increasingly valuable.
  - thaumasiotes 8y ago
    > The interesting thing is that at that team size you really only need to have each team member “gain 1 point” for the “manager switch” to be “worth it” since 9x9 > 10x8. "Wow, only 1" isn't a good way of looking at it, since the points aren't measuring anything and therefore don't have any meaning in the example. At this team size, you need to have each team member increase their productivity by about 11%, 1 / (10 - 1). If we're calling their output "8 points", then the increase you need is just one point. If their output stays exactly the same, but we call it "a million points" instead of "8 points", then it's more than one point. Is achieving the 100,000+ point gain in the second scenario more difficult than achieving the 1-point gain in the first scenario? No.
  - danmaz74 8y ago
    Ok, I got what you meant now :)
lifeisstillgood 8y ago
A good manager is not a multiplier but a subtractor. They subtract the inanities and insanities of flawed organisations - they allow use of more appropriate tech, or they encourage developers to take on projects that might otherwise be frowned upon. But they have limits - at each level up the hierarchy there are always decisions above your pay grade. And that is the fundamental problem - organisations have built in limiters to how much change they can accept internally - because too much internal change breaks the cash generator. So sometimes the most performant thing to do is not to chnage anything, or perhaps just to leave. As I progress, I realise that coding is at the bottom of an inverted pyramid of "affect" - decisions in your code has less business impact than business decisions. For example I was just moaning that audible/kindle sync positions so you can read a bit, listen a bit. But a business decision was taken to kill off that fairly neat bit of coding - the business decision was not in sync with the coding decisions. To my mind that means we should have smaller coder driven organisations- see programmer anarchy, not somehow work out how to hire more managers
laythea 8y ago
Agree with all you say. the people who have a "higher multiplier" indirectly enact value rather than directly "at the coal face". It takes a certain kind of person, to be able to extract self value from seeing others directly create it, rather than directly creating it. Not everyone prefers that and some find more satisfaction when directly responsible for the added value. It's the self consumption of a direct-value vs indirect-value effect that drives whether you will be good at one or the other. The problem is that the mainstream mantra sways people into chasing indirect-value type roles, when they ought not to be (for the good of the individual).

deleted 8y ago

[deleted]

revvx 8y ago

> Supposing you literally “just write code,” there’s a ceiling to how much impact you can have I'm don't see why a single person can't have a ton of impact merely as a coder. I mean, this whole website is dedicated to (mostly) discussing tech startups and how (mostly) software disrupts and help scale outdated business models. Isn't the software-making business model also ripe for that disruption, at least in a smaller scale? Couldn't a single coder (or a small team) help an organization get some competitive advantage when it comes to tools. Or even programming languages? Why does ALL the innovation has to come from outside in our industry? Fred Brooks talks about "The Toolsmith" it the "Surgical Team" chapter in Mythical Man-Month, and how "the tool-builder will often construct specialized utilities, catalogued procedures, macro libraries". Facebook made React, Apple made Swift, Google has dozens of those. And the teams doing those tools aren't that huge. Why don't we try new things instead of letting good coders go away or making them stop coding?

ithkuil 8y ago
Yes and, if you're into it, you can model the effectiveness of those teams/projects in terms of productivity multipliers for other teams that use them.
fastball 8y ago
> One person can only hold so large of a program (or so many small programs) in their head Many programs can be small. But many of them cannot. For the larger programs, management is generally needed.
cml11 8y ago
I agree, but this website was dedicated to startups once upon a time. Now the dogma is that a single coder can do nothing and you need a "force multiplier". The multiplicand, which can be low or negative, does not matter to the vocal subset of talkers (often with vested interests) that has overrun HN.
badfrog 8y ago
> Couldn't a single coder (or a small team) help an organization get some competitive advantage when it comes to tools. Or even programming languages? Sort of, but: 1) Knowing what to build requires deep knowledge of that the other engineers in your company are struggling with. Figuring this out requires a lot of time spent meeting with people and doing other things that would be considered more management than coding. 2) If the thing you build is good, it's going to start getting a ton of feature requests. Your company will decide that it's worth investing in, and suddenly you're either managing a team or somebody else is managing you and running "your" project.

thaumasiotes 8y ago

> You could now say the manager is responsible for 28 of those points. You could, but that would be a weird thing to say. 36 would make a lot more sense.

burlesona 8y ago
Haha, good point. I edited my comment to reflect what I was thinking, which is that the manager created a 28 point gain. :)
- thaumasiotes 8y ago
  The manager still created a 36 point gain. The policy of hiring one less worker and one more manager created a 28 point gain, of which 36 come from the manager and -8 come from the missing worker. (Or, if you hire the manager and then fire the worker, 40 come from the manager and -12 come from the missing worker. Which one makes more sense depends on the analysis you're trying to do. In either case the manager is currently producing 36 points.)

danmaz74 8y ago

If as an individual contributor you produce 8 points per week, as a manager you're not going to get other team members to produce 12 - unless they are much better developers than you were in the first place. What you can do, instead, is allowing your devs to stay at the maximum of their productivity even as the team grows - which is a challenge. And, even more importantly, you should ensure that those "points" that they develop actually contribute to the team's goals.

burlesona 8y ago
I agree with what you’re saying. When trying to coin an example I was imagining a team of ten with little in the way of focus and leadership, which means a lot of interrupts, conflicts, and changes in direction (ie lost points), compared to the same team with an effective leader clearing the way for them operate as you describe. It’s admittedly a contrived example. The interesting thing is that at that team size you really only need to have each team member “gain 1 point” for the “manager switch” to be “worth it” since 9x9 > 10x8. The point being that as the number of humans, good leadership is increasingly valuable.
- thaumasiotes 8y ago
  > The interesting thing is that at that team size you really only need to have each team member “gain 1 point” for the “manager switch” to be “worth it” since 9x9 > 10x8. "Wow, only 1" isn't a good way of looking at it, since the points aren't measuring anything and therefore don't have any meaning in the example. At this team size, you need to have each team member increase their productivity by about 11%, 1 / (10 - 1). If we're calling their output "8 points", then the increase you need is just one point. If their output stays exactly the same, but we call it "a million points" instead of "8 points", then it's more than one point. Is achieving the 100,000+ point gain in the second scenario more difficult than achieving the 1-point gain in the first scenario? No.
- danmaz74 8y ago
  Ok, I got what you meant now :)

lifeisstillgood 8y ago

A good manager is not a multiplier but a subtractor. They subtract the inanities and insanities of flawed organisations - they allow use of more appropriate tech, or they encourage developers to take on projects that might otherwise be frowned upon. But they have limits - at each level up the hierarchy there are always decisions above your pay grade. And that is the fundamental problem - organisations have built in limiters to how much change they can accept internally - because too much internal change breaks the cash generator. So sometimes the most performant thing to do is not to chnage anything, or perhaps just to leave. As I progress, I realise that coding is at the bottom of an inverted pyramid of "affect" - decisions in your code has less business impact than business decisions. For example I was just moaning that audible/kindle sync positions so you can read a bit, listen a bit. But a business decision was taken to kill off that fairly neat bit of coding - the business decision was not in sync with the coding decisions. To my mind that means we should have smaller coder driven organisations- see programmer anarchy, not somehow work out how to hire more managers

laythea 8y ago

Agree with all you say. the people who have a "higher multiplier" indirectly enact value rather than directly "at the coal face". It takes a certain kind of person, to be able to extract self value from seeing others directly create it, rather than directly creating it. Not everyone prefers that and some find more satisfaction when directly responsible for the added value. It's the self consumption of a direct-value vs indirect-value effect that drives whether you will be good at one or the other. The problem is that the mainstream mantra sways people into chasing indirect-value type roles, when they ought not to be (for the good of the individual).