> I have identified some issues. I certainly didn't ask enough questions when I started and I definitely will wait around for people to get back to me sometimes rather then be proactive. I also tend to spend too long tackling an issue or trying to fix something I think I messed up rather than raise it to the team that I am having an issue.
Definitely good that you recognize this. That's the hardest part. Your next step is to fix it.
------------------------------------
> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.
It's never too late to ask dumb questions. Especially if these certain processes are your first time really working with them. Sometimes that happens, you get used to working around a knowledge gap. You're new, it happens. Not all senior engineers will quite get it. Is there someone else on the team you have a better rapport with? Show that you're taking initiative and making improvements and you'll get results.
That being said, some companies have a poor engineering culture, where you won't get the right feedback. IMO the worst part about being new is not knowing how to recognize a good team from a 'bad' team as easily. You said that the team wasn't bad, but you don't really know for sure. I don't know if this is really what you should be thinking about in this situation at all, even if you have your mind made up on whether the team is good or not. If it does become a distraction, the book "Extreme Ownership" can help a lot with having an internally focused mindset, which helps a lot in this profession.
------------------------------------
> Its hard to imagine anyone who is good at engineering delaying a teams release and causing problems.
This can and does happen even from good, experienced engineers.
------------------------------------
> I know I should just focus on improvement, but I am not sure how.
When I was new to software development, I had to spend a LOT of my free personal time improving my skills, working on side projects of my own (even though they never got finished, it helped). I have no doubt that if I didn't do that, I would have not been successful. Those side projects can really accelerate your improvement. Just make sure it uses the same technologies you use at your job since your goal is to improve at the job itself.
------------------------------------
> Should I be writing reminders to myself to always double check everything? Should I write down the steps to every process?
IMHO if you use a note taking app/methodology that is frictionless, you won't need to really think of "should I write down x" as a decision, you'll just do it when needed. Try using some of your personal time to research note taking apps till you find one that works best for you. I personally like Obsidian, it was a game changer for me and it only was recently made available. An app like that can also help you take notes on advice given in this thread ;)
------------------------------------
> Its hard for me to know whats a junior engineer error and whats an error I shouldn't be making at all.
IMO, don't stress over that. Just do what you can. When you know you've made a mistake, learn from it, maybe even write about it if you want to really cement that knowledge. Are there parts of your system that are easier to work with than others? Can you find a way to add value to your product through focusing on those parts? Some systems are just built in a way that is not easy to work with as a junior.
------------------------------------
How good is your sleep quality? Are you out of shape physically or have a poor diet? Do you have uncontrolled ADHD or depression? Things like that can make or break your problem solving ability in subtle (or not so subtle) ways. Don't overthink it, but don't ignore it.
I am also curious what languages/tech you are working with?
Definitely good that you recognize this. That's the hardest part. Your next step is to fix it.
------------------------------------
> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.
It's never too late to ask dumb questions. Especially if these certain processes are your first time really working with them. Sometimes that happens, you get used to working around a knowledge gap. You're new, it happens. Not all senior engineers will quite get it. Is there someone else on the team you have a better rapport with? Show that you're taking initiative and making improvements and you'll get results.
That being said, some companies have a poor engineering culture, where you won't get the right feedback. IMO the worst part about being new is not knowing how to recognize a good team from a 'bad' team as easily. You said that the team wasn't bad, but you don't really know for sure. I don't know if this is really what you should be thinking about in this situation at all, even if you have your mind made up on whether the team is good or not. If it does become a distraction, the book "Extreme Ownership" can help a lot with having an internally focused mindset, which helps a lot in this profession.
------------------------------------
> Its hard to imagine anyone who is good at engineering delaying a teams release and causing problems.
This can and does happen even from good, experienced engineers.
------------------------------------
> I know I should just focus on improvement, but I am not sure how.
When I was new to software development, I had to spend a LOT of my free personal time improving my skills, working on side projects of my own (even though they never got finished, it helped). I have no doubt that if I didn't do that, I would have not been successful. Those side projects can really accelerate your improvement. Just make sure it uses the same technologies you use at your job since your goal is to improve at the job itself.
------------------------------------
> Should I be writing reminders to myself to always double check everything? Should I write down the steps to every process?
IMHO if you use a note taking app/methodology that is frictionless, you won't need to really think of "should I write down x" as a decision, you'll just do it when needed. Try using some of your personal time to research note taking apps till you find one that works best for you. I personally like Obsidian, it was a game changer for me and it only was recently made available. An app like that can also help you take notes on advice given in this thread ;)
------------------------------------
> Its hard for me to know whats a junior engineer error and whats an error I shouldn't be making at all.
IMO, don't stress over that. Just do what you can. When you know you've made a mistake, learn from it, maybe even write about it if you want to really cement that knowledge. Are there parts of your system that are easier to work with than others? Can you find a way to add value to your product through focusing on those parts? Some systems are just built in a way that is not easy to work with as a junior.
------------------------------------
How good is your sleep quality? Are you out of shape physically or have a poor diet? Do you have uncontrolled ADHD or depression? Things like that can make or break your problem solving ability in subtle (or not so subtle) ways. Don't overthink it, but don't ignore it.
I am also curious what languages/tech you are working with?