Right but I see this taken too far. Getting side eyed for creating a Jira ticket not doing it now. Dude, I am creating a Jira ticket because I have 100 things to do and need to actual priorise this! If I do stuff in the order of serendipity I will definitely be inefficient.

▲ jimbokun 4 hours ago | parent | next [-]

It does add up though.

    1. Ticket
    2. Feature branch
    3. Write unit test
    4. Periodically merge from main.
    5. Implement to get tests to pass
    6. Push changes
    7. Create PR
    8. Wait for PR feedback
    9. Address feedback and repeat
    10. Close and merge PR
    11. Automated CI deploy
    12.  Integration testing as needed
    13. Close ticket
    14. Include in next prod release

All of these are good things. But the overhead is significant. And there may be times when you want to do spikes that forgo some of these.

▲ arcfour 6 hours ago | parent | prev | next [-]

I don't think that this is an indictment of creating the Jira ticket, or prioritization, or anything. It reads to me like a reminder that we often focus too heavily on the other work and thoughts that are adjacent to doing something, get lost in the weeds, and don't actually end up doing the thing.

▲ fuzzy_biscuit 8 hours ago | parent | prev | next [-]

If you don't create the ticket, it may never get done, too! That not doing the thing might lead to convincing others the thing needs to be done which directly leads to doing the thing.

It may not be doing the thing, but it enabled the thing to be able to be done at all. Cheers to the precursors, the planners and the annotators. Through you, more things are done.

▲ shadowgovt 8 hours ago | parent | prev [-]

I am creating a jira ticket because I will forget I have done the thing.

I am also creating a jira ticket because 11 months later when another engineer is trying to figure out if the code they're staring at is still actually valuable or if they can rip it out safely, they are going to use git blame to find the pull request where the thing was done, that pull request is going to mention the jira ticket, and the jira ticket is going to reference the design document that justified why we did the thing. If we don't do those things, that engineer is going to yank that functionality out and something way over there is going to break without anybody realizing it broke.

Your mileage may vary. Some teams make the PRs detailed enough that they don't have to fall back on jira. Other teams try to encode this information into unit tests (that helps but it's circular reasoning; the unit test will tell you that somebody at one point thought that this was important enough to verify that it keeps doing the thing; they won't tell you why the thing matters or what customer wanted the thing or whether the thing was the thing we did before we pivoted to doing the new thing cuz the old thing didn't make money).

	▲	AstralStorm 3 hours ago \| parent [-]
		It's called documentation. Somehow people forget to include a non-external service dependent version with their code these days. Probably because "nobody is paid for doing that".