3 ms·

I was given high impact projects precisely because I crushed tickets as a junior. I demonstrated repeated mini-competencies (crushing tickets), gained credibili

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.

kidbomb 2y ago
It's not about crushing tickets. It's about crushing the right tickets.
bashtoni 2y ago
I suspect this is a very common experience. I don't think that 'crushing tickets' is a good metric of developer competency, but it's a very visible metric regardless and is therefore probably a good way to progress in many organisations.
- scarface_74 2y ago
  But only to a mid level developer.
scarface_74 2y ago
> I'm not sure how one gets to be responsible for a project without first crushing tickets, though I skipped the whole junior developer thing. I was hired at a company as a computer operator based on a prior years internship. I was the only one that knew how to code and they got a contract where they needed to build an entire connected double entry verification data entry system with about 10 screens and a management console. I wrote the entire thing in C in the mid 90s. Unfortunately, after working at another company for 9 years after that, I became an expert beginner by 2008 and didn’t start learning best practices until 2012-2014 at my 4th company. So in other words - “don’t do that”.
theamk 2y ago
I think the OP's point is that "crushing the tickets" should not be your first priority. That does not mean you should not be closing JIRA tickets, but it does mean that the number of tickets closed should not be your #1 metric. In other words: if you have a choice of closing 10 easy tickets or 1 hard ticket this week, what should you choose? It's a trick question! You should be choosing whatever is most important for company. If those 10 tickets are required for release, by all means, crush them! But if there is a high-profile incident that VPs pay attention to, then forget about 10 tickets and do that single one to mitigate it.
- jq-r 2y ago
  Which reminds me of a previous discussion: Don't do easy things https://news.ycombinator.com/item?id=27988260 https://news.ycombinator.com/item?id=27988260
- ebiester 2y ago
  Two caveats for less-experienced engineers (whether by senority at a company or years in the industry): * As a manager, I would prefer you to crush those ten easy tickets if you aren't up to the task of the hard ticket. If that hard-for-you ticket is easy for someone with more skill, and we're in a high profile incident, I am going to steer you away from it. * As a manager, if you show me you can crush the easy tickets, I will find a way to guide you toward harder problems. Then, if you show you can do the harder problems, and those around you are in agreement that you are tackling those, then you have the leash to start swarming to issues. Note that you can usually prove this within 1-3 months - I'm not talking about an extensive time of paying your dues here. But make sure not to try and skip a rung.
  - nosefurhairdo 2y ago
    I made this thread's root comment: this is exactly how I was managed, including the "can prove this within 1-3 months" timeline. Glad to see there are other good managers out there. It's a bit horrifying seeing the pessimism in these sorts of threads. Would strongly encourage folks in low-autonomy teams to seek other opportunities.
corytheboyd 2y ago
100% agree, you simply have to prove varied competencies repeatedly to level up. It’s very intuitive, and leading projects means guiding others to execute the varied competencies you’ve now demonstrated your understanding of.
swatcoder 2y ago
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.

kidbomb 2y ago

It's not about crushing tickets. It's about crushing the right tickets.

bashtoni 2y ago

I suspect this is a very common experience. I don't think that 'crushing tickets' is a good metric of developer competency, but it's a very visible metric regardless and is therefore probably a good way to progress in many organisations.

scarface_74 2y ago
But only to a mid level developer.

scarface_74 2y ago

> I'm not sure how one gets to be responsible for a project without first crushing tickets, though I skipped the whole junior developer thing. I was hired at a company as a computer operator based on a prior years internship. I was the only one that knew how to code and they got a contract where they needed to build an entire connected double entry verification data entry system with about 10 screens and a management console. I wrote the entire thing in C in the mid 90s. Unfortunately, after working at another company for 9 years after that, I became an expert beginner by 2008 and didn’t start learning best practices until 2012-2014 at my 4th company. So in other words - “don’t do that”.

theamk 2y ago

I think the OP's point is that "crushing the tickets" should not be your first priority. That does not mean you should not be closing JIRA tickets, but it does mean that the number of tickets closed should not be your #1 metric. In other words: if you have a choice of closing 10 easy tickets or 1 hard ticket this week, what should you choose? It's a trick question! You should be choosing whatever is most important for company. If those 10 tickets are required for release, by all means, crush them! But if there is a high-profile incident that VPs pay attention to, then forget about 10 tickets and do that single one to mitigate it.

jq-r 2y ago
Which reminds me of a previous discussion: Don't do easy things https://news.ycombinator.com/item?id=27988260 https://news.ycombinator.com/item?id=27988260
ebiester 2y ago
Two caveats for less-experienced engineers (whether by senority at a company or years in the industry): * As a manager, I would prefer you to crush those ten easy tickets if you aren't up to the task of the hard ticket. If that hard-for-you ticket is easy for someone with more skill, and we're in a high profile incident, I am going to steer you away from it. * As a manager, if you show me you can crush the easy tickets, I will find a way to guide you toward harder problems. Then, if you show you can do the harder problems, and those around you are in agreement that you are tackling those, then you have the leash to start swarming to issues. Note that you can usually prove this within 1-3 months - I'm not talking about an extensive time of paying your dues here. But make sure not to try and skip a rung.
- nosefurhairdo 2y ago
  I made this thread's root comment: this is exactly how I was managed, including the "can prove this within 1-3 months" timeline. Glad to see there are other good managers out there. It's a bit horrifying seeing the pessimism in these sorts of threads. Would strongly encourage folks in low-autonomy teams to seek other opportunities.

corytheboyd 2y ago

100% agree, you simply have to prove varied competencies repeatedly to level up. It’s very intuitive, and leading projects means guiding others to execute the varied competencies you’ve now demonstrated your understanding of.

swatcoder 2y ago

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.