Having gone through this stage myself and now mentoring others going through the same thing, I think it is an inevitable part of learning to code. A few pieces of advice:

- The first key is to keep trying -- it WILL get easier and become second nature. Problems that once challenged you will become trivial as you develop a personal bag of tricks and reusable code, and generally "level up".

- Become opinionated -- decide for yourself what programming languages/paradigms/methods will solve problems the quickest (and correctly), because that's what bosses care about. Maintainability and "best practices" CAN be important, but it depends on the exact industry and type of code you're writing. Each paradigm has something to offer, but not all paradigms fit all programming styles. You will need to try several different languages to achieve this. I would venture that it is almost impossible to be a good programmer without writing a substantial program in at least a half-dozen languages.

- Find a mentor. Ask them how they think you should proceed when you get stuck, ask them about what aspects of your code need improvement, and listen. If it is your boss, and they have the programming expertise, they will almost certainly be glad to help, because it will make you more productive. Otherwise, a friendly and experienced coworker.

- Code on the side. Lots of people want to work 9-5, but you will unfortunately not be competitive in this field if you do. Pick side projects that are fun and challenging. Volunteer patches on a OSS project, or find a nonprofit to do (challenging and interesting, not "can you build our website?") work for. If you want to, these side projects can also be for your job, but don't feel obligated to do this.

- Build a personal library of reusable code and algorithms suitable for your field. For example, mine is bioinformatics, and I have amassed over the years a toolbox of scripts and algorithms in various languages. I can then string together my code to solve a problem in one line of bash that would be hundreds of LOC if developed de novo. Put a lot of effort into documenting and generalizing this library (but also don't re-invent the wheel, use external packages when they exist).

- Familiarize yourself with critical relevant libraries in your field and language of choice. For example, in Python, this could be numpy, pandas, scikit-learn -- packages that have broad applicability. If you need statistics or linear algebra, learn it (for me, the best way to learn these abstract subjects is by using them -- implementing a statistics method or linear algebra-based algorithm by reading a paper and translating the equations into code).

EDIT: one final point that is very important:

- Realize that the purpose of programming is to solve a problem, NOT to write code. If you can find a simple way to solve a pain point for your boss or stakeholder, that is far better than writing hundreds of LOC. Sometimes this can even take the form of explaining to them why a certain feature they have requested is actually a bad idea. Somewhere along the hierarchy above you, there is a person who does not know how to code, and only cares about results. Always be asking yourself: how do I make this person happy with a minimum of effort?