Square obviously not listening to feedback

[Sjol]

I don't understand why you're replying to me since I do mostly agree with this. I specifically replied to people trying to shut us down with "the majority has spoken" arguments.

And the main problem with said majority is that said majority isn't open to any compromise, and is already getting 100% of the cake and changes specifically tailored for them. That our feedback is ignored By SE has been pretty obvious for a while now even though they ask us to continue sharing it. Well, I'm not very smort I guess, and I'll continue doing what I'm told to do.

And yes, I do think SE hasn't been very respectful toward its veterans, and I do feel salty about it. I do hope this isn't too much of a hard concept to grasp even for the privileged out there.

You're right. This should have been more clearly directed at some of the other people speaking. Though, in general, what I'm trying to say is there's a difference between ignored and not acted upon, at least to me.

[Aravell]

You're right. This should have been more clearly directed at some of the other people speaking. Though, in general, what I'm trying to say is there's a difference between ignored and not acted upon, at least to me.

I don't think people expect all of their suggestions and feedback to be acted upon, that's just not realistic. I think what people want is for the dev team to actually communicate their intentions clearly.

Like the healer situation. The dev team has been flip-flopping on the issue for years, never fully committing to anything. If they just stated outright "No, we will never be expanding the damage kit" or "No, we will never be increasing the healing requirements very much at all", then people can accept it and make their decision to stay on or leave the role. The dev team flip-flopping and never committing to one side or another just ends up making people restless and makes the team seem like they're not taking any feedback at all.

It's the same with the Kaiten thing. All the dev team has to do is commit, either say "We heard your feedback, but we have no plans on ever bringing Kaiten back" or "We heard your feedback and we're bringing Kaiten back". The fact that they asked for feedback and then never addressed the topic again makes them look very deaf to the playerbase, and that's not a very good look.

The dev team does not need to do everything we ask for, but they do need to communicate their intentions clearly.

[Sjol]

I don't think people expect all of their suggestions and feedback to be acted upon, that's just not realistic. I think what people want is for the dev team to actually communicate their intentions clearly.

The dev team does not need to do everything we ask for, but they do need to communicate their intentions clearly.

I'm a developer. Not on this, but lots of things at a lot of different companies. I think it might be surprising how much disagreement there is internally on how to proceed with things. In fact, it's usually a sign of a healthy work environment where people can openly disagree and discuss without fear of retribution.

The fact they they've flip-flopped a bunch of times may simply indicate that they have a lot of internal disagreement about how to proceed on various topics. And without agreement, they're unwilling to commit to a strategy for fear of alienating all the people on one side of the discussion. They're all people, too. And you can have decisions get stalled because you don't want to alienate critical people in the office.

You may have a designer in the office who wanted desperately to keep Kaiten, but the director laid out his vision for streamlined jobs but has stated to the designer who was overruled that they're just going get feedback before committing to a decision. I think people see the politics out here but don't see the politics in there. And why would we since it's purposefully hidden.

I think you hit it 100% that they're not committing. They may even recognize that it's causing problems, but not have agreement on the solutions. Admittedly, it's extremely frustrating for the people using their product. I know I've failed the customers of my products a bunch of times. I know our development teams have done it, collectively on more than one occasion. Sometimes it's messy. Sometimes you don't want people to see just how messy the process is.

[Valence]

I don't think people expect all of their suggestions and feedback to be acted upon, that's just not realistic. I think what people want is for the dev team to actually communicate their intentions clearly.

Like the healer situation. The dev team has been flip-flopping on the issue for years, never fully committing to anything. If they just stated outright "No, we will never be expanding the damage kit" or "No, we will never be increasing the healing requirements very much at all", then people can accept it and make their decision to stay on or leave the role. The dev team flip-flopping and never committing to one side or another just ends up making people restless and makes the team seem like they're not taking any feedback at all.

It's the same with the Kaiten thing. All the dev team has to do is commit, either say "We heard your feedback, but we have no plans on ever bringing Kaiten back" or "We heard your feedback and we're bringing Kaiten back". The fact that they asked for feedback and then never addressed the topic again makes them look very deaf to the playerbase, and that's not a very good look.

The dev team does not need to do everything we ask for, but they do need to communicate their intentions clearly.

It also additionally makes them look like they don't know what they're doing, or that they have no idea where they want to go with things forward. Whether it's true or not, it sends a very bad message.

[MagiusNecros]

I think you hit it 100% that they're not committing. They may even recognize that it's causing problems, but not have agreement on the solutions. Admittedly, it's extremely frustrating for the people using their product. I know I've failed the customers of my products a bunch of times. I know our development teams have done it, collectively on more than one occasion. Sometimes it's messy. Sometimes you don't want people to see just how messy the process is.

