Firstly, you got your _first_ swe job in August. Companies that hire juniors for first jobs shouldn't expect to have fully formed contributors from the gate. It's probably a year or two before you should be expected to be a reliable contributor.
I know with todays inflation in "senior" titles, it comes earlier, but personally, I have low trust in anyone who hasn't done the job for 10+ years.
As more concrete advice:
Own the fact that you are green & new. Ask the "dumb" questions. If you are unsure on how to start something, ask "what would be a sensible, concrete first outcome on the way?". Ask, ask, ask.
Also, as a junior, it is immensely valuable to pair on problems and code with more senior members. So if it's not a thing, maybe suggest if you could try pair programming from time to time in the team. It reduces bugs and errors even for very senior people.
Finally, mistakes happen. Sure, try to avoid them, but don't freak out when they happen, just find a solution to correct it. Every mistake you make is a mistake you are less likely to make again (but some of them, you will make again, and that's fine).
If you are able to do expensive mistakes on production systems, I'd suggest it's more of a process problem than a people one.
In an R&D org where this is not a thing (pair programming). Any pointers on how to get started? (mechanics wise .. who controls the keyboard? Is the senior dev supposed to be quiet unless an issue? Is there talking throughout?)
Depends:
If you work remotely, using VS Code Liveshare or IntelliJ CodeTogether (depending on tooling) works a charm.
In office environments, I once worked in a place where each workstation had two sets of mice and keyboards connected.
Main thing about pairing is communication: one person "drives", while both people talk through what they are doing/thinking. The non-typing partner can be a "map reader" of sorts, thinking ahead. It really will be different from person to person.
The benefit of remote setups with two people working the same code in their own editor is one person can run ahead and write the tests, while the other writes the implementation code (and both communicate what they're doing).
What either setup has had in my experience is constant communication between the parties.
I know with todays inflation in "senior" titles, it comes earlier, but personally, I have low trust in anyone who hasn't done the job for 10+ years.
As more concrete advice: Own the fact that you are green & new. Ask the "dumb" questions. If you are unsure on how to start something, ask "what would be a sensible, concrete first outcome on the way?". Ask, ask, ask.
Also, as a junior, it is immensely valuable to pair on problems and code with more senior members. So if it's not a thing, maybe suggest if you could try pair programming from time to time in the team. It reduces bugs and errors even for very senior people.
Finally, mistakes happen. Sure, try to avoid them, but don't freak out when they happen, just find a solution to correct it. Every mistake you make is a mistake you are less likely to make again (but some of them, you will make again, and that's fine). If you are able to do expensive mistakes on production systems, I'd suggest it's more of a process problem than a people one.