Sounds like you are working in a toxic environment.
Asking questions is not a crime. At most places it is welcome. Just make sure your questions are organized and not continual.
Produce a quality product.
Don’t let these people distract you. However you might want to start looking for another job.
often task descriptions are vague or straight up incorrect, and I am
expected to remember verbal discussions that directly contradict the
story descriptions. I am bad at remembering verbal things, which is
why I rely on notes and written story descriptions a lot, but they are
often unreliable as changes in requirements are not documented. I feel
Is it a sign of me being basically 'too dumb' if I still need to ask questions after almost 2 years?
Not at all. But it sounds like you're asking the wrong questions.
I asked an experienced coworker if he could give me a quick introduction.
That's beyond vague, and sounds like you haven't even tried to figure it out.
If you asked me to give you a "...
Keep this in mind: it's very common for people to do jobs without corresponding titles. This is especially true in knowledge-based professions like programming.
So, good sir, you are leading a development team. You do the technical organization tasks typically done by a "lead." You are the lead. And you have some of the frustrations all leads have:
Sounds like you need to decide which one you want more:
Become lead dev
Stop doing other people's work
Because to me they sound somewhat orthagonal. I think ask yourself if you ever see your lead dev stepping up and the likelihood of no. 2 happening.
In my experience once you set a precedent it's hard to break others expectations. At the end of the day I ...
Actually getting a Lead role while being effectively part time is going to be tricky as most companies will want you to be there full time.
That said the role you are doing (frustrations and all) is still good experience towards that goal - you won't be able to claim the title true but you will be able to talk in depth at future interviews about what you've ...
I had similar experience before. At the time, it was indeed frustrating.
But later in your career, you may find that this experience adds great value to your CV.
Take myself as an example. Because I had these "extra duties", I get to put "I lead the change of xxx in yyy company. This results in ....". And this not only differentiates you from the sea of ...
There seem to be two issues that cause you frustration, which I'd suggest are best separated:
Give your lead feedback on how his broken commits are affecting the team and suggest an alternative.
Don't compare yourself to the other lead, but ask your manager on what you need to progress in the company.
You have a very clear cut case on how ...
How to defend yourself during the "blame placing" meetings
Speak up for yourself in those meetings! Redirect the blame process (which is toxic) by pointing out that until you and your coworker sit down and carefully trace the source of the bug, it is impossible to know for sure what is causing it (it's well known that first guesses about the cause of bugs ...
As a subsidiary answer to this question - I agree with the general advice "Speak up for yourself", but you should be careful to ensure that the problem is actually in your colleague's code.
Neither of you have a vast amount of time worked and my experience (both with myself and with junior developers I have worked with) is that there is a tendency to not ...
Follow up because this is something that hits close to home to me and i feel like the current answers don't cover the most important aspect about software development.
This may not be the answer you like but in my professional experience understanding this will go a long way.
Code reviews are not just for code quality they are also for shared ...
Ask your project leader
The problem is that you are finding that your colleague is blaming you for your colleague's bugs. Your project leader is the person hearing that. How do you let your project leader know about this? Schedule a private meeting and ask what to do. You want to know
Does this matter? Is who caused a particular bug tracked in some ...
There are 2 problems here:
You have a toxic coworker. These are the kinds of people who wreck teams. If you find yourself on a team with this kind of person in the future, change teams or companies. But the real problem is:
You have a clueless manager/project lead. The Pointy Haired Boss (PHB) in charge should note that Toxic Tom is constantly pointing ...
One option is to bring up the last few incidents when he blames you the next time. Say something like "Are you sure it's my code? The last few times you said that, it turned out to be your bug. Perhaps we should get the revision history before assigning blame."
That makes it clear that you were wrongly blamed in the past, and that you think he should ...
Speak up for yourself!!
The only reason that your colleague is making you look bad is because you are allowing him to. He is making a claim in front of your manager and rather than challenging his claim you are simply doing nothing. This needs to stop. The next time that he blames you in front of your manager for a bug you need to speak up with something ...
Tricky. The key player here is the project leader and their impression of you.
If the project leader are good at reading people and situations then they will notice that you are blamed for every error and that this is unlikely to be true. If, on the other hand, they are not good at reading the situation then there is probably very little that you can do. In ...
How's the QA process in your organization? Is someone assigned to ensure that the project is free of bugs before delivery to the client. Are you two developers allocated time to perform basic testing and bug fixes?
Also, does the team maintain proper documents listing project specifications and who is responsible for which module?
Since you mentioned it's ...
Then, when I go to source code to know where the problem is, I usually find out that he was who wrote that specific piece of code (thanks to git commit history), but as it is not immediate, I cannot defend myself.
Two approaches here. If the policy is "whoever caused the bug fixes it", then you just push back:
I've investigated this issue, but it seems ...
You should confront your colleague and discuss the issue with your manager.
Ask your colleague for 30-min to catch up over coffee. Let him/her know you have some feedback to share about they way you have been working together and are open to any feedback they may have for you.
In the conversation, be direct in sharing your observations with your colleague ...
There are too many dysfunctional behaviours here that it will be hard to fix them if the other members of the company don't know how a dev company should work.
Your colleague shouldn't be in a position to blame you. As I understand, he's not your superior so he shouldn't be allowed to do so and your superiors should discourage such behaviour.
Your project ...
I usually discover that he wrote that specific piece of code (thanks
to git commit history), but as it is not inmediate, I cannot defend
In a single phrase: Your Source Control system of choice (git/tfs)
The ole saying goes the code don't lie. If you are blamed for a change you did not make, you should be able to say "well, let's look at the ...