Live data from Hacker News

Why Good Developers Are Promoted into Unhappiness (2007)

robwalling.com

101–110 of 235 posts

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

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

Depends on the company.

Big orgs with lots of outsourcing, architects are supposed to police the result to make sure it's semi decent. But since they've long since gave up doing any real work, they tend to be people who buy really expensive crap to cover their arse.

In smaller orgs, it can almost be just a lead dev with a fancy title.

Rarely does the title seem appopriate, but some of the folks with the title are good regardless.

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

#102
post #80
post #9

In my previous company all the senior engineers took a few juniors under their umbrella and had very informal one-on-ones with them, just to bypass the troubles with non-technical managers. Hereby I as senior could give practical advices, eg how to deal with politics, without having to go into politics, excel and powerpoint and meeting-hell by myself. This way the good senior devs didn't had to be promoted to managem…

You kind of described a highly disfunctional company, where you as a senior sw engineer literally had the power and authority to choose who would get promoted and who wouldn't.

No, I never talked with my manager about anything I talked with my juniors. I only advised my juniors how to deal best with managers, but mostly we talked about code.

It was a highly functional company until they changed the dev manager, then it went downhill immediately. Political middle managers soon took over everything, and all the seniors left.

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

#103
Funnily enough, it's the same thing in academia/research. You get into it because you like doing research and you (think you) are good at it. And if you are really good (and have a healthy dose of luck), eventually you progress to being a professor, you are principal investigator of some projects, and you find out that your job now consists mainly of managing a group of people -even if you aren't especially good at management and haven't been trained for it- and writing grant applications, and you have almost no time for actual research.

The difference is that in academia is not an explicit promotion that moves you from research to management, but more of a boiling frog kind of situation where you gradually do less and less research and more and more management - or at least this has been my experience.

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

#104
post #80
post #9

In my previous company all the senior engineers took a few juniors under their umbrella and had very informal one-on-ones with them, just to bypass the troubles with non-technical managers. Hereby I as senior could give practical advices, eg how to deal with politics, without having to go into politics, excel and powerpoint and meeting-hell by myself. This way the good senior devs didn't had to be promoted to managem…

You kind of described a highly disfunctional company, where you as a senior sw engineer literally had the power and authority to choose who would get promoted and who wouldn't.

I think what he is saying is not particularly uncommon.

Several of the orgs I have worked at have expectation that a senior developer will help juniors, whether that's formalized as a line management and 1 to 1s or informal mentoring.

Tbh expecting to be a senior developer and not give any time towards leveling up the next generation of software practitioners is both selfish and short sighted.

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

#105
post #79

I'm surprised how these traditional organizational structures still exist so strongly today. It sometimes feels like the whole agile/lean revolution (with self-managed teams) never happened.

The agile revolution never happened because it’s just not how people buy things. Hell, I don’t even think it’s how we build them. I love the analogy of a burger joint and ordering a burger with fries, because from a buyers perspective, that’s exactly how we want to buy software. We point out some items on the menu, and we expect them to be delivered together, on time and to our specified demands. The person taking ou…

> I love the analogy of a burger joint and ordering a burger with fries

I would like to argue that the burger joint is actually very agile. The person taking the order isn't the project manager. He just has the role of placing the order on the kanban board. From hereon the rest of the people all take their self-managed roles to fulfill the order. You can point out such agile (lean) processes throughout the entire delivery chain.

> Agile was supposed to help on this, but it hasn’t.

My experience has been exactly the opposite. Those companies that managed to achieve a true agile process (or achieved an agile bubble inside a structured organization) were making the best progress. What I do see, however, is many companies misinterpreting agile. Especially Scrum. They see Scrum as a method for ticking off the to-do list provided by the product owner. I've seen project managers posing as scrum masters and project managers posing as product owners. It's still top-down management and the team is expected to follow orders. They don't seem to understand the principles of the sprint goal or how it's actually the development team that ought to own the sprint backlog. They never really did scrum.

> I mean, a true agile contract can’t specify requirements, cost and time at once

This is indeed a challenge. You can - at most - sell sprints. With agile you say: "You have the dev team for this amount of time". It's an uncertainty for the client. But in my experience this has always led to the most bang for the buck. I'm surprised you haven't experienced these results?

> Which unfortunately means that you need to promote a few developers into unhappiness

This perhaps is an argument in favor of agile. Those project managers indeed need to know how to make those damn burgers. Then why not just make them your lead dev (chef-cook)?

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

#106
The machine is a companion and safeguard against swallowing too much of my own BS, or the BS of others that I get involved with. I'm unhappy without that level of feedback being frequent. Even declaring for Crocker's Rules doesn't get you really honest feedback from humans.

It's really gross that the higher you go up the tech IC ladder the less you code. Your opinions also somehow matter more even though you're furthest removed from knowing if they're valid.

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

#107

Earlier quoted context omitted.

I don’t know how it works in the US but in the U.K. becoming a contractor can provide a good half way house between being employed and running your own company. You’re not an employee so no performance reviews or line management and you are responsible for running your own company, but at the same time many contracts will be working with teams of permanent staff for 6 months or more so it’s not like you are off total…

How do you, as a contractor, find this sort of work?

You can join a network of freelance experts, like Toptal.

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

#110
post #83
post #70

Earlier quoted context omitted.

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

> charged with figuring out an emerging disruptive industry change And did you? — I'm really curious as to whether there ended up being a positive ROI from dedicating those top engineers to that task.

Yes, we figured it out. The ROI question is complicated (and I'm a techie, not an MBA). At some point, old product line management appeared and took over everything about the new product line, bringing in much/most of the company's engineers and managers. I stayed on for this new phase. I later had a rapport with some people who'd had executive-level visibility, who confided a few bits of why some things happened, but I don't have enough information (nor MBA qualifications) to distill useful lessons from that here. I'll just say my sense is that the original team performed well for the organization, and then organization things changed outside the team.

My personal ROI: moving to that group might've been the best decision I ever made. I learned a tremendous amount, got to work with great people, and afterwards it catapulted my career in the direction I wanted to go. Had I not been determined to go to grad school, I would've followed the original team lead anywhere.

Post reply on HN