Hacker News Reader

Comment by nosefurhairdo | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

Which reminds me of a previous discussion: Don't do easy things

https://news.ycombinator.com/item?id=27988260

> 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”.

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.

But only to a mid level developer.

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

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.

Reply on news.ycombinator.com