I have no desire to be a jira centric developer.

I don't want to be proficient in handling a board or spending my days as a consultant in ticket comments.

I just want to grab a ticket and write code.

Anything short of this is not why I got into development.

  • 0
    Random question from someone who also doesn't want to be tied up in jira...

    How do you want work to be given out to you and tracked? Emails, Slack/Teams messages, sticky note on your monitor from your boss? Like how would work find its way to you and how would you let whoever assigned you that task know it was done?
  • 0
    @valkn0t if i had it my way, sticky notes on my wall. But its not realistic in an org any bigger then 10 devs. Im fine with jira if im not spending my time in jira. It should be used for me to read a ticket and move it along when finished, thus alerting qa and whoever else is tracking it.
  • 0
    There is an integration trick where you can bind jira and git so that your commits become a comment or close a ticket or some shit like that. Maybe look into it?
  • 1
    @NoMad we're using it. Its more so adding meta data to jira from commits which is helpful. But theres still so much discussion happening on the app, its painful.
  • 1
    @dUcKtYpEd I see. So the requirements aren't clear or keep changing?
  • 1
    Just go work for an agency then, I thought it would be fun to just have a simple "Add this to that" task but now I absolutely hate it, it's so bad that I started begging my PM to write details in the tickets.
  • 0
    @skylord I actually came from an agency. Loooove agency Jobs. Always fun. Half the pay
  • 1
    @NoMad there is just a lot of expected developer feedback in the ticket process. That’s the problem. Lot of mentions. Lot of back and forth
  • 0
    @dUcKtYpEd where would you prefer the communication to happen? Like in a group chat type format?

    I hate getting tagged in comment sections on like Jira or Salesforce tickets bc I don't use those platforms day to day, so it's a hassle logging in and responding. Most people just hit me up on Teams/Slack, or we make a group chat and use that. Sometimes I feel like it would be nice for people looking at the ticket could see the group convos we had around it, discussing the problem, potential solutions, etc.
  • 1
    Oh yeah, I know what you mean...

    What I'd like to do:

    move a ticket from "todo" to "in progress", code, and then put it from "in progress" to "on review" and move on...

    what it's often like:

    you get a ticket... there's already 3 comments from someone because on the last 3 meetings you may or may not even be in they decided to change the spec... you take the ticket... you start coding it when suddenly there's an email informing you that a ticket from 2 months ago has a new client comment on it, because they finally decided to respond.. so you open it up because your SLA mandates you respond within 24 hours, which means if you don't do it now you'll prolly forget... so then you start responding to some shitty question comming from someone who clearly doesn't know what they are doing when in turn a new email notifies you there's a completely new ticket created for a bug in feature you coded a year ago...
  • 0
    @Hazarth this. This is exactly what I’m talking about. My experience with it to a T. Then we’ve got gong integrated with it too
  • 2
    @Hazarth So I'm not sure if this is just the process implemented where I work, but devs don't pick up tickets/tasks/stories that haven't been scoped for the sprint. Unexpected tickets are immediately prioritized by the product mgr usually at the daily standup the next morning and picked up by a dev right then and there. If it needs to be dropped by one and picked up by another it's the responsibility of the prev dev to bring the next one up to speed.
  • 1
    I would correct your statement to be more precise: You want to be an developer, not a mixture of developer and manager without management permissions...

    Company / project management is at fault here.

    What's worse is that splitting the info flow on dozens of devs just destroys any time management... Sigh.
  • 1
Add Comment