They follow a 3 step procedure.

Step 1: Create a problem.

Step 2: Look at the problem they created.

Step 3 : Create another problem to fix the previous problem.

[Katish]

I'm a developer. Not on this, but lots of things at a lot of different companies. I think it might be surprising how much disagreement there is internally on how to proceed with things. In fact, it's usually a sign of a healthy work environment where people can openly disagree and discuss without fear of retribution.

The fact they they've flip-flopped a bunch of times may simply indicate that they have a lot of internal disagreement about how to proceed on various topics. And without agreement, they're unwilling to commit to a strategy for fear of alienating all the people on one side of the discussion. They're all people, too. And you can have decisions get stalled because you don't want to alienate critical people in the office.

You may have a designer in the office who wanted desperately to keep Kaiten, but the director laid out his vision for streamlined jobs but has stated to the designer who was overruled that they're just going get feedback before committing to a decision. I think people see the politics out here but don't see the politics in there. And why would we since it's purposefully hidden.

I think you hit it 100% that they're not committing. They may even recognize that it's causing problems, but not have agreement on the solutions. Admittedly, it's extremely frustrating for the people using their product. I know I've failed the customers of my products a bunch of times. I know our development teams have done it, collectively on more than one occasion. Sometimes it's messy. Sometimes you don't want people to see just how messy the process is.

Not all working environments are like this, I am too a developer...and if you question the flow of those above (usually Code I's and Code II's); Or you go against the customers wishes, you end up being reported (thankfully usually the higher ups take heat from this in my company).
And yes, I have seen this...There is no common ground on development, you work with your leader and they pass down to you what the higher ups want. You then execute it...that is all there is to it. So I think your opinion is a bit biased to your own working environment, or position, as not all environments are like this, I can assure you; and the end result on whatever your making (the product) definitely does play into how much say goes into it.

If you do freelancing development, perhaps you have more say...because they have to take your input, as you have to comment on what you changed (if you are a programmer of course). Although I do not have personal experience with freelancing work and only have worked directly for companies, so this is only a guess(?)

[RyuuZero]

Who asked for Damageless Gap Closers on DPS?
I also don't get the hate for Spine Shatter Dive since it's just a Gap Closer, that's also a Jump.. about regarding Damageless Gap Closers overall.. why can't we have Proximity based Damage Values on Gap Closers?

You know.. like in the returning FFXV Event's Warp Strike. I think that would be a Good Change.

[Equitable_Remedy]

Who asked for Damageless Gap Closers on DPS?

Everyone who wanted gap closers to be gap closers and not part of the DPS rotation.

why can't we have Proximity based Damage Values on Gap Closers?

Because running away from bosses to maximize gap closer DPS during a rotation is, at best, awkward. Also, because the first thing.

[Sjol]

Not all working environments are like this, I am too a developer...and if you question the flow of those above (usually Code I's and Code II's); Or you go against the customers wishes, you end up being reported (thankfully usually the higher ups take heat from this in my company).
And yes, I have seen this...There is no common ground on development, you work with your leader and they pass down to you what the higher ups want. You then execute it...that is all there is to it. So I think your opinion is a bit biased to your own working environment, or position, as not all environments are like this, I can assure you; and the end result on whatever your making (the product) definitely does play into how much say goes into it.

If you do freelancing development, perhaps you have more say...because they have to take your input, as you have to comment on what you changed (if you are a programmer of course). Although I do not have personal experience with freelancing work and only have worked directly for companies, so this is only a guess(?)

Certainly, not all working environments are like where I'm currently at, though as mentioned I've worked at a lot of places. The control isn't so much on the code developers, but in the product management and designers. Though in my experience most decisions in most organizations are made in coordination with engineering leads to figure out what is possible and feasible and how long it'll take to do things. I've popped a lot of designer and product bubbles with negative technical feasibility analyses or very long estimates.

I'm mostly trying to communicate the indecision that happens at the product level that leads to flip-flopping and unclear communication. I find that there's this impression that SE, internally, is mentally a monolith or that every decision is coming from Yoshi P. I would be amazed if he's even involved in half the decisions in any meaningful way. That's not typically the director's job. The director is there to set direction, but not necessarily get into every little decision.

[Elkanah]

We're straying a bit far from the topic of the thread, but you're looking at the wrong thing. People pay high rent because they want to live in that expensive place - they don't pay the rent because they like paying rent. That they're willing to pay high rent to live in that expensive place is evidence that they want to live there. In the analogy, time is rent (the cost people pay) and the SMN changes are housing (the thing people consume).

Except that a lot of those housing companies are pushing the rent up for no reason while wages are not increasing to meet that same setting (in most states and cities).