system
Given the following post, respond as if you're commenting on Reddit:
human
What to do if your senior dev just got fired?

I work on a small team as a Junior/Front-End/Intern.

&#x200B;

Today the senior dev who got us the position got fired....

&#x200B;

Some of the code that gets written for our applications gets written outsource, the Back-End gets written and managed by a in house dev and they also have an algorithms dev in house. 

&#x200B;

I would like to keep my job but because we don't have a senior Front-End anymore.... So our position if we are kept would be to work underneath the outsource team or if they hire another Senior dev (I doubt it). 

&#x200B;

I have enough experience to push on without him leading the team but sometimes there are bugs I don't know how to solve and also they will be looking for a team manager to build the version 2 of their application. (they have a few applications, the one I'm working on is in a framework I know but their main app is written in a different one that I don't have much experience with). The original plan was to rebuild the main app with the framework i'm comfortable with because React is great and Angular sucks... ;) and their version 1 is a pile of unusable garbage (quoting the senior developer)

&#x200B;

Now I just want the job and am willing to learn Angular or what ever but I would like to push to use React and I would like advice on systems so that I can push code and work without occasional assistance from the senior dev. 

&#x200B;
gpt
Guess the most important thing right now is knowledge transfer. I'd suggest:

1. Fix all your bugs yourself. Do not give up and hand them over to the senior. Consult them if you are absolutely stuck but not more. Yes that's painful but it's the best way to learn all the intricate details of a system. 
2. Do not have the senior do any stories or similar on their own. Rather have the senior act as a consultant or pair programmer to someone else. 
3. Documenting processes is also very useful. We recently formed a shared team out of multiple tiny component teams and one of the things we like to do is to actually write down flows we perform for certain administrative tasks that come up regularly (in our case for instance certain setup tasks that touch multiple systems). The next time that task comes up someone else performs it based on the documented steps, which acts as a good way of reviewing if something is unclear. 

Other than that ... a lot of graduating from junior is simply "growing up" so to say - i.e. becoming more self-reliant in finding out things and becoming proactive in the whole development process (including how to set priorities).