6 ms·

Your comment sadly repeats the same old software developer tropes, namely: * Managers create all the problems, * Problems not created by managers are created

Your comment sadly repeats the same old software developer tropes, namely: * Managers create all the problems, * Problems not created by managers are created by my team members, * Everyone around me is incompetent except myself, * The problems I create have everyone else to blame but myself, because I'm flawless and I was just put in a bad situation. * goto start. I've been in a fair share of time-constrained problems, but honestly deadlines tended to slip because of a mix of emergent technical requirements that dev teams didn't managed to see beforehand, and scoping tasks that severely undershoot the requirements. Scoping and planning is hard, specially with limited info, and you can't reasonably allocate 10x the resources to your project just to have a decent slack in the critical path. Also, bad code can and often is subjective,and I've seen competent and above-grade engineers underperform because of task- and life-specific issues. It's high time that developers cease the "everyone around me is incompetent and responsible for al problems" mindset.

watwut 4y ago
Meh, you gotta admit management of software projects tend to suck. Yes scoping and planning is hard, but management that don't even try either (and is not agile either) is fairly frequent. Also, we are for some reason blessed with management with not much soft skills. Stuff like new manager coming in and insulting people right and left on the first day with no reason just because they are insecure or arrogant is frequent too. There are good manager, I worked with some. But bad management is frequent and there is very little accountability for managers, so they get stuck for years and decades.
- dr-detroit 4y ago
BlargMcLarg 4y ago
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.
mihaigalos 4y ago
How exactly do you "manage" a creative process to respect a deadline? Do you tell a painter to get it done by Monday? That's why small iterations are there in the first place: to constantly add incremental value, not "big bang" plan-the-work and work-the-plan but reacting to change.
- bluedino 4y ago
  Are they painting a house or are they painting portraits?
- bumby 4y ago
  I guess that depends on whether they are operating as software engineers or software artists. Sure, an artist can have leeway for their creative efforts. But allowing artists to work on a muse-driven timeline is also why the stereotype of a "starving artist" exists. Engineers on the other hand have some product with at least a baseline of utilitarian value. Those generally need timelines because somebody is planning on a delivery of that utility. But I think both those are besides the point. You can have a structured process that also integrates creativity. I think treating them as mutually exclusive is a false dichotomy.
DougBTX 4y ago
> It's high time that developers cease the "everyone around me is incompetent and responsible for all problems" mindset I reckon there’s some selection bias here too, people who perceive themselves to be incompetent probably talk about it less.
- arinlen 4y ago
  > I reckon there’s some selection bias here too, people who perceive themselves to be incompetent probably talk about it less. The issue here is not what's the true skill level of anyone in the team. The problem is this recurrent theme of software developers demeaning everyone around them while portraying themselves as flawless saviours. A key trait of software development is JIT onboarding and continuous development. If you develop your skills and today you're a better developer than you were yesterday, that means that yesterday you were a worse developer and quite possibly quite bad by your measuring stick from some point in the future. Thus if JIT onboarding and continuous personal development is a basic aspect of software development jobs, why is not being ab absolute expert on everything the target of so much criticism and abuse? I often look to the work I've done in the past and often times I come across less optimal choices that today I wouldn't make. I'm sure the only ones who don't experience the same are thise who learn nothing from anything. Therefore, why use that as a target for abuse?
  - peteradio 4y ago
    > A key trait of software development is JIT onboarding and continuous development This is a horrible trait and a recipe for painting oneself into corners unless you are only working on trivial stuff that's been done before.
    - BlargMcLarg 4y ago
      Yet it's all too common today. Here's a fun exercise for anyone: imagine what would happen if 10% of the team would go away in the next month. Now imagine if it was 80%. For how risk-averse companies are, it's pretty crazy how bad their back-up plan is should the latter happen.
