> They'll "figure it out for you" and then spoon feed Jira tickets and Figma mockups to devs.

Been there... never again. If I can't speak to the people that use the software, I'm out, period.

I also agree that I prefer to work this way, but it's crazy to see how many developers have an "I just want to code, I don't want to think about business problems" mentality.

In some ways I respect their devotion to pure technical craft. Personally, I'm not talented enough at the technical aspect to make up for ignoring business needs.

Often it's because getting involved on the business side means doing a lot of politics. Is this problem more urgent than that problem? Who will take credit for solving this problem? If I solve this problem, will they fire half the people who currently solve it manually? If I solve that problem, will it empower a certain scumbag VP who's been clamouring for it? Etc etc.

Codemonkey doesn't want to be involved with all that shit.

Requirements engineering can be extremely draining regardless of it.

What's that? We're three years into this six months project and you just realized again that you don't understand your own job, don't understand the legal requirements placed on you, nor your position in the overall organizational architecture? Of course we can rewrite everything from scratch for you, again. What do you mean there's no budget and it has to just work?

I don't think GP means getting involved with business side decisions, just understanding the "business logic". Where "business logic" is a generic term for anything, it could also be the rules of a sport, how the competition(s) are structured etc. if you are building a sports website...

Wait, I'm no programmer, How could programmer build if they don't understand that minimal business logic ?

Spoon feed JIRA tickets on what to do

It boggles my mind how someone can think they can build anything useful without having a basic understanding of what the thing they are building will be used for... that's a sure-fire way to software that will be a nightmare to use (and support).

My biggest frustration is the people who refuse to get involved with any of the process of defining requirements, but then when the requirements arrive moan about how they're stupid requirements and won't get the job done. You can't have it both ways.

It's because defining requirements is someone else's job, so if you get involved, you will be doing part of their job while you might already be working at your capacity.

The Agile style user stories that often lack technical details because the author doesn't know enough about the technical details means the developer is the one actually writing the requirements (usually as they are doing the work).

I've experienced this too at a bigco. A well-meaning group of UX people took on the role of conducting all user observation studies. And the studies were high-quality and statistically valid, but it took months to get observations I could have seen directly in minutes. So the recommendations were mostly about things I'd already fixed or changed.

It's much better to just talk to users and watch them work. A same-day feedback loop beats any improved study quality.