My suggestion is to do more design work up front before touching code. Write up a plan in a drive document or an internal wiki tool, with a focus on capturing requirements, a high level description of your proposed solution, and detailed sections on the portions you anticipate to be complicated, controversial, or risky. Also include an "alternatives" section where you very briefly summarize technical approaches that you considered but ruled out.

That captures most of the high-value engineering work necessary to solve the problem, and you can move faster, unencumbered by programming languages, linters and toolchains because you're using freeform human communication. That document is allowed to be ugly.

Once you have an initial idea down, even if you don't like it yet, pass it around to your coworkers. Ask them for feedback on the design, especially the requirements, and ask them to help you brainstorm solutions to the parts you don't like. Your coworkers are going to naturally approach your document with a positive, progressive mindset. There's no risk of breaking things or stepping on toes. Chances are there will be design decisions they don't like, or have better ideas for how to do it. Since it's a freeform document, you can quickly rewrite stuff and tweak it until everyone's happy, or you can at least have the tough conversations to reach a compromise.

Once your coworkers have had a chance to provide feedback, then is the time to write code. Since you did that up-front work, you should be able to barf out the code 10x faster. You could even hand it off to someone else like an intern to barf out the code.

When the code goes through code review, it's your coworkers' jobs to be in a very conservative mindset, looking for regressions and maintenance pitfalls. You'll likely have a very different experience, though, because the code is now the manifestation of a previously agreed upon plan. It's simply an artifact. The lines of code are "cattle" to be slaughtered and consumed rather than "pets".