Live data from Hacker News

Why Good Developers Are Promoted into Unhappiness (2007)

robwalling.com

51–60 of 235 posts

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

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

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

#52
post #45
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 read this article a few months ago about being a Principal Engineer, https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-e... , and ever since it’s been my designated career path / plan. I am in the lucky position of working in a small-but-growing team of developers, so I get to choose my career advancement and have support to follow this road. I think a principal engineer is the right mix of (still) develop…

I thought this was my dream as well, until I found out it basically brings you all the responsibilities of management, without any of the rewards.

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

#53
post #10

Earlier quoted context omitted.

It's _vastly_ harder to get ahead on the "engineering" track. At Google, for instance, it's to the point where as a manager you barely need to have a pulse to get promoted (as long as your reports are any good), whereas on the technical ladder promotions to Staff level and above are stupid hard and downright nondeterministic. That's why many engineers there, who have little to no leadership skills or inclinations, en…

Google aside there is nothing worse than getting stuck at middle management in a software corp after 40 - 50. You are expensive, replacable and disposable.

Oddly enough I've never seen managers complain about ageism or the difficulty of finding jobs later in life, but it seems to be rather common around here.

So maybe there is something worse: bring stuck as a developer after 40-50.

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

#54
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-L6, maybe L7 - the TL/architect ladder should go from L5-L11 (note overlap with IC) - the Management ladder should go from from L5-SVP/CEO (I don't know the numbers for SVP, but I'm guessing ~13 or so...).

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

#55
post #38
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…

Isn't this more or less what Google does with all their profitless projects? Giving senior engineers something to play with so that they don't leave for the competition or create new competition. I guess it's nice for the devs at first, but creates a lot of waste. They're basically spamming the world with programming languages, libraries and products only to wind them down and start again.

I guess it will be waste either way, only if it’s going to be gold, google owns it

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

#56
post #37

Earlier quoted context omitted.

George Hotz once mentioned in an [1] interview; Managing people just another abstraction in making software. You can think of people kind of like an IDE that you can use to create things... I thought it was an interesting way to view management. [1] https://softwareengineeringdaily.com/wp-content/uploads/2018...

Yeah my boss certainly sees me and my colleague as a technical problem solving API: he says “now that I have told you what the problem, it is no longer my problem, and I don’t want an update unless it’s the solution.” I think this is sort of ok at a high competence level, but fails when the people you work with are less experienced. One could say the same of an IDE I suppose..

At a low competence level, this leads to non-solutions that still have to be used because of deadlines.

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

#57
This is what happens when management is valuated more glorious than any other activity. Systems and hierarchies therefore tend to reward good performances with what they considers as good recompense: management position.

This mindset bias is everywhere, first i noticed it in my european university, where the good teachers were promoted to high responsabilities position, meaning more and more administrative workload and far lesser time for teaching. Leading to the vicious situation where the teacher was not teaching anymore and not happy with his position, and studend loosing a good teacher and having to face less capable teachers. Using management position as a reward should be only used for wanabee managers.

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

#58
post #26

Earlier quoted context omitted.

> you have to push back and argue no, you don't.

Exactly. Mistakes need to be made over and over again. Do not try to stop this force.

Then what is the point? Are you just there to gather your paycheck?

I mean, to an extend, yes. But you need to be able to excert some positive effect.

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

#59
post #38

Earlier quoted context omitted.

Isn't this more or less what Google does with all their profitless projects? Giving senior engineers something to play with so that they don't leave for the competition or create new competition. I guess it's nice for the devs at first, but creates a lot of waste. They're basically spamming the world with programming languages, libraries and products only to wind them down and start again.

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

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

#60

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…

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

Post reply on HN