From my experience, any time a project isn’t on time, something like this happens from someone up high. And guess what? They are rarely “on time”. The solution is adjusting the definition of “on time”, whether it is cutting the scope of the project, better estimation, or conveying the scope and velocity during the project. Usually this falls on senior/leads/management, but it is a good skill to learn as a junior.
Don’t sweat it. The real world sometimes recognizes your effort, and sometimes beats you down and gaslights. You know the effort you put in, and that’s what matters. Get experience, and if it continues, hop somewhere else after a year or two. Get a nice pay bump. Win-win.
Agreed, 100%. I would be beyond livid if a coworker did this to me if I were the original committer. OP does not realize the insane level of mistrust he just created with this action.
Blindly checking out code late at night, without PR review, without discussion about context, overwriting approved and (I assume) tested changes, for code you did not write and were not included on review for, BLINDLY merging to master (!?) - this could be tantamount to a fire able offense depending on where you work. I would have a hard, long talk with any of my mid or junior engineers if this was attempted (although master should ideally be protected, preventing this scenario unless OP had administrative senior permissions on the code base).
All around a mess. I agree with the sentiment (write clean code unless you shouldn’t) but there is some serious process issues here that should be caught and corrected and would have made this entire issue something during the PR review phase, where OP presumably asks for an improvement and is answered with the context for the decision. Not to mention the red flag of “I know better than my peers” attitude of many programmers I have known in the past, leading to distrust and backstabbing. It can get ugly.