My last feedback from my engineer manager was, I don't understand the task at work regularly and this is not an isolated incident, it takes too long for me to complete a task. When I seek for help, they point me to a direction to where to look into. After that when we meet at the second time, there is not much progress from where I left off.
It seems like I rely on my senior engineer too much, I feel like my approach was asking them for answers. I don't find it sustainable in the long term.
Obviously, I want to grow in developing my skills but whenever I get stuck, I get frustrated which add more stresses to me so I procrastinate, whether it is sleeping or playing games.
I don't have a computer science degree and come straight out of a coding bootcamp. Maybe that's where I feel lack of confidence or just feel lack of motivation in tackling difficult problems.
I am a bit lost at the moment, but I don't want to repeat this kind of behaviour.
How do I set myself up for success?
Can you bullet list the actions that you take from the time that you receive a task to the time that you meet for the second time?
You might be having a mental roadblock where you are feeling completely frozen and not sure what to do at all because the task sounds overwhelming. You might just need to do something, anything. I would start by taking 10 minutes to just summarize what you think you need to do to accomplish the task with the expectation that you could be completely wrong. The goal is to just have some path you can take and execute on rather than keeping everything in your head. When you do this, it's easy to dwell on the imagined impossibility of the task.
Once you have this path, I would have a casual conversation with your senior engineer to make sure you are on the right path.
Now, you'll have the high level idea figured out, you just need to execute.
Do you find yourself just frozen in your code editor, not sure what to do? Start by just adding log statements and trace through the code. This is better than just doing nothing. Remember that you are coding in a local environment, so you can treat it as a sandbox where nothing bad can happen.
You need to clearly define what you are trying to do. Write down the different approaches you've taken, why you think they should have worked, and why they ended up not working. Then, you can bring this to your senior engineer to try to figure out where your assumptions might have led you astray. You can categorize where your deficits are: not understanding the codebase, not understanding the programming language, etc.
It also sounds like there's a sense of imposter syndrome. Try not to get too caught up in where you are now, but try to look at where you could be in 5 years if you just get the reps in and learn a little bit more each day.
Can you keep a diary of all the questions you ask the senior engineer in the next 2 weeks? And also write down the answer you received.
Then do some reflection and ask yourself the question, "Was there anything I could have done to have answered this on my own? What resources could I have used?"
I highly recommend going through my answer here as well: How should I respond when I have no idea what a person is talking about?
Building on top of the existing advice, I'd also recommend that you start narrowing down on where you're publishing your paper trails at. Often times, if there's no visibility (no easily accessible public artifacts like comments on tickets, design docs, documented weekly updates) on what your process/progress is, your broader stakeholders will often assume the worst case scenario that you're slow and inefficient. Try to identify how you can communicate/document your progress in a more public manner: whether it's by posting regular comments in tickets, asking more clariying questions in public channels in your company's internal messaging app, or providing more granular updates in standups. This will also benefit you individually in the long term as information you've encountered in the past will be more readily available to you (and anyone else who's interested), allowing for a quicker turnaround time when you need information from the past.