4 ms·

From anecdotal evidence, a) is more likely than b). The deadlines are arbitrary because most companies are slow bureaucratic oil tankers that are difficult to s

From anecdotal evidence, a) is more likely than b). The deadlines are arbitrary because most companies are slow bureaucratic oil tankers that are difficult to steer and will mow down everything in their path once a course is set. Management's job should to be to work on this, to improve the system as a whole and making it more nimble, not on myopic deadlines that fulfil some checkbox and are tied to your EOY bonus. This is outlined by people like Deming and others in the systems thinking space. From experience, in their career, engineers not only need to excel technically, but are also forced to pick up everything from UX, methodological BS (from Scrum to Itil) to domain specific know-how in multiple fields or areas. Since many managers do not know what they're doing, senior engineers often times end up being de facto management consultants as well. If you are working in a business environment (as opposed to writing low-level drivers or whatever) it's almost impossible to not pick up on what's going on around you. How many banking managers know how to code? How many engineers working in banking know at least something about the processes, compliance issues, how the org is structured, what the competitors are? The stereotype of the autistic programmer who is only interested in shiny gadgets and tech needs to die.

gregjor 5y ago
I agree, except the programmer (autistic or not) who wants to be left alone to code and play with shiny things is not just a stereotype. Just read through HN any day to see posts about ignoring meetings, marketing, management, business priorities and focusing excessively on languages, tools, the “best” ways to do things, dismissing non-programmers as hopelessly useless (“many managers do not know what they’re doing.”) As a freelancer I have to get to know the business my customers are in, I can’t just focus on purely technical things most of the time. Many times I have described my work to other programmers and heard how they want to be left alone to code. I take over legacy software and failed projects for a living. The two main reasons in my experience for software dev project failure are (a) developers did not bother to gather and understand requirements but rushed to start coding, and (b) poor communication with the customer and stakeholders. Those faults may come from arrogance or inexperience, or both.
- pm90 5y ago
  > Just read through HN any day to see posts Only an incredibly tiny slice of professional engineers are on HN, even smaller slice of that actually post anything. HN is not representative of anything.
  - gregjor 5y ago
    For most of my 40 year career as a programmer HN didn’t exist, but the complaints about management and business priorities did. And so did those stereotypical developers who want to be left alone to play with shiny things. You can find the attitude I described all over the place, not just HN. When I get involved in a failed or failing project the developers almost always blame management, schedules, budgets, marketing priorities. They almost never reflect on the time they’ve wasted or how they don’t really understand the goals or users for the software they are responsible for.
    - uglygoblin 5y ago
      > They almost never reflect on the time they’ve wasted or how they don’t really understand the goals or users for the software they are responsible for. I think the quoted statement tends to be a systematic issue on struggling projects that describes the decision makers, regardless of role. I'm not sure how anybody can expect other outcomes than a few lucky successes and a lot of failures when understanding why you are building something seems to be undervalued by management, technical or other.
- FinanceAnon 5y ago
  > (a) developers did not bother to gather and understand requirements but rushed to start coding Because of arbitrary and too short deadlines > (b) poor communication with the customer and stakeholders Communication is a two way street. Why blame devs for all this? In my opinion, when a project fails, you have to blame the people higher up in the management chain who are coordinating the work, rather than the engineers. (in a large company) If engineers are to blame, maybe look at your hiring standards and hire better engineers. This points back to the management again. > Those faults may come from arrogance or inexperience, or both. Don't hire arrogant or inexperienced engineers then?
senko 5y ago
> The stereotype of the autistic programmer who is only interested in shiny gadgets and tech needs to die. The stereotype has been kicked to death, dismembered, burned, rebuilt as an effigy and burned again throughout the years. The stereotype of the evil and incompetent manager who is only interested in ruining the lives of their underlings, who would solve the world's problems if only left alone to do their jobs, is still going strong.
- kitsune_ 5y ago
  I agree with you here, but some observations: Managers are imbued with more formal power than their reports and as such should be held to a higher standard. Simply passing on pressure and not standing up for your team will never inspire loyalty. Taylorism and top-down management are culturally embedded in many companies. With software eating the world you have companies who are ill-equipped to deal with other ways of working and do not understand how writing software is fundamentally different than building a house. This all inevitably leads to cultural conflicts.
