Programming

Who is your PM or senior assigning the tasks? You need to take this up with them -- everyone always needs a couple of quick hits in their back pocket. When you stall out grinding on task after impossible task it kills your motivation and productivity, and that's your boss's job to fix.

You’re out here solving impossible problems. You’re “The Fixer” from Pulp Fiction. Fools look at story points. Pros see an unsolvable story that languished for years until you came along and defeated it. A single point for you is an entire epic to other teams.

Everything is a differentiator that can be spun to your advantage. The points aren’t accurate, and you’re the only one with enough guts to step up to the plate and finally work these neglected tickets; even if it won’t “look good” on some “dashboard” - that’s not what’s important; you’re here to help the organization succeed.

If the system doesn’t make you look good, you have to make yourself look good. If you weren’t putting in the effort, it would be hard - but as you say, everyone who takes a deeper look clearly sees the odds stacked against you, and how hard you’re working / the progress you’re making; despite those odds.

Don’t let some metrics dashboard decide your worth, king!

I probably can't solve your issue entirely, but if it helps, one thing I note from your post is that most of your stress seems to come from YOU trying to be too hard on yourself. Did anyone call you stupid? Yes, you did. Did anyone say that you should just quit? Yes, you did. Stop being so mean to your coworker! Yes, even/especially if that person is you!:-D

Second, to get accurate information, LISTEN to your teammates!

I get a lot of, “Wow, that’s crazy,” or, “Yeah your job does seem to have a lot of unusual blockers.”

Especially those more senior than you!

when I explain what I’m blocked by, every person has said, “Oh weird, this seems like a really confusing task.” Or, “Damn I’ve never seen anything like that.”

(emphasis added)

What they gave to you to do is on them, but how you handle it is on you. Don't stress yourself out too much.

Third, yes you got called into a meeting with a senior dev. USE that to your advantage. If you were really were stupid, this is your time to get that crucial feedback - if accurate, then better to get out now before you get too deep and find it even more difficult to change careers. However, it seems to be the case that it is NOT accurate, and that information is INCREDIBLY HELPFUL, and you may want to treat that great feedback with the value that it has instead of dismissing it?

Also, that senior dev can help you boost your skills. How many people get that opportunity? Free training, woot! Even/especially if it is not related merely to technical skills but skills on how to exist in a job environment.

Fourth, you might also want to touch base with whoever created that ticket. They might even say "oh yeah that is still there? I totally forgot about that. Nowadays that would make zero sense, ever since we implemented that XYZ thing about a year and a half back. Just ignore it and go on to something else." YOU could be the one knocking those tickets out of the park, resolving each one simply as "Won't Do" citing "owner said so". Okay, I doubt they will all be so easy, but it's a thought.

And you seemed like you needed an ego booster. Sorry, I don't know how to do that well, but the least I could do is spend some time on your issue, so that you know that you are not alone. I hope these musings help some too:-D.

If your company is using story points to “measure” developers, they are completely misusing that concept, and it probably results in a low-teamwork environment (as you describe).

The purpose of story points is so a team can say “we’re not taking more than X work for the next two weeks. Make sure it’s the important stuff.” It is a way to communicate a limit to force prioritization by the product owner.

And, in fact, data shows that point estimation so poorly converges on reality that teams may as well assign everything a “1”. The key technique is to try to make stories the same size, and to reduce variability by having the team swarm/mob to unblock stuck work.

Who creates these tasks? They need to close the year old items, reevaluate the work and break it down into sub-5-day chunks. If there are so many unknowns that it’s impossible to do that, the team needs to brainstorm how to resolve them.

It's already been said a couple times but if your more experienced team members are saying, "that's a really weird task" the issue is probably the task not you.

Having daily meetings with a senior because you're having a lot of trouble progressing isn't necessarily a bad thing. Everyone has jobs that are absolute ordeals and sometimes it's better to break them down even further and just go one step at a time.

