An often overlooked aspect of development is understanding the thoughts and opinions of other non-developer team members when completing a story, and importantly understanding what they quantify as being able to mark a task complete.
A recent addition to the average development team, the UI/UX designer is somebody who is often the victim of this lack of understanding; when under a looming deadline, team members that are not as involved with the look and feel of the site will often suggest that "near enough is close enough" for the visual aspects. The need to have the story marked as completed so they can get started on the next task will supersede the view of getting that slice of the system right the first time around.
For those whose whole career is based upon getting a website looking immaculate on each browser, device, and platform, having a button be 5 pixels out of alignment on a single device is akin to you as a developer writing a nasty set of class logic and having to pushed it to production. It works, it does its job, but every time you look at it, you wince; you hope when somebody finds it, particularly if it's your boss, that they don't assume you cut-corners or purposefully wrote lazy code.
Another frequent victim from lack of communication are testers; as an engineer it is easy to feel that testers are doing little more than nit-picky work where they point out every tiny flaw within your work. From the perspective of a tester however, their position within the team is to ensure that the completed task meets the criteria set by the product owner, not reporting bugs; this process is simply a byproduct.
When an API response is incorrect, it is acceptable for a tester to flag it as an issue, should it be treated differently than when the wrong shade of blue is put down on the background, or a button being 5 pixels out of alignment? As an engineer, the API not returning a valid response may seem like a far more significant issue than the background colour being incorrect; for some members of the team however, and even for the stakeholders, it may be the critical to the task, and for a tester, both issues are simply acceptance criteria not yet met.
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. Taking the time to understand why something that may seem trivial to you, is of a high priority to others, encourages collaboration within the team, and will generate the type of communication that ensures tasks are completed where all relevant parties are happy.
Top comments (3)
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.