[twelfthnight]

So true. Communication is insanely difficult. Hiring competent, motivated engineers is insanely difficult. Working around short-term thinking executives is insanely difficult. Iterating until you stumble on a success product is insanely difficult.

How often does anyone talk about these problems in meetings? It's wild, I feel like all I ever do is argue over mostly irrelevant technical minutia.

[nikau]

welcome to bike shedding

https://en.wikipedia.org/wiki/Law_of_triviality

[huygens6363]

Exactly! It's this huge elephant in the room and all we want to talk about is our editors and how Java is faster than Go or whatever.

I'm sitting in this meetings thinking "Guys, using XML or JSON truly, truly does not matter here. You have already wasted months on this shit and the value meter is still at $0. I'm telling you we can make this work with either Scala or 6502 assembly or anything in between. What matters is that we need a coherent vision, formulate actionable goals and work on improving our communication and keeping it there."

Maybe I need to go into management? (/s ?)

[anon64765446]

It's almost as if you are describing the meetings in my company (and my previous)

I think focusing on technical trivialities is a symptom of what type of experience the developers have and how the current workplace is organized.

In traditional companies, the developers are at the tail of a process that they have limited participation in. Most of the product decisions has been done by others and the developers often don't have enough contact with the business side to make any real impact.

You end up with an isolated group that can only influence technical desicions, so that's what they will focus on.

Choosing tech X vs tech Y is actually only 1 choice in a long chain of product, design and business choices that has led to the Jira ticket. From their point of view, it seems like the most important desicion because it is taken out of context.

This is where experience is actually a good thing, because it increases the chance that you have been exposed to "the other side". They will also know that these types of decisions are not likely to be the reason why they fail.

By participating from the beginning you also tend to be more motivated by outcome. Technical discussions that don't have a real impact become less interesting.

[twelfthnight]

This resonates with me, although I would go a step further to say the makeup/experience of the developers is a product of the competency of leadership. Most leaders wind up in their positions out of pure luck and chicanery. I can't tell you how many lay offs I've been through where the best people are let go and the worst are kept on and unintentionally sabotage the entire engineering team.

[wruza]

focusing on technical trivialities is a symptom of what type of experience the developers have and how the current workplace is organized

It comes from development echo chambers (including this one, sorry HN), where people tend to discuss The Right Way even if they see it not working at their own job, cause right ways feel good. New/young developers absorb it and bring it to their workplace. I did that too. It took decades to beat this shit out of myself. Now when I hear someone talking about true ways of a qualified professional developer I just remember that the business will probably pivot a couple of times before they deliver an mvp that is neither v or p.

[twelfthnight]

I for one would love to have a boss that cares about those things.