Live data from Hacker News

Crushing Jira tickets is a party trick, not a path to impact

seangoedecke.com

1–10 of 86 posts

Re: Crushing Jira tickets is a party trick, not a path to impact

#3

Another way to frame this is to not get too attached to your code. Tmrw it could be the cornerstone to a new line of business or it can be burned in the dumpster.

That’s not the takeaway. The author said work on “projects” not “tickets”. In other words, volunteer to be the single responsible individual for “work streams” or “Epics”. This is actually the behavior of a mid level developer at every tech company whose leveling guidelines I have seen either internally, talked to other people about or that’s publicly available - ie Drobox

https://www.levels.fyi/blog/swe-level-framework.html

https://dropbox.tech/culture/sharing-our-engineering-career-...

A senior developer should be over guiding an implementation and mentoring and coordinating mid level and junior developers.

I made it a point ny entire career not to be a “ticket taker” and be able to say I “lead” or “designed” a major feature or implementation.

Re: Crushing Jira tickets is a party trick, not a path to impact

#5

Another way to frame this is to not get too attached to your code. Tmrw it could be the cornerstone to a new line of business or it can be burned in the dumpster.

That’s not the takeaway. The author said work on “projects” not “tickets”. In other words, volunteer to be the single responsible individual for “work streams” or “Epics”. This is actually the behavior of a mid level developer at every tech company whose leveling guidelines I have seen either internally, talked to other people about or that’s publicly available - ie Drobox https://www.levels.fyi/blog/swe-level-framew…

Thanks for sharing

Re: Crushing Jira tickets is a party trick, not a path to impact

#6
> But this is a dead end. You’ll get a pat on the head, told “nice work, don’t burn yourself out”, and no progress towards a senior promotion.

Eh, this might be accurate (for certain teams/companies) but I was on a team where I was the contractor. Everyone else was SO focused on promotion that they got zero work done ever, and I got a dozen tickets crushed each week. The whole (oversized) startup ending up failing, but the CTO ended up pulling me in to another project they helped start, one with a massively leaner team, and we crushed that project and made it truly successful. I didn't even know anything about the role (data warehouse engineer) but he knew I would work hard, learn fast, and get things done, and that was what mattered.

Re: Crushing Jira tickets is a party trick, not a path to impact

#7
post #4

> If you ship a project and your management chain begins talking about the next thing, stop improving that project. and this type of advice is precisely why the whole industry completely lost its ability to produce usable things.

Or in the case of Google at one point had 5 messaging apps shipping simultaneously and talked about three of them at one Google event. Shipping new products shows “impact”. Maintaining and improving existing products don’t.

Re: Crushing Jira tickets is a party trick, not a path to impact

#8
I was given high impact projects precisely because I crushed tickets as a junior. I demonstrated repeated mini-competencies (crushing tickets), gained credibility, then got to demonstrate macro-competency (deliver projects).

Definitely agree that "crushed many tickets" is less effective in performance review than "delivered critical project". I'm not sure how one gets to be responsible for a project without first crushing tickets, though.

Just my experience, curious what other folks have seen/experienced.

Re: Crushing Jira tickets is a party trick, not a path to impact

#10
Yup. The people on my team who are the most respected and influential, getting steady promotions and good reviews, hardly crush tickets.

If you look at sprint histories, and went purely off of tickets, you might think they did nothing at all! And maybe they don’t!

But, they’ve shipped a few key projects and features that totally improved our product so much that now everyone has less work to do because everything just works so well most of the time.

I think of these guys as the big guns, we just keep them around on payroll in case we have something really difficult to do.

Post reply on HN