People do stupid cowboy shit in big tech companies all the time. Sure, in theory you should have the resources and workforce to have a stable production pipeline, but in reality you're often understaffed and underfunded trying to meet unreasonable deadlines from retard suits. Sometimes you don't have time to wait for Rajneesh in DevOps to get off his lazy ass and do it the right way, so you just say fuck it and ram it in, because you know what you're doing and you're willing to take the risk in the name of getting shit done.
I'll admit it, there is something cathartic about doing cowboy shit especially it it's a product that has been terrible to work on, you feel as it you're finally putting the last nail on the coffin of this shitshow of a project, or at least it is in my experience. But experience has also taught that just because you might know what you're doing but that doesn't mean that the other people working on the project knew what they were doing and it can happen that you deploy unfinished or broken stuff that either QA missed or the suits wanted deployed no matter what. That usually meant that I had to stay until late or work on weekends either reverting all the changes or patching what was broken because the deadline was tomorrow or on Monday. Years later I realized I could just say: "Deployment? Yeah, I'll check it out tomorrow" or "Deploy it? Sure, I'll do that on Monday", and the suits or management couldn't do anything about it because no one else was willing to do the cowboy shit. Every time they whined about the deadline or the client, I would always suggest to set up the proper production pipeline and make sure that QA did their jobs, so we could prevent this situation again. After a couple of years, tt eventually worked as we did set up a proper pipeline and QA became more methodical and more competent, it was nice seeing your efforts finally paying off.
That's not exactly how it is. It completely differs between software solutions & hardware ones
For example, no amount of technical knowledge will compensate you the lack of 3rd party relays of business data for testing environments, especially when you dealing with realtime stuff (running vehicle sensors' data for example). Obviously you can invent a wheel and route data from prod to test environments, but it opens the whole set of other issues, you don't really wanna to setup one more shiny cluster to test 1/1000 of functionality, readjust all the data so it conforms to production. It's faster to test on prod. Obviously, it depends on the component and how the solution built, but if it's something that doesn't put your system on any downtime, I don't see any problem testing on prod
I should have made it more clear that there clear exceptions when testing in production is valid and even expected. A valid example is like you say, receiving and/or sending data in realtime, that while absolutely possible to set up possible test environment to iron out most the bugs but some will only show up in production, such as reconnection failures, loss of data, scalability issues, amongst other possible problems.
Regarding networking stuff, network engineers build the solution on prod hardware from ground up, nobody builds a testing stand for 50 floor business center, or giant airport, because of how expensive hardware is in the first place. So testing in prod for network engineer is a must-have at all times, and that's what they do 99% of their time - fixing client configurations. Also worth mentioning networking is one of the fields where certification actually does mean a lot, so they are prepared for this shit
I should have also clarified that I was giving my take from a point of view of software development, not so much from a network engineer, which I admit my experience is quite limited and bit rusty since my first job (sorry for the PL) where I was the designated "network engineer", on the mere qualification that was I the only one willing to give it a shot (But I didn't really knew much about it, I figured I'll learn on the job) and mess with stuff (It was a very small company, 5 people and that was including me). It usually involved making sure our computers and servers could communicate with each other, set up the static IP config for the servers, that sort of basic stuff. I was lucky that my boss had more money than common sense and had acquired, mostly second hand, hardware that I could try stuff without breaking the main network, mostly.