Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Good Developers Are Promoted into Unhappiness (2007)

robwalling.com

Post reply on HN
Print view View original

41–50 of 235 posts

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

#41

Post by thaumasiotes »

burlesona wrote: post #25

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…

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

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

#42

Post by danmaz74 »

burlesona wrote: post #25

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…

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.

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

#43

Post by eight_ender »

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 liked to write a lot of code.

Once I was promoted to management I quickly realized just how much "not coding" that job requires. I struggled with not coding as much. I struggled with wanting to micro manage my staff. I struggled with wanting to write their code for them. I had juniors on my team and I wanted to snatch the keyboard from them and write their code for them.

The defining moment for me was one day, while watching one of my developers deploy something magnificent, that I realized I don't necessarily like to "build things", I like to "see things built". I like to see people succeed. I like to see a scribble on a napkin become a tangible piece of software. Code was a means to an end for me.

I won't lie and say I don't miss coding full time. I still get right in there when I can, but I step aside when I know my management duties are going to let the team down. One thing I don't feel is guilty about not coding as much anymore.

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

#44

Post by marmaduke »

blub wrote: post #38
wjossey wrote: 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.

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

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

#45

Post by doppel »

wjossey wrote: 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) developing, planning, mentoring and potentially leading small teams, while staying out of a full-on managerial role.

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

#46

Post by marmaduke »

gitgud wrote: post #37
democracy wrote: post #13

You stay in the company long enough and you write less code and spend more time managing people and processes as now you own your projects as the most knowledgable person for these projects. You start hating it (I did) and look for a pure programming role. But you are not in your twenties any more and you have to align with and follow someone else's designs and decisions and you can't since you are experienced and kn…

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

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

#47

Post by burlesona »

thaumasiotes wrote: post #41
burlesona wrote: post #25

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…

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

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

#48

Post by ithkuil »

revvx wrote: post #34
burlesona wrote: post #25

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…

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.

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

#49

Post by jasonkester »

wjossey wrote: 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…

A better fourth path is to transition to running your own business. You still get to write the code, and you remove the salary cap.

People sweat about all the “Business Stuff” you have to do in addition, but I find it’s not really any more of your day than the normal boring admin stuff of being a rank and file developer. Certainly less than being a manager at a bigco.

It also does away with ageism concerns.

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

#50

Post by burlesona »

danmaz74 wrote: post #42
burlesona wrote: post #25

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…

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

Post reply on HN