As with anything in Software, there's a tradeoff. "Code Quality" and processes have tradeoffs around risk, i.e. is this going to break something in prod? If it

As with anything in Software, there's a tradeoff. "Code Quality" and processes have tradeoffs around risk, i.e. is this going to break something in prod? If it's a real small startup (< 10), and you're pre-revenue or there's a bunch of emergency situations, then yes, a lot of what you're describing is normal. Things are crazy, and you have to cut corners to even make money. If it's bigger than that, then you've got a problem and you should start looking elsewhere or attempt to change the company from within (hard to do unless you're in leadership). Otherwise, here's my personal rules for "running scrappy": - Pushing to master & prod w/o review is fine if it's truly an emergency or something super tiny, i.e. a whitespace change. Otherwise, it's good to get in the habit of putting up a PR, even for posterity. - Connecting to prod dbs - never do this unless it's something you have to fix right now. Otherwise, just grab a copy, a backup, or connect to an idle follower instance if you need prod data (v ez to setup). - Bad code is fine. You have to pick & choose your battles. Ideally care about stuff that's around building a mental model of your application rather than quibbling around refactoring some small function - Similar note about testing... you can get away without it in a bunch of cases, especially if the app is easy to QA locally - Deployments.... just use Heroku :-) - It's good to spend at least a little time architecting/designing, but seriously time-box it and run with what you've got - Staging environment.... you won't have a good one for a long time :-)