3 ms·

GP is crude, but it's not too far off reality. Managers are the first line of defense in ensuring there is slack within the team to pick up what is problematic.

GP is crude, but it's not too far off reality. Managers are the first line of defense in ensuring there is slack within the team to pick up what is problematic. By instilling a mindset of "sales/finance/features/bug fixes come first, slack is a luxury", they are directly telling you the health of the codebase long term is not your primary concern, it is getting stuff done on the short term. Instilling that mindset then seeps into everything else. Make things more open-ended so you can change things later? Too risky, too time-consuming. All frameworks, methods, etc. used become increasingly more closed off, and fixing them after the fact is an afterthought. 2 years later something that should take 2 hours now takes a week, but who cares. Hiring weaker individuals when your codebase has no obvious flows? Clear signs of executives, HR managers etc. pinching pennies. Don't set people up for failure, and use stronger individuals to create environments where weaker individuals are set up for success instead. This is leadership and teaching 101. No slack in the team? No time to work through codebase problems. Most of all, assumptions that there will be no slack cause the team to become so skeptical, they won't even mention long term issues. It creates the very mindset they claim to dislike: one where mercenaries shine, getting a quick buck and not caring about the feelings of those coming after them. The only thing I don't agree with, is not matching individuals. There just isn't enough interesting work for the entire software developer crowd to go into. CRUD-plumbing webdev rules the world, it is extremely unimaginative but it pays well. Ironically, having the entire industry take a breather and look at the problem from a higher level might be the thing to make it more interesting and less painful, but I doubt there will ever be enough jobs in the more complex, visual, animated and/or hacky fields anytime soon to accommodate all the developers now stuck trudging in the stereotypical CRUD webdev shop. I say this knowing someone from a different, non-management discipline will run into the same issues while working in a software team. UX, UI, graphics artists, testers, etc. all suffer similarly from management incompetence.

arinlen 4y ago
> Managers are the first line of defense in ensuring there is slack within the team to pick up what is problematic. They are, but the first line of defense is often broken due to problems that are controlled, if not outright created, by developers. I mean, isn't feedback from developers the main source of info available to a manager? What if that info becomes highly unreliable due to natural occurrences like emergent requirements? What happens to a schedule when midway through the project someone realizes there's something fundamentally broken with the architecture put together by the developers and suddenly you need a major rewrite to be able to meet your requirements? Don't confuse accountability with responsibility. Managers are held accountable, but developers can and often are responsible for misdirections and blockers and the need to rework. Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers, who are perfect and flawless, is not a honest starting point for a discussion on unhappiness of software developers.
- BlargMcLarg 4y ago
  >I mean, isn't feedback from developers the main source of info available to a manager? Then why is that feedback routinely thwarted or ignored in so many places? You make it seem like developers aren't giving feedback. Most places I worked at, at least 1-2 developers in a team of 7-8 were passionate enough initially to provide feedback. Then their feedback gets shot down repeatedly for no other reason than "low priority". What do you think happens to people who have to make a conscious effort to document such issues, articulate them and provide potential solutions? They figure "you know what, this isn't worth the effort, it won't get picked up". That's valuable time they could spend coping with their frustrations instead of hopelessly tackling them head-on. Managers are held responsible because when we speak of managers, we're not just talking about middle managers. We're talking about all managers, including the executives. If those executives prioritize short term sales over long term company health, don't be surprised when your ICs follow your example. If you're a leader, set the example you expect others to follow. >What if "What ifs" are primarily exceptions. How about we tackle the vast majority of cases where short term financial gains are prioritized over long term company health? That's where the feedback matters most for passionate ICs, and that's where feedback is waved away the most. >Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers You're the one claiming this. Don't take us all as not understanding the point of view of executives. Understanding doesn't mean agreement, nor does it mean the chickens won't come home to roost someday. If you consciously decide it is worth making your codebase a complete mess for short term gains, don't cry when in 5 years, all that's left is a bunch of jaded developers only in it for the money wondering why it takes them ten times as long to fix something trivial.
- dilyevsky 4y ago
  > Managers are held accountable In my 15 year career I’ve never seen line manager being let go for poor performance. I’ve seen a good number of underperforming devs getting canned and some higher-ups (usually for political reasons or just phoning in completely) but never line managers.
- pdimitar 4y ago
  > I mean, isn't feedback from developers the main source of info available to a manager? Of course it is, that's well-known. But for 20 years of career 99% of all managers I ever worked with outright ignore the feedback. Most people should not be in positions of power -- ever. It quickly turns into an ego trip where inconvenient facts are ignored and hand-waved away. And always letting somebody else deal with the fallout of your incompetence. Programmers are not stupid. With your feedback routinely ignored you learn to keep quiet -- why expend energy on something futile? Or you change jobs. Take a wild guess which of both happens 90% of the time.
