Programming

If you're trying to pull your weight, and it sounds like you are, the problem is either with the tasks, the codebase, or the teammates:

Potential problems with the tasks:

• they're not researched sufficiently
  • is this doable?
  • should we we even be doing this?
  • have we actually thought about how hard this will be, or did someone say "well that should be trivial" a bunch?
• there's not enough info on the tickets
  • inexperienced leads tend to just shit out tickets with zero info and underpoint them
• they're not broken down into small enough pieces
  • are you working "implement X" tickets while everyone else is working a series of "implement X: step N" tickets?

A ticket needs: clear repro documents (if necessary), screenshots, and clear steps to reproduce. It needs more than "Title: Add X to Y. Description: We need Y in X. Implement it." unless you're intimately familiar with the codebase. And even if you are, you still need a paper trail to back up what you're doing. If you're not closing tickets, be very chatty in the comments. Share where you are, problems you're running into, and who you're waiting on for help. If there's a consistent theme to the things you're fighting, keep a list of them and bring them to your manager. Be your own advocate and be very transparent about all the research you're doing because other people didn't.

Potential problems with the codebase:

• someone preemptively optimized it
• it's not documented well
• it's spidery bullshit code that someone has deep emotional attachment to

Hey, it works. But it's not documented, someone decided to be clever instead of elegant, the local story sucks, or it's optimized to such a degree that you have to refactor just to add a simple option ("lol why would we ever need that data here? It's inefficient!)

Potential problems with teammates:

• they're not supporting you
• they're grabbing easy tasks because you're the "code whisperer"
• they didn't know what they were doing either so they're vague when you ask them questions

Everyone pulls their weight. Everyone communicates in clear, declarative sentences and provides examples if necessary. "I don't know" is an acceptable answer. Evasiveness, vagueness, specialized jargon, or acronyms point to the dev being insecure about their knowledge in that area. Be very suspicious of the word "should": "that should work", "that shouldn't be hard", "you should be able to...."

And, as an aside, I've seen this happen a lot. A new dev or contractor comes on, blows through tickets, gets good marks, and an existing dev or two get called out for not contributing with the same frequency. One of two things are happening here: the new devs are getting softballs, or they're creating a lot of subtle tech debt that someone else will have to fix because they don't have a full picture of the codebase. Eventually, those devs will be where everyone else is, but it's still frustrating.

Hang in there.