Also, are you involved in your team sprint planning? Who says "this ticket is a 1 day job" that should be your teammates, or at least a subset of them? Why did they decide this was an easy task? What did they, or you, miss in the execution?

Story points are bullshit and I just hope it's not the sole metric you're judged on, or at least your team don't see it that way. If you do, definitely try to steal a bunch of easy tickets to even out the playfield.

How many story points can I complete? I don't know because that's a hard no for my team, but if we did, probably would not have many points either unless you assign like hundreds of points to my tickets. Some take me weeks and months to get through.

Why? Because I get assigned all the incredibly cursed tickets, and those get assigned to me for a reason: they're my kind of specialty and I'm the senior on the team with the skills to tackle them. And my performance reviews still say I exceed expectations. I complete those in record time, comparatively.

I deal with and fix things most people don't even dare to touch. It's a well known fact all the way to the CTO and other senior staff of adjacent teams. It's just, you can't break down tasks to half day tickets when all you know is there's a giant rabbit hole and you can't see how deep it is until you start digging into it. I'm the guy that can just pull out GDB and strace and debug the interpreter that runs the software. My colleagues write standard PHP/NodeJS meanwhile I go browse the PHP and V8 source code to get down deep into why things break, report and fix bugs upstream. NodeJS crashing on a SIGPIPE on a socket that's already closed? Yep, figured it out down to the exact series of syscalls that led there. Sometimes I have people from teams I never talked to reach out to me with their problems, because when you're real stuck, you go get Max's input on it.

Ultimately, you should talk about that with your manager. Is your manager happy with your performance? Does your team seem frustrated with your performance? It's very possible you get the tougher ones because people know you can handle those. If you're struggling that badly and somehow you end up with the hard tickets, your manager is dropping the ball hard and not setting you up for success.

I love coding, I hate my coding environment… Anyone else ever have this type of issue in programming?

Yeah, we all do, all the time. I swear the only reason therapists can earn so much is because of all the programmers are racing to afford them.

I would actually go talk to your manager about this. I feel you are unsure about whether the problem is:

• you always get the hardest tasks and thus seem incompetent among the others, or
• you actually can't finish tasks that others would be able to, they are just too nice to tell you.

If it's the first, then your manager should help ease the load, or at least you could get recognized for your efforts for doing the heavy lifting for the team. If it's the second, your manager will still be able to tell you that, and then at least you know you actually need to git gud.

all my tasks were opened years ago, remained open for months or years, then were assigned to me

That says to me, it's the first. I'd ask people when something like that gets assigned to me; what changed that makes it possible to close this that wasn't true in the past years? Or why don't we close it with a "won't fix", since nobody seems to have missed the thing for years?

That said, there are three things I'd like to say to that:

First, story points are not for you to obsess over on how many you can complete in a sprint. They are also not there to compare people to each other. They are solely to try to guesstimate how long something is going to take, so that the PM is not flying completely blind. If a task really was estimated at some points, then the team agrees you were justified in taking a lot longer, then the team fucked up with estimating. If that's consistent, then the team should have a conversation about why their estimates are off.

Second, yeah, the job market sucks now, that's also not on you. Try to obsess less about your work. I know it's really hard to do so, and I've gone through a bunch of experiences myself where I got closer and closer to burning out. Try to find something other than work to obsess over, that helped me a bit. I know it's hard. I've failed to do so many times already. If you are worried about your career, just know that every day you spend biding your time at the current place makes you worth more in a better market to come.

Lastly, it will get easier later on. I sucked a lot during my first few years. You learn through the suckitude. That's what you're there for. You will be able to solve these later in your career. These issues, not the code or the tricky bugs are the ones that need experience.

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.

i took french for 5 years. i cannot speak french. i love the language, and i try.. but i could never become fluent like my classmates.

i dont know what the answer is for you, but maybe, you need to switch gears to something programming-related instead of hands on coding.