BackBlast 5y ago
I think every case is individual. One of my recent gigs had management failures and engineering failures. Management failed to communicate the limitations of the investment by investors to finish a project. In this case 4 months window of having an additional small team to build it. I had to pay very close attention to extract that information, my inquiries into it were rebuffed. My contract held the most clues. Engineers didn't bother to listen to the clues and started a design by committee loop that was going to take a year+ to finish. They were much more interested in new shiney things than the financial business restrictions and this attitude was enabled by management. We managed to finish something within the investment period only because I pushed and prodded at every turn trying to finalize decisions and cut out scope, without managements help, to do so. The manager who tried to shield engineering from deadlines didn't help this despite the train wreck I tried to communicate. At the end of the investment period all the extra engineering hired for the task were let go and the regulars were left to finish the demo we managed while maintaining their normal work load. It is now almost a year later it still isn't released. While there are places where tone deaf management creates death matches for no good reason. There are apparently also places where management let's engineering walk all over them like a spoiled child with no grounding in financial realities.

gregjor 5y ago

I agree, except the programmer (autistic or not) who wants to be left alone to code and play with shiny things is not just a stereotype. Just read through HN any day to see posts about ignoring meetings, marketing, management, business priorities and focusing excessively on languages, tools, the “best” ways to do things, dismissing non-programmers as hopelessly useless (“many managers do not know what they’re doing.”) As a freelancer I have to get to know the business my customers are in, I can’t just focus on purely technical things most of the time. Many times I have described my work to other programmers and heard how they want to be left alone to code. I take over legacy software and failed projects for a living. The two main reasons in my experience for software dev project failure are (a) developers did not bother to gather and understand requirements but rushed to start coding, and (b) poor communication with the customer and stakeholders. Those faults may come from arrogance or inexperience, or both.

pm90 5y ago
> Just read through HN any day to see posts Only an incredibly tiny slice of professional engineers are on HN, even smaller slice of that actually post anything. HN is not representative of anything.
- gregjor 5y ago
  For most of my 40 year career as a programmer HN didn’t exist, but the complaints about management and business priorities did. And so did those stereotypical developers who want to be left alone to play with shiny things. You can find the attitude I described all over the place, not just HN. When I get involved in a failed or failing project the developers almost always blame management, schedules, budgets, marketing priorities. They almost never reflect on the time they’ve wasted or how they don’t really understand the goals or users for the software they are responsible for.
  - uglygoblin 5y ago
    > They almost never reflect on the time they’ve wasted or how they don’t really understand the goals or users for the software they are responsible for. I think the quoted statement tends to be a systematic issue on struggling projects that describes the decision makers, regardless of role. I'm not sure how anybody can expect other outcomes than a few lucky successes and a lot of failures when understanding why you are building something seems to be undervalued by management, technical or other.
FinanceAnon 5y ago
> (a) developers did not bother to gather and understand requirements but rushed to start coding Because of arbitrary and too short deadlines > (b) poor communication with the customer and stakeholders Communication is a two way street. Why blame devs for all this? In my opinion, when a project fails, you have to blame the people higher up in the management chain who are coordinating the work, rather than the engineers. (in a large company) If engineers are to blame, maybe look at your hiring standards and hire better engineers. This points back to the management again. > Those faults may come from arrogance or inexperience, or both. Don't hire arrogant or inexperienced engineers then?

senko 5y ago

> The stereotype of the autistic programmer who is only interested in shiny gadgets and tech needs to die. The stereotype has been kicked to death, dismembered, burned, rebuilt as an effigy and burned again throughout the years. The stereotype of the evil and incompetent manager who is only interested in ruining the lives of their underlings, who would solve the world's problems if only left alone to do their jobs, is still going strong.

kitsune_ 5y ago
I agree with you here, but some observations: Managers are imbued with more formal power than their reports and as such should be held to a higher standard. Simply passing on pressure and not standing up for your team will never inspire loyalty. Taylorism and top-down management are culturally embedded in many companies. With software eating the world you have companies who are ill-equipped to deal with other ways of working and do not understand how writing software is fundamentally different than building a house. This all inevitably leads to cultural conflicts.

BackBlast 5y ago

I think every case is individual. One of my recent gigs had management failures and engineering failures. Management failed to communicate the limitations of the investment by investors to finish a project. In this case 4 months window of having an additional small team to build it. I had to pay very close attention to extract that information, my inquiries into it were rebuffed. My contract held the most clues. Engineers didn't bother to listen to the clues and started a design by committee loop that was going to take a year+ to finish. They were much more interested in new shiney things than the financial business restrictions and this attitude was enabled by management. We managed to finish something within the investment period only because I pushed and prodded at every turn trying to finalize decisions and cut out scope, without managements help, to do so. The manager who tried to shield engineering from deadlines didn't help this despite the train wreck I tried to communicate. At the end of the investment period all the extra engineering hired for the task were let go and the regulars were left to finish the demo we managed while maintaining their normal work load. It is now almost a year later it still isn't released. While there are places where tone deaf management creates death matches for no good reason. There are apparently also places where management let's engineering walk all over them like a spoiled child with no grounding in financial realities.