The broader point is if you care about sports you understand the passion and that there’s often “a way” of doing things in a sport, you learn it, and you move on.
You don’t argue for 10 minutes that your way of displaying a box score is better than how literally millions of fans expect it to be.
Yes, exactly, and the game Slay the Spire is a strong example. Primarily made by a two-person team. The designer is super passionate about the game (and card games in general). The programmer doesn’t even like card games!
But it works great (it is such a successful game that it spawned a new genre) because both are really good at what they do!
so couldn't you answer that? "I'm very passionate about building useful things, and I can see how your product BLAH can be applied to valuable areas like ..."
I guess it’s a sense of why do I need a PASSION for it. I’ll do it , but my passion more so lies in say not starving to death while enjoying my hobbies rather than caring more than I need to about YOUR product
>I guess it’s a sense of why do I need a PASSION for it
I think at the end of the day, an employee with passion is always better than one without, if everything else is held even. I think this is a tough pill for a lot of people who arent/dont want to be passionate about their work to swallow. It impacts every attribute an employer cares about.
I do work for an esports company. Something a lot of devs are passionate about. In the end after a downsizing they kept the most competent developers even when they cared zilch about esports. Because your passion doesn’t make you write good code. Just makes you happy while writing bad code
Well this is a very confusing argument. If you hire someone who cares about their work, who has passion for it, you're going to need to be prepared to talk things through with them when they think they've worked out a better way of doing things. If you wanted them to just code up what they are told to, you would have been better avoiding all that passion in the first place.
I assume that you've run into this with people before, or you wouldn't be calling it out as a worry.
But I would hope that I'm humble enough to admit (at least to myself) when I don't know much about a particular topic, and would accept at face value, without argument, when someone says to me, "thanks for trying to find an improvement here, but this is just how this data is displayed, and millions of fans expect to be able to read it this way, and will get confused if we do something different".
I'm not passionate about commodity futures trading. I don't care about it at all. But when I work on software which traders will use, I understand that there are specific conventions about how the numbers are displayed and that they need to be understood and used.
>You don’t argue for 10 minutes that your way of displaying a box score is better
most people working in any particular industry understand that there is a particular way things are done for customers in that industry.
on edit: actually thinking about this I recall I was working on a live streaming sports station and I should display some scores (not baseball) I hate watching sports and yet I still chased down several people to find out if there was a well known way that scores should be sorted and displayed because I expected different sports might have different idiosyncrasies and I should provide a generic templating system for displaying the score (these folks evidently didn't care as much as ESPN because there was nothing special I should do)
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.
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.
You don’t argue for 10 minutes that your way of displaying a box score is better than how literally millions of fans expect it to be.