In contrast to some of the other commenters here, I mostly agree with the points made in the post. However, I will argue that it's very much possible to end up

In contrast to some of the other commenters here, I mostly agree with the points made in the post. However, I will argue that it's very much possible to end up in environments where even these suggestions are infeasible, for a plethora of reasons. > For example, instead of trusting that programmers won’t push to the master branch, the repository owner can enable an automatic rejection for any attempts to push directly to the master branch, except through a pull request. This is a great example of a common practice that prevents potential problems. Programmers may not want to push to the master branch, but they could do it accidentally, as they are only human. I have personally caught myself doing this at times. Even outside of pushback ("pull requests introduce friction") someone could hypothetically just turn the functionality off, limiting access to that may or may not be possible with the tier of SCM solution that you manage. Even if it's possible, then you might find yourself seeing people create pull requests that they themselves approve/merge, for a concrete example: https://docs.gitlab.com/ee/user/project/merge_requests/approvals/ https://docs.gitlab.com/ee/user/project/merge_requests/appro... Want to make those mandatory? Suddenly your org needs the paid version of GitLab. Guess that's not happening because at that point you're not up against just resistance from some developers, but against the org itself which would have to fork out a bunch of money and you'd need to justify it, while having few/no people backing you up. > Improve workflows, not individuals. Make the process the lever to apply effort. Identify problems that occur systematically, introduce processes to resolve them, and prioritize process over people. Processes work like tests in programming. When you find a bug, it’s not enough to just fix it because the same bug could appear next week when someone else makes changes to the code. To properly fix a bug, the programmer must add a test to ensure the issue will caught if it will reproduce again. Sometimes people just don't care about the idea of improving the processes, because they see it as additional work that they don't benefit from themselves. Even linking together pull requests with the source control (because, again, you couldn't get an integration between GitLab/Jira working for the same reasons as above), things like adding basic documentation to the code to explain why it works a certain way ("code should be self-documenting" ignoring the fact that you lose the context of the requirements, because it only explains WHAT not WHY), things like adding examples of front end components to a playbook so others can re-use them (they'll just create ones needed for their own bit of the codebase in some package, so you'll eventually end up with dozens of duplicates), or even having helpful README and onboarding files. The same with tests: suddenly you're up against a codebase that's actually hard to test, in addition to sometimes needing to mock complex webs of service patterns and logic that just goes all over the place. Writing tests might take you 2-5x more time than the actual code and that'd raise eyebrows - you're basically fighting a losing battle. > Make decisions based solely on written conversations, with an overview of all possible solutions, including all known positive and negative aspects of each. This is nice and good, but many will prefer to argue in bad faith and expect you to do everything "their way" even when it's objectively harmful to the codebase (e.g. wanting to fail fast even when that means having a field with no data, that's only used for display, break the entire form and preven the user from seeing anything at all, and saying that the input data should always be good and that you shouldn't add error handling from recoverable states or fail/degrade gracefully). You can document all of the facts in the world, they'll just shift the burden of proof on you, disagree with everything you say and you'll get nothing done, holding up releases and making you look bad. > Require material evidence, like measurements, to support any statement. They won't care. I've had cases where a page needs like 4000 SQL queries to render and people still argued that the code is readable and easier to work with in the way how it was written (it wasn't) as opposed to just a few queries against a bunch of views. I showed how the performance was measurably worse and also how rewriting that code helped, but in other places in the system the same patterns are used by them. > Set strict rules for linters to ban most dangerous language features and force programmers to write boring and obvious code. If you enable rules a few years into a project, you'll get hundreds if not thousands of errors, only some of which will be fixable automatically. Then, suddenly the burden of ensuring that all of the refactored code works like the old code (it won't) is on you and you're basically shooting yourself in the foot. All while people will come up with all sorts of rules for how code should be formatted in pull requests, of course, all to be done manually, no code generation for common patterns across the codebase, just a lot of busywork. I've literally had a case in the past where the codebase had a bunch of index.js files in the modules with basically nothing else in them. It'd be like "some-module/index.js" and that's it. Clearly that broke code search, since you could find nothing by the name of a file and when you were looking at where certain code is located it'd alway show that "index.js". So, I made a script that took the code, renamed the cases with single file modules into files that are named like the module, e.g. "some-module.js", updated the imports, added a prebuild script to warn about cases like that in the future and prevent that type of code from being added because the CI pipeline would then fail. It worked. It improved the navigability of the codebase. There were no downsides to that. You know what happened? A few weeks later I saw a bunch of index.js files again, with the checks removed from the codebase, with no discussions about that and no concrete arguments about why using index.js everywhere is better. It's like people hate the idea of tooling and automation, not that writing your own custom plugin for a JetBrains IDE is easy, either. > Once, we had performance issues due to unnecessary re-renders in a complex React project. Our investigation revealed that the problem was related to memoization, a fairly common issue. One of the solutions was to introduce a rule to memoize everything returned by hooks, to automatically prevent future problems with memoization. This idea was straightforward, simple, and stupid (that is good). However, we had a long discussion with one programmer who insisted it was a bad idea because of "premature optimization", the fact that React docs does not have recommendations about it, and "nobody does it that way". In my opinion, this was a clear case of a programmer resisting the system approach because he wanted to spend time fixing the same problems over and over and pretend to be working hard. If you have the authority to enforce decisions, then go ahead. If you don't, then there's often nothing you can do, especially if people pull rank. Realistically, you either get lucky to work on a project from day 1, you manage to work with a team that has views that are similar to your own (whether that's using containers for most things, or shipping by copying directly to prod from your workstation through SFTP; whatever, the main thing is your opinions match), or you're out of luck. I've honestly considered quitting places in the past due to this exact reason.