bbarn 4y ago
I think you hit the nail on the head here. I am a lot more understanding at this later stage in my career when someone shows me a big ball off spaghetti in a project. I don't know why decisions were made, what trade offs for time or requirements were made in the past, what designs might have made sense that got turned upside down with new features, etc. I tend to shut down sentiments like "This all needs rewriting" or "What on earth was this person thinking" as much as I can. Most of us are decent enough at our jobs, and generally the industry does a good job of weeding out those who can't perform or they end up lost and irrelevant in some big company. There are certainly some bad developers out there, but there's bad doctors, bad lawyers, etc. in the real world too. That said, the impact a bad manager can have is definitely of a greater magnitude than a bad engineer, generally speaking.
- agentultra 4y ago
  Hard agree. It annoys me that this has the air of a “hot take,” but I don’t believe anyone wakes up in the morning and thinks, “I’m going to write overly clever spaghetti code today and do as bad a job I can.” People are generally good and want to do a good job and be recognized by their peers. Different people have different strengths and skills. It’s the sum of those things that makes a team. Alone we could do some of the things we want to achieve but it’s together that we can make it happen.
  - dasil003 4y ago
    What I’ve noticed over the decades is that performance on large teams is largely a function of systemic behaviors and culture. The larger the “team” (ie. everyone you have to interact with to get something built), the less any one individual’s performance matters. In particular I’ve seen situations where every single person is working hard doing their job in a defensible way, but the code base is heading towards a cliff because no one has the incentive and/or skill set to point out that the short term decisions made on either side of the engineering /product divide are steadily inching us towards a state where the code base will be too complex to add a feature or fix a bug without creating more bugs. Ultimately this type of problem has to be owned by management with support all the way up the chain in order to be solved. That doesn’t mean ICs and PMs don’t have a role in the solution, but this is why engineering management is hard and requires technical depth.
dangerface 4y ago
> Scoping and planning is hard, specially with limited info, and you can't reasonably allocate 10x the resources to your project just to have a decent slack in the critical path. Why not? If you don't have an accurate understanding of the problem you NEED to allocate extra time to gain that understanding or redevelop as the requirements emerge. > emergent technical requirements that dev teams didn't managed to see beforehand What? So developers that see poor breifs and ask for more time to manage that lack of information can't be given that time but then its the developers problem for not asking for more time to manage that? Your developers don't have a crystal ball! It's high time that Management stop blaming developers for the things managers control.
highwaylights 4y ago
I sort of simultaneously agree and disagree with you here. Are managers at fault for all problems? Intuitively I would very much doubt that’s true of any project anywhere. Are managers responsible for all problems? It depends on the environment and level of autonomy but.. kinda, yeah. The first rule of leadership is that everything is your fault. You kind of have to pick which one you want to define “to blame” as here, but I’m tempted to stick with the latter, if only because I don’t know of a lot of managers that had guns put to their head to take the job, and my own experience tells me that the pay disparity usually covers it.

watwut 4y ago

Meh, you gotta admit management of software projects tend to suck. Yes scoping and planning is hard, but management that don't even try either (and is not agile either) is fairly frequent. Also, we are for some reason blessed with management with not much soft skills. Stuff like new manager coming in and insulting people right and left on the first day with no reason just because they are insecure or arrogant is frequent too. There are good manager, I worked with some. But bad management is frequent and there is very little accountability for managers, so they get stuck for years and decades.

dr-detroit 4y ago

BlargMcLarg 4y ago

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.

mihaigalos 4y ago

How exactly do you "manage" a creative process to respect a deadline? Do you tell a painter to get it done by Monday? That's why small iterations are there in the first place: to constantly add incremental value, not "big bang" plan-the-work and work-the-plan but reacting to change.

bluedino 4y ago
Are they painting a house or are they painting portraits?
bumby 4y ago
I guess that depends on whether they are operating as software engineers or software artists. Sure, an artist can have leeway for their creative efforts. But allowing artists to work on a muse-driven timeline is also why the stereotype of a "starving artist" exists. Engineers on the other hand have some product with at least a baseline of utilitarian value. Those generally need timelines because somebody is planning on a delivery of that utility. But I think both those are besides the point. You can have a structured process that also integrates creativity. I think treating them as mutually exclusive is a false dichotomy.

DougBTX 4y ago

> It's high time that developers cease the "everyone around me is incompetent and responsible for all problems" mindset I reckon there’s some selection bias here too, people who perceive themselves to be incompetent probably talk about it less.

