zlacker

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.

>>gregjo+(OP)
> 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.

>>pm90+V1
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.

>>gregjo+(OP)
> (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?

>>Financ+o3
Management may be at fault, but anecdotally I see programmers rushing to code very often. Almost every one of my customers has the same story: the last developers stopped answering emails and calls when the project ran into problems.

I have worked with terrible managers an dysfunctional organizations, but I have seen developers rush to code and stop communicating far more frequently.

I don’t really care about blame. These are people problems with no single solution. When I get involved in a failed project the customer has moved past blame and just wants to salvage something to meet their requirements. The programmers will blame management with little introspection about their own role in the failure.

>>gregjo+f4
I do disagree. The primary responsibility of the manager is to manage and to manage they need to understand the process. The problem is that managers very often do not understand the software engineering field particularly well at all. I've seen it a thousand times that both large and small issues are simply ignored by managers, because they either do not understand them or even if they manage to grasp something, they fail to understand that they need to actively do something about it or just plain out ignore the issue, either with wishful thinking or just a power move where they think the issue isn't theirs to solve and in fact that the issue lies on the engineer to resolve. Most engineers are highly logical and would not bring something up without good reasons. It will have a negative impact if not handled.

I do not manage like this myself and I do not blame my engineers for anything that sits on my head, but I learned these lessons painstakingly through 15+ years of professional coding myself, seeing all kinds of roles at all kinds of companies creating chaos, project managers, product managers, bad managers, bad manager's managers, etc, but also the good ones luckily, the ones that were respected, knew what they were talking about, won the hearts of engineers, etc. This is what I modelled my own path after.

>>gregjo+(OP)
So, projects fail because of (arrogant or inexperienced) developers but not because of managers. And then you wonder why engineers say “many managers do not know what they are doing”.

>>gregjo+U2
> 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.