Understanding your fellow team members, how they work, and what is important to them will lead to a conducive working environment where nobodies concerns are pushed out.
And it will absolutely make you a much better developer yourself! Programming is all about teamwork and nuance.
100% agree - developers who can take a step out of the mindset of requirements + code = done and actually look at what needs to be done, what the actual outcome is of a requirement/story, and why the detail matters, are going to produce far better products and results for the product/business, than those that try to cut corners because they just want to maximise the work done.
Quality always trumps quantity - sometimes that's a hard sell to management but places where management tries to push quantity (in my experience) are not places that are worth hanging around.
With companies these days emphasizing WCAG compliancy, seemingly trivial colour changes can be make-or-break for that 'tick' you require. Getting it right the first time around will also help reduce tech debt as you won't need to return to the work (which in my experience rarely occurs and is poorly prioritised) somewhere down the track .
These issues also seem to occur often due to poor grooming or inadequate estimates on stories prior to the sprint which results in the tasks not being able to start straight away, or finish too early. Focusing on these 'other' aspects of the story will help mitigate both these issues, and make you a better developer as a whole, as you can far more reliably understand, estimate, and create the work which meets the all goals of the product owner.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
And it will absolutely make you a much better developer yourself! Programming is all about teamwork and nuance.
100% agree - developers who can take a step out of the mindset of requirements + code = done and actually look at what needs to be done, what the actual outcome is of a requirement/story, and why the detail matters, are going to produce far better products and results for the product/business, than those that try to cut corners because they just want to maximise the work done.
Quality always trumps quantity - sometimes that's a hard sell to management but places where management tries to push quantity (in my experience) are not places that are worth hanging around.
With companies these days emphasizing WCAG compliancy, seemingly trivial colour changes can be make-or-break for that 'tick' you require. Getting it right the first time around will also help reduce tech debt as you won't need to return to the work (which in my experience rarely occurs and is poorly prioritised) somewhere down the track .
These issues also seem to occur often due to poor grooming or inadequate estimates on stories prior to the sprint which results in the tasks not being able to start straight away, or finish too early. Focusing on these 'other' aspects of the story will help mitigate both these issues, and make you a better developer as a whole, as you can far more reliably understand, estimate, and create the work which meets the all goals of the product owner.