arinlen 4y ago
> I reckon there’s some selection bias here too, people who perceive themselves to be incompetent probably talk about it less. The issue here is not what's the true skill level of anyone in the team. The problem is this recurrent theme of software developers demeaning everyone around them while portraying themselves as flawless saviours. A key trait of software development is JIT onboarding and continuous development. If you develop your skills and today you're a better developer than you were yesterday, that means that yesterday you were a worse developer and quite possibly quite bad by your measuring stick from some point in the future. Thus if JIT onboarding and continuous personal development is a basic aspect of software development jobs, why is not being ab absolute expert on everything the target of so much criticism and abuse? I often look to the work I've done in the past and often times I come across less optimal choices that today I wouldn't make. I'm sure the only ones who don't experience the same are thise who learn nothing from anything. Therefore, why use that as a target for abuse?
- peteradio 4y ago
  > A key trait of software development is JIT onboarding and continuous development This is a horrible trait and a recipe for painting oneself into corners unless you are only working on trivial stuff that's been done before.
  - BlargMcLarg 4y ago
    Yet it's all too common today. Here's a fun exercise for anyone: imagine what would happen if 10% of the team would go away in the next month. Now imagine if it was 80%. For how risk-averse companies are, it's pretty crazy how bad their back-up plan is should the latter happen.

bbarn 4y ago

I think you hit the nail on the head here. I am a lot more understanding at this later stage in my career when someone shows me a big ball off spaghetti in a project. I don't know why decisions were made, what trade offs for time or requirements were made in the past, what designs might have made sense that got turned upside down with new features, etc. I tend to shut down sentiments like "This all needs rewriting" or "What on earth was this person thinking" as much as I can. Most of us are decent enough at our jobs, and generally the industry does a good job of weeding out those who can't perform or they end up lost and irrelevant in some big company. There are certainly some bad developers out there, but there's bad doctors, bad lawyers, etc. in the real world too. That said, the impact a bad manager can have is definitely of a greater magnitude than a bad engineer, generally speaking.

agentultra 4y ago
Hard agree. It annoys me that this has the air of a “hot take,” but I don’t believe anyone wakes up in the morning and thinks, “I’m going to write overly clever spaghetti code today and do as bad a job I can.” People are generally good and want to do a good job and be recognized by their peers. Different people have different strengths and skills. It’s the sum of those things that makes a team. Alone we could do some of the things we want to achieve but it’s together that we can make it happen.
- dasil003 4y ago
  What I’ve noticed over the decades is that performance on large teams is largely a function of systemic behaviors and culture. The larger the “team” (ie. everyone you have to interact with to get something built), the less any one individual’s performance matters. In particular I’ve seen situations where every single person is working hard doing their job in a defensible way, but the code base is heading towards a cliff because no one has the incentive and/or skill set to point out that the short term decisions made on either side of the engineering /product divide are steadily inching us towards a state where the code base will be too complex to add a feature or fix a bug without creating more bugs. Ultimately this type of problem has to be owned by management with support all the way up the chain in order to be solved. That doesn’t mean ICs and PMs don’t have a role in the solution, but this is why engineering management is hard and requires technical depth.

dangerface 4y ago

> Scoping and planning is hard, specially with limited info, and you can't reasonably allocate 10x the resources to your project just to have a decent slack in the critical path. Why not? If you don't have an accurate understanding of the problem you NEED to allocate extra time to gain that understanding or redevelop as the requirements emerge. > emergent technical requirements that dev teams didn't managed to see beforehand What? So developers that see poor breifs and ask for more time to manage that lack of information can't be given that time but then its the developers problem for not asking for more time to manage that? Your developers don't have a crystal ball! It's high time that Management stop blaming developers for the things managers control.

highwaylights 4y ago

I sort of simultaneously agree and disagree with you here. Are managers at fault for all problems? Intuitively I would very much doubt that’s true of any project anywhere. Are managers responsible for all problems? It depends on the environment and level of autonomy but.. kinda, yeah. The first rule of leadership is that everything is your fault. You kind of have to pick which one you want to define “to blame” as here, but I’m tempted to stick with the latter, if only because I don’t know of a lot of managers that had guns put to their head to take the job, and my own experience tells me that the pay disparity usually covers it.