WHY DO PEOPLE ALWAYS LEAVE CLOSE TO DEADLINES???

My team exists of three developers and a product owner. By the end of the month we have to deliver two new applications. It has not been going as smoothly as we'd hoped so far. However, one of the developers has cut his time for this project from fulltime to 1-2 days a week starting this week. The other developer is also needed on another project and has to run to the rescue whenever there is a problem with the servers, so he doesn't really solve any bugs either. Also he'll be leaving straight after deadline so he has to document everything only he knows and he'll be on holiday next week. Also, the product owner leaves tomorrow and will be back after deadline.

So.. Here I am, junior developer, have been here for about three months and I have to fix everything and do the communication to our testers as well. I'm feeling too overwhelmed right now...

That moment you're actually happy a new bug is reported since you're basically out of work...

If I ask you to clarify a specific bug. I don't mean clarify everything you told me but that one. Spend 15 minutes telling him that he couldn't log in because he used an invalid username, while he kept on circling back to all kinds of other problems but that one. It's way too early to deal with this kind of crap, he literally called me when I just opened my mailbox (which is the first thing I do at work).
Doesn't help that I'm really done with the dude anyway. Not entirely his fault though, but I might post that in another rant.

So, something changed at our company not allowing me to connect with the correct network. Now this is barely a problem since I can still connect with another network, however the only thing I can't do now is push and pull from git... Every time I have to sync, I have to set up the hotspot on my phone. Apparantly, that's more often than I thought. Also, in order to work on the application I have to be connected to the company network because our application uses windows authentication, so I keep switching back and forth.

Our company has the opportunity to start moving towards a more microservices architecture approach.

There is so much technical debt that needs to be paid back, this opportunity is a godsend!

Now, of course, the whole "programming language debate" comes into play at this point.

To provide some context, we've reached the point where we need to be able to scale, and at the same time where speed and performance are also important. I would argue that scale is of more importance at this stage.

Our "dev manager" (who is really only in that position since he's the oldest, like scribbling on a notepad and the sound of his own voice) wants to use Rust, as this is a peformant language. He wants to write the service once and forget about it. (Not sure that's how programming works, but anyhoo). He's also inclined to want to prematurely optimize solutions before they're even in production.

I want to use Typescript/NodeJS as I, along with most on the team are familiar with it, to the point that we use it on a daily basis in production. Now I'm not oblivious to the fact that Rust is superior to Typescript/NodeJS, but the latter does at least scale well. Also, our team is small - like 5 people small - so we're limited in that aspect as well.

I'm with Kent Beck on this one...
1. Make it work
2. Make it right
3. Make it fast

We're currently only at step 1, moving onto step 2 now!