Hacker News new | ask | show | jobs
by XorNot 721 days ago
I don't get it. If the box needs the stats in a particular order, don't you just put that in the task ticket for it? Like how is this requirement being communicated where someone wants to argue about it? If the ticket says "do this" and it's not done then you just fail QA and send it back.
4 comments

I'm very thankful that not all developers work in a code factory where explicit requirements get spit out on their desk at the end of the process. If you're involved in the definition you get to prevent the "team <upstream> is so clueless" issues, and actually learn about what you're building beyond code implementation.
I don't think that's what's going on here, though. Developers often don't design UI, anyway. They're given a UI spec or mock-up from a UI/UX designer, and build it to spec. That's not a "code factory", that's just being a professional about it (and many software developers are terrible at UI design and should grow some humility and accept that).

Regardless, a quick "we need this score box to be laid out exactly this way, because this is the standard in this particular fandom, and our fans will expect to read it this way" should be sufficient. A developer who doesn't accept that, and argues, needs to mature and learn some social and professional skills.

Even more desirable is a dev who you can simply ask to make a score box and they deliver some think that meets or exceeds your expectations without further information.
It's something that would be assumed without being explicitly stated. I'd have no idea how the stats are supposed to be displayed for a cricket match but I'm a fan of other sports so I'd know there's a correct way and would likely ask a cricket fan coworker how to do it. Or research it myself if nobody's a cricket fan. With baseball box scores, I'd know the right way to do it without having to ask.
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?

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.

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.

I don't know where you work but what you describe sounds like a widget factory.