[jasonkester]

Wow. I'm having trouble wrapping my head around this workplace you describe.

I mean, yeah, you've described it well. I can understand how it works. But I just can't imagine working as a developer where the first introduction to a "task" is this finely specified. Like, this dev won't have been involved in the feature at all before seeing it in a card in some task manager app?

Yikes.

Are you saying that you've worked in places like this? Just doing these tiny little tasks, blind, to an app that you have no context on. And you did this for more than, say, a week before quitting? And that week wasn't your first week of your first job out of school?

[XorNot]

How would you QA something like this across all possible sports? Or test it? How was the feature even developed or requested though if the specification isn't written to explain what it is? Are the frontend designers developing the specification? The developers? What about the backend engineers who need to implement APIs?

What if there's a couple of different factions in a fandom for some particular sport that disagree on the ordering?

Imagine doing this for any other industry and expecting coherent results. An effective developer given a vague tasking will do a bit of quick research and come up with an idea, but they could also be entirely wrong compared to the business objectives. Or the task could relate solely to internal business processes, in which case there is no consensus it's whatever the internal culture of the business does.

[kelnos]

I think that's a fairly uncharitable explanation of the GP's point.

Even if the developer is involved in the UI design (which at many shops is -- IMO wisely -- not the case), it takes all of 7 seconds to give context on why a box score needs to be displayed in a particular way.