Live data from Hacker News

Why Good Developers Are Promoted into Unhappiness (2007)

robwalling.com

61–70 of 235 posts

Re: Why Good Developers Are Promoted into Unhappiness (2007)

#61

Earlier quoted context omitted.

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 t…

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…

> 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.

Re: Why Good Developers Are Promoted into Unhappiness (2007)

#62
post #6

Earlier quoted context omitted.

In my company it's certainly the case that in order to progress on the technical track you need to be extremely good and more importantly on the right projects. I see a lot of mediocre people advance on the management track but only very few advance above a certain level on the technical track. Considering that salary is directly tied to a person's rank I think it's a very rational decision to go into management even…

This really depends on the company. I know senior ICs who make a bit more money than the managers they report to.

As a manager, this is fine. It’s not my money :P

Re: Why Good Developers Are Promoted into Unhappiness (2007)

#63

I think it's pretty common to talk about "management career path" and "tech lead / architect career path", and I think it's a mistake. I think there should be three paths: manager, TL/architect, and individual contributor. I wish Google (I work there, opinions my own) had three ladder flavours for engineers, not two. If we did that, in Google terms (ref. http://levels.fyi ), I think: - the IC ladder should go from L3…

[deleted]

Re: Why Good Developers Are Promoted into Unhappiness (2007)

#64

I wrote code like a madman and then went into management. I like management, but I understand what the author of this article was getting at. I had an identity crisis early on doing management. I liked to tell people what to do, because I had a big map in my head of where things should go. Because of this developers sort of organically gravitated to me for guidance even before I had the official job. However, I also…

So how DO you deal with people under you writing code under you that just boils your blood? Especially if you instinctually see that their contributions are always more counterproductive than not, but everyone else (including their people manager) thinks they're alright?

Re: Why Good Developers Are Promoted into Unhappiness (2007)

#65

Earlier quoted context omitted.

> They're basically spamming the world with programming languages, libraries and products only to wind them down and start again Replace libraries, languages and products with statistics, hypotheses and figures and you have described scientific research. The point is that each iteration learns from the last, in principle, even if they aren’t backwards or forwards compatible.

Replace statistics, hypotheses and figures with bread, donuts and cake and you have described a bakery. Hmmm cake... How can you not like cake?

[deleted]

Re: Why Good Developers Are Promoted into Unhappiness (2007)

#66
post #34

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…

> 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 smalle…

> 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.

Re: Why Good Developers Are Promoted into Unhappiness (2007)

#67

Earlier quoted context omitted.

> 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.

Haha, good point. I edited my comment to reflect what I was thinking, which is that the manager created a 28 point gain. :)

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.)

Re: Why Good Developers Are Promoted into Unhappiness (2007)

#68
post #51
post #22

I’ve been reviewing a lot of career path documents recently for different engineering orgs, and every one is fairly uniform in that you either progress into management, team leadership, or architecture (or some blend of the three). If not, you’ll stagnate at a pretty high level, but stagnate none the less. I’ve been noodling on this for a while, and I think maybe a fourth track at a lot of organizations should be spe…

Since you seem to have some idea of what an Architect is, can you explain this to me? As far as I’m concerned they’re the people that run around flooding every meeting with words that have already been said by the developers, and by extension do not need to be said.

Yes the average ones are like that but the good ones I have seen provide a broader perspective, simplify solution, prevent the excited devs from trying out complicated solution with hyped but unsuitable technologies among other things. They save so much time and effort of an org that they are much more valuable than many managers.

Re: Why Good Developers Are Promoted into Unhappiness (2007)

#70
post #22

I’ve been reviewing a lot of career path documents recently for different engineering orgs, and every one is fairly uniform in that you either progress into management, team leadership, or architecture (or some blend of the three). If not, you’ll stagnate at a pretty high level, but stagnate none the less. I’ve been noodling on this for a while, and I think maybe a fourth track at a lot of organizations should be spe…

I was in a group a bit like that. It was small product-focused R&D team of ~6 people, charged with figuring out an emerging disruptive industry change, and building a new product line for that. (The rest of the company was directed not to even allude to our existence, since that might interfere with sales of the current products, and we even had a stealthy group name.) Except for me, who was the token enthusiastic kid, it was hand-picked from among the top engineers in the company.

This particular group had a manager. One of my favorite bosses, who was very sharp as both engineer and manager, honest, humble, and supportive (and formative of some of my ideas of what I should aspire to).

Post reply on HN