Edit : I appreciate all the PoVs and I will reply to everyone. This is important to me. Just going to go rest a bit and I’ll be back.
Edit : Leaving the self-insulting language in, but yeah… Point taken, I should stop being so mean to myself. And to add another FYI, I’ve been on this codebase for about 3 months, which I probably should have mentioned.
I have no idea what is wrong with me. I get tasks, I work on them, they NEVER seem to close. Meanwhile everyone around me is left and right solving their issues. I reach out for a second opinion because I must just be stupid, and every time I reach out the person is never able to assist in any meaningful way.
It’s like my tasks always have blockers that everyone around me seems perplexed by, I get a lot of, “Wow, that’s crazy,” or, “Yeah your job does seem to have a lot of unusual blockers.”
I’m at the point where I’m in a daily meeting where I explain what I’m working on to a senior dev because obviously they noticed I’m a person on the team with sometimes zero points in a whole month. It’s so discouraging to have to go to a daily meeting because apparently I’m stupid? The thing is, 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.”
So obviously I look at other peoples’ tasks… what are they working on? And their tasks are SO simple and straightforward, yet I’ve NEVER had a task like that, all my tasks were opened years ago, remained open for months or years, then were assigned to me. And they’re all fucky. Wth.
Tbh I’m running out of things to write because I don’t want to justify it, because I feel like I should be doing better. What the hell is wrong with me?
I have wanted to change jobs for close to two years now… but you’ve all interacted with recruiters… they never help, and job search is impossible as a person with anxiety and possibly autism?
I love coding, I hate my coding environment… Anyone else ever have this type of issue in 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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
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:
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:
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:
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.