I was a gifted kid who realized that when I applied myself all I got was more and harder work that I also didn’t want to do. Being successful academically felt like a punishment.
So I don’t mind at all that I’m filling out Jira tickets. It’s easy work and I have other things to enjoy.
My high school never had math competitions so I’ll never know how I’d do. :(
I feel personally attacked by this post!
I don’t get the hate for Jira
Seems like the hate I see for JIRA and Bitbucket consistently boils down to whoever implemented them being bad at their job
Maybe it’s badly implemented where I work, but I feel it’s clunky and messy
Kind of off topic but some people are really bad at writing jira tickets.
“Show the user a list of projects [eof]”
Ok but like, only their projects, right? Do they need to be ordered? Searchable? Paginated? Only active ones or soft deleted ones, too? Do you just need the name or do you need metadata too?
Somehow product doesn’t love my stance of “if it’s not on the ticket or in a sop, the behavior is undefined and you get what you get” stance.
The problem is that requirements refinement has been unceremoniously dumped in your lap. The failure here is organizational; maybe you have a design person involved, maybe devs are expected to do this. Either way, your job now also includes communications.
One strategy I’ve used is to draw a low-fi example of what they’re going to get - Figma is great at this these days. Then I add it to the issue and push the whole thing back for early approval in order to suss out these finer points.
Not to come off as misanthropic here, but many people are hot garbage at describing what’s in their head. Most of the time, it’s all abstract concepts up there until you start asking the real questions. They really do need a whole-ass conversation to sharpen that mental image. Or in this case, what they want that feature to look like. Incidentally, this is also the reason why therapy is a thing, and why it takes people years to make sense of themselves, and that outcome is usually far more crucial than anything we’re doing at the keyboard.
Reminds me of this gem: https://lizengland.com/blog/2014/04/the-door-problem/
Dealing with this at the moment - in an org that’s been pretty lax at writing anything down about what and why as far as internal software goes, trying (with support from C-suite) to get people to actually write up any amount of detail in their requests is like pulling teeth.
I tend to take that position as well; if it’s not defined, I get to define it. If I ask for feedback or review and get silence, that means you approve.
If it’s someone else’s job to design things, then that’s a pretty terrible specification. But depending on your role, it’s common enough for there to be one person who designs and builds a feature like “User projects dashboard”, and the job is to decide what’s important based on the product. Especially with smaller companies.
