Live data from Hacker News

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

seangoedecke.com

31–40 of 86 posts

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

#31

Earlier quoted context omitted.

Surely there's a balance to be found. Personally, I allow myself some not-explicitly-requested improvement work when I see what I view as low hanging fruit. I know the code and effort involved, and sometimes just doing the thing is fast enough it's not worth working it into planning. It also keeps me motivated on whatever "next thing" I'm working on when I allow myself some non-next-thing work. However, there's defin…

How does that work in organizations where everything has to be tied to a ticket and you have to do pull requests?

You work on what you think is the most important, and then you choose a closest ticket # to put into pull request description. If there is no ticket close enough, then you make one first.

Some companies like to micromanage and rob engineers from any sort of autonomy: they have non-engineers make tickets, and those tickets are very small, and they are assigned them without engineer's inputs, and managers carefully monitor that engineers only work on assigned tickets. If that's your case, then I am sorry. Also, it is not not a "senior engineers" position, even if your business card says otherwise. If you are interested in becoming a better engineers, consider a different, less disfunctional, workplace.

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

#32
As someone who's sat on both sides of the table, getting tickets done is incredibly valuable. I don't really think an engineer is worth their salt if they can't do this. However, there's a transition that needs to happen when they hit mid-level where they need to be able to synthesize what the ticket is asking for and implement the right thing. No ticket or product manager is perfect, and awareness is often times a better driver of performance because certain tickets aren't done or are changed due to an engineer's competence.

From the flip side, management is looking at industry trends that the engineer simply doesn't see. It may be the current market is getting saturated with your product and the company really needs to pivot to remain competitive. No amount of further feature work or bug fixing will "fix" the market position. You have to do something different or you will lose sales. While fixing the existing product may make the existing customer happy, it won't continue to drive new revenue.

The only way to really make the two sides happy is to have a level of trust/communication that is rare. What engineer doesn't like to complain about management that keeps changing their mind? What manager doesn't like to complain about engineers that are out of touch with reality? Given this audience, I would say that if you're an engineer, there's an order to the skills: crush tickets, gain awareness of the product so you can do the "right" stuff, then solve your manager's market problems (not the product's).

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

#33

Earlier quoted context omitted.

And this is one reason this industry can be so soul crushing. You're asked to demonstrate "ownership", but at any moment some person above you can take all your work away and make you do something entirely different. Somehow we're asked to care about our work and not care about it at the same time.

This is what bothered me so much about my last job. Thank you for saying it so succintly

I think it's one of the prime causes of burnout. Feeling like you have no real control over things, but having immense responsibility anyway. Fighting learned helplessness with an internal taskmaster.

It's not good for the psyche.

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

#34

This guys’ posts read like someone put Paul Graham in a tumble dryer and interviewed him immediately afterwards on a topic pulled from a hat If you ship a project and your management chain begins talking about the next thing, stop improving that project. In my experience, continuing to work on an already-shipped project is a very common mistake. Declare victory and walk away! Got it. Shipped = Victory. Take some prid…

I can’t exchange “pride” for goods and services. The people that hold the power to give you raises and promotions don’t care about “craftsmenship”

[dead]

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

#35

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 ju…

I have been working at my current company for six months and haven’t wrote a line of code even though my title is “staff software engineer”. I have worked with sales and the customer to close two major deals… I don’t see myself doing any real coding at least for the next six months.

Sounds like you got yourself promoted right up into a sales role. I mean, if you like that and are happy with it, I'm happy for you. But some people enjoy coding, so I'm not sure your success story is as strong of an anecdote as you might think.

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

#36
The most respected and well paid senior engineers and managers at my company are all ex-ticket crushers. They put in their time being the kind of people that managers could trust to get stuff done and done right and done promptly.

Trying to play games and fudge it only works in a company big enough that this sort of gamesmanship goes undetected beyond your immediate team. Or if you have a bad boss that isn't really keeping tabs on who's doing what.

Also, people don't ship shit, teams do. And teams with morale in the toilet because they've got more than a couple people acting like this don't ship the good stuff you want to be associated with.

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

#37

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 cru…

With junior developers specifically, people are actively and almost desperately looking for signals for who might be ready for more responsibility.

And so at that level, crushing tickets provides one such signal of many that are possible. If you're a junior developer and you have opportunity to crush tickets, it's a chance to show off and that could mean being rewarded as you were. It's not the only way, though, and if those tickets and spurious or the work is deprioritized, it could backfire.

The heuristic changes as you move up though, as crushing tickets in not necessarily providing a lot of real value in itself and a more experienced dev that predominantly busies themselves with lots and lots of low-hanging fruit is not really making best use of their talents/responsiblities.

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

#38

Earlier quoted context omitted.

Surely there's a balance to be found. Personally, I allow myself some not-explicitly-requested improvement work when I see what I view as low hanging fruit. I know the code and effort involved, and sometimes just doing the thing is fast enough it's not worth working it into planning. It also keeps me motivated on whatever "next thing" I'm working on when I allow myself some non-next-thing work. However, there's defin…

How does that work in organizations where everything has to be tied to a ticket and you have to do pull requests?

In such an organization, there's no low hanging fruit, because everything requires a ticket writing exercise, and a group consensus managment exercise.

Or you make up a blanket ticket, and self-approve your PRs.

Or you start probing for process in interviews, so you can find somewhere to work without oppressive process.

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

#39
As a developer, the more you understand about the non-technical, business side of your company, the better you can prioritize and communicate about what is important. No need to "read the tea leaves" or guess at how to interpret the gestalt. Just learn what matters to your company's success and how to communicate with the people outside of development. The goal is not promotion and working less than 40 hours a week. The goal is company success. The other stuff follows.
Post reply on HN