Some hard lesson's i've realized while working in "professional" environments:
1. You must earn respect before you trash the system, no matter how shitty their code is or lack of tests. It's usually best to start by "doing your job"- whether that's issues assigned to you or bug fixes; you are at the bottom of the totem pole right now. Once you're "respected", implementing better solutions will be a lot easier.
2. Excuses for why shitty code is in production are probably legitimate excuses; a company that makes profit on a SaaS product needs to launch and iterate quickly. Product managers/sales/marketing do not care about your unit tests. Your users also don't care about your unit tests. Unfortunately this is a dilemma that's hard to swallow, because when things break, it comes back around.
You have to realize a team that's been there before you has done things in certain ways for certain reasons- whether that's good or bad, you must adapt to it before you go king kong on their shit.
Or you can just start your own company and make your own rules.
1. You must earn respect before you trash the system, no matter how shitty their code is or lack of tests. It's usually best to start by "doing your job"- whether that's issues assigned to you or bug fixes; you are at the bottom of the totem pole right now. Once you're "respected", implementing better solutions will be a lot easier.
2. Excuses for why shitty code is in production are probably legitimate excuses; a company that makes profit on a SaaS product needs to launch and iterate quickly. Product managers/sales/marketing do not care about your unit tests. Your users also don't care about your unit tests. Unfortunately this is a dilemma that's hard to swallow, because when things break, it comes back around.
You have to realize a team that's been there before you has done things in certain ways for certain reasons- whether that's good or bad, you must adapt to it before you go king kong on their shit.
Or you can just start your own company and make your own rules.