I had a similar experience when I first started out and I got fired from my first two development jobs so maybe my experience can help you.
Getting good at grocking through existing codebases is an experience thing I feel. You need to understand the frameworks and libraries used, as well as understand the underlying business use cases. You can look through open source projects or build small example projects with the libraries in question to help you with understanding their code bases.
Understanding a code base is like understanding most other things. If you don't have an understanding of most of the background things, then you don't even know where you're struggling. It's like jumping into a book about quantum mechanics when you don't even know Algebra. You need to learn about the backend they use, the frontend stuff they use, and the business cases. I know that's a re-iteration of what I said above but sometimes having something explained from two ways helps.
As for the meetings and such, I think it is partially the above as well. I know when I first started out, not understanding the business, and the goals of the business, as well as what is in the code base already, nor what can be done in the code base, made the meetings hard. You don't know what they are talking about, why they are talking about it, and can't contribute due to lack of understanding. This makes it boring, like attending a lecture so high above your understanding that it's almost pointless to be there.
If this sounds like a likely scenario, then you just have to study and study and study. Also be honest with your co-workers and manager. Most of the time in my experience if you can identify the problem, figure out a path to fix it, and explain to your manager, they will be on board. Especially if you show that you are working to fix it. Always be introspective about the problems, and never be afraid to look dumb by asking questions. Also maybe confide in another coworker first about your problem if that feels more comfortable than your manager.
Lastly, I know that I had lots of these problems when I had an alcohol problem and drank WAY too much everyday. It made me sleepy in meetings, hard to think about problems, hard to understand new things, and just lots of other things. If you find yourself drinking a lot, perhaps consider doing a month of no drinking to see how that affects things. (I know you didn't mention drinking anywhere but I thought I'd say something just in case)
If you have questions or things just reply! Also maybe look at dev.to as well as they are a more junior community with a softer touch than here and may have lots of advice from people closer to your level or different perspectives that will help!
Thank you for your answer. I got fired from my two last development jobs too.
I didn't like the first place, I haven't got too much help to even onboard, not talking about learning the codebase or the framework. (One thing I will never ever do again is trying to learn a completely different framework at a new job...)
At the second place however I felt I was pretty good. They mentioned areas to improve (productivity, meetings), but most of the feedbacks were good. Then they fired me. They "expected more improvement".
What is the mistake I shouldn't make again? Am I a bad developer, having problems or just unlucky?
I think the second place might have been a bit of bad luck, bit of not reading between the lines. It sounds like you can code well enough and your co-workers like you if you got positive feedback except for productivity and meeting issues which sounds like you're a good developer, but maybe have issues as an employee.
Are you currently employed and if so is your current place complaining, and if so is it the same things? I know after having been fired I get a bit of anxiety just thinking about those kinds of things even if I am doing well.
As others said on the falling asleep thing, do ask a doctor about it, you may have an attention disorder or sleep disorder.
Also do you participate in the meetings? If not, why? I found if its a meeting I don't need to be in, or can't participate in then its harder to focus and stay awake.
I also find that I am not good at 'using' my ears. I had trouble learning by listening when I was in class, and also by listening in meetings, I need to read something to have a chance at following along often. If you have a similar thing, ask if they can provide some notes or info about the meeting so you can prepare better. That may help.
I find on productivity, making sub-tasks for the day helps a lot. Something like:
* send email about x
* ask Y about Z
* look into A for project B
* do ticket D
* fix issues from PR for ticket Q
* do PRs for persan M and N
and then I just do those as well as I can each day and break them down into smaller tasks if need be. I don't care if I don't finish them really unless it happens a lot, and I add new things as they come up. I also normally make that list in Slack to myself so I can access it wherever I need to. This will give you a good baseline of where you are in terms of daily productivity. Also be sure that if you're doing a whole bunch of non-dev tasks, and they are measuring you on dev tasks, to talk to your manager about it. That's not fair or they be unaware of all the non-dev tasks.
But it sounds like the commonalities that happened in both jobs were not producing enough, and also sleeping or not being attentive in meetings. Work out why those are and fix those.
Getting good at grocking through existing codebases is an experience thing I feel. You need to understand the frameworks and libraries used, as well as understand the underlying business use cases. You can look through open source projects or build small example projects with the libraries in question to help you with understanding their code bases.
Understanding a code base is like understanding most other things. If you don't have an understanding of most of the background things, then you don't even know where you're struggling. It's like jumping into a book about quantum mechanics when you don't even know Algebra. You need to learn about the backend they use, the frontend stuff they use, and the business cases. I know that's a re-iteration of what I said above but sometimes having something explained from two ways helps.
As for the meetings and such, I think it is partially the above as well. I know when I first started out, not understanding the business, and the goals of the business, as well as what is in the code base already, nor what can be done in the code base, made the meetings hard. You don't know what they are talking about, why they are talking about it, and can't contribute due to lack of understanding. This makes it boring, like attending a lecture so high above your understanding that it's almost pointless to be there.
If this sounds like a likely scenario, then you just have to study and study and study. Also be honest with your co-workers and manager. Most of the time in my experience if you can identify the problem, figure out a path to fix it, and explain to your manager, they will be on board. Especially if you show that you are working to fix it. Always be introspective about the problems, and never be afraid to look dumb by asking questions. Also maybe confide in another coworker first about your problem if that feels more comfortable than your manager.
Lastly, I know that I had lots of these problems when I had an alcohol problem and drank WAY too much everyday. It made me sleepy in meetings, hard to think about problems, hard to understand new things, and just lots of other things. If you find yourself drinking a lot, perhaps consider doing a month of no drinking to see how that affects things. (I know you didn't mention drinking anywhere but I thought I'd say something just in case)
If you have questions or things just reply! Also maybe look at dev.to as well as they are a more junior community with a softer touch than here and may have lots of advice from people closer to your level or different perspectives that will help!
Good luck!