ChrisMarshallNY 4y ago
I was a first-line manager (a "sergeant," if you want to use a military analogy) for 25 years. I deliberately stayed at that level, even though I could have easily bubbled up higher. I felt that I could make a big difference to my team, and, by running a good team, make a big difference to my company. There were a lot of problems in the corporation; bad decisions, HR issues, administratium poisoning[0], etc., but the consensus seems to have been that my little team was really quite effective, and I kept engineers for decades. Managers can make a big difference for the positive. [0] https://www.mit.edu/people/dmredish/wwwMLRF/links/Humor/Administratium.html https://www.mit.edu/people/dmredish/wwwMLRF/links/Humor/Admi...

arinlen 4y ago

> Managers are the first line of defense in ensuring there is slack within the team to pick up what is problematic. They are, but the first line of defense is often broken due to problems that are controlled, if not outright created, by developers. I mean, isn't feedback from developers the main source of info available to a manager? What if that info becomes highly unreliable due to natural occurrences like emergent requirements? What happens to a schedule when midway through the project someone realizes there's something fundamentally broken with the architecture put together by the developers and suddenly you need a major rewrite to be able to meet your requirements? Don't confuse accountability with responsibility. Managers are held accountable, but developers can and often are responsible for misdirections and blockers and the need to rework. Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers, who are perfect and flawless, is not a honest starting point for a discussion on unhappiness of software developers.

BlargMcLarg 4y ago
>I mean, isn't feedback from developers the main source of info available to a manager? Then why is that feedback routinely thwarted or ignored in so many places? You make it seem like developers aren't giving feedback. Most places I worked at, at least 1-2 developers in a team of 7-8 were passionate enough initially to provide feedback. Then their feedback gets shot down repeatedly for no other reason than "low priority". What do you think happens to people who have to make a conscious effort to document such issues, articulate them and provide potential solutions? They figure "you know what, this isn't worth the effort, it won't get picked up". That's valuable time they could spend coping with their frustrations instead of hopelessly tackling them head-on. Managers are held responsible because when we speak of managers, we're not just talking about middle managers. We're talking about all managers, including the executives. If those executives prioritize short term sales over long term company health, don't be surprised when your ICs follow your example. If you're a leader, set the example you expect others to follow. >What if "What ifs" are primarily exceptions. How about we tackle the vast majority of cases where short term financial gains are prioritized over long term company health? That's where the feedback matters most for passionate ICs, and that's where feedback is waved away the most. >Trying to pretend that the role of a manager is a Dickensian figure whose purpose in life is to rain misery on developers You're the one claiming this. Don't take us all as not understanding the point of view of executives. Understanding doesn't mean agreement, nor does it mean the chickens won't come home to roost someday. If you consciously decide it is worth making your codebase a complete mess for short term gains, don't cry when in 5 years, all that's left is a bunch of jaded developers only in it for the money wondering why it takes them ten times as long to fix something trivial.
dilyevsky 4y ago
> Managers are held accountable In my 15 year career I’ve never seen line manager being let go for poor performance. I’ve seen a good number of underperforming devs getting canned and some higher-ups (usually for political reasons or just phoning in completely) but never line managers.
pdimitar 4y ago
> I mean, isn't feedback from developers the main source of info available to a manager? Of course it is, that's well-known. But for 20 years of career 99% of all managers I ever worked with outright ignore the feedback. Most people should not be in positions of power -- ever. It quickly turns into an ego trip where inconvenient facts are ignored and hand-waved away. And always letting somebody else deal with the fallout of your incompetence. Programmers are not stupid. With your feedback routinely ignored you learn to keep quiet -- why expend energy on something futile? Or you change jobs. Take a wild guess which of both happens 90% of the time.

ChrisMarshallNY 4y ago

I was a first-line manager (a "sergeant," if you want to use a military analogy) for 25 years. I deliberately stayed at that level, even though I could have easily bubbled up higher. I felt that I could make a big difference to my team, and, by running a good team, make a big difference to my company. There were a lot of problems in the corporation; bad decisions, HR issues, administratium poisoning[0], etc., but the consensus seems to have been that my little team was really quite effective, and I kept engineers for decades. Managers can make a big difference for the positive. [0] https://www.mit.edu/people/dmredish/wwwMLRF/links/Humor/Administratium.html https://www.mit.edu/people/dmredish/wwwMLRF/links/Humor/Admi...