Double down. You enjoy the realization of creation but not the act itself. You like the view from the top of the mountain but you hate hiking.

Either come to terms with the hiking part, or resign yourself to only seeing pictures of the mountain top.

The third route is to simplify the workflow required to get to the final realization of creation but that tends to be a magnitude more difficult than the typical act of creation.

As someone who has been working on just that in a parallel field (animated filmmaking) for a couple of decades now, can confirm. :)

First, there is product design. That is not just 'make this font look pretty', it is doing things like figuring out sane workflows for your user, watching them use the product and figuring out elegant solutions to the points where they get stuck or frustrated. It's conversations with the engineers - your design might eat batteries, or render poorly on device X, or.... There is coming up with the product idea, presenting it to investors (who could just be the VP in the company you work for, there is plenty of chances for creativity w/o starting your own company). There is product management, project management. There is the whole personnel side of things. It's not just 'fill out this form for the yearly review' - a good manager has a mental model of their employees, and guides them through constant improvement. She also makes it possible for that employee to do their job by removing everything extraneous to that job.

I'm just saying HN can give you a skewed perspective. I have solely invented a few different products while working for large companies and had my companies decide to adopt them. The only two things missing was the payoff at the end, and the stress filled nights (am I going to make payroll? John just bought a new house). For me that is a great tradeoff. For others, I can't say.

And I'll say this. People like Jony Ive didn't become great by running off and doing their own things alone. It's a path to do that, to be sure. But he spent years grinding at a growing company. His story is different than yours, I'm not trying to say there is an equivalence. But you have to work really, really hard, for years, for your ideas and designs to be worthy of the world, to be better than the competition. He became great by years of grinding, and his work was made sellable by daily, relentless meetings where every decision was torn apart by other brilliant people (say what you want about Jobs, he knew how to get great work out of designers).

There seems to exist a difference between someone who codes for the sake of coding (perhaps it relaxes the mind?) and someone who codes to make other things.

As the other guys have mentioned, there's a lot of valuable nuggets of info you should look into.

I especially liked the part about seeing coding as a means. Code to get somewhere, and if you find a tool that is better and more convenient than writing code, use that instead.

There is actually a school of thought (hopefully I'm not alone in this) that sometimes sees writing code as a matter of no progress. For the last 60 odd years (or more) people have been "writing code" and it makes you wonder why this is still so necessary for the "basic" stuff we try to do.

For example: Why do we need to write and re-write code to build the internal CRUD business applications?

You should also consider taking up another hobby to relax your mind from coding (especially if you don't enjoy it), otherwise the worry about it will just fatigue you physically and mentally.

A google talk: https://www.youtube.com/watch?v=0SARbwvhupQ

If there are teams sitting around discussing patterns then they aren't focused on what they should be in the first place. They should be focusing incessantly on implementing the requirements to meet the needs of the business and ultimately the customers.

5 decades of code was written and a lot of it still in production before the GoF (Gang of Four) got together to write down their musings.

Most of the patterns I've studied are so abstract as to be completely useless in applying to the art of implementing the requirements to meet the needs of the business and ultimately the customers.

Mind you, it's a tool I'm very good with, and that I get intrinsic enjoyment from when using it. But I don't do it 24/7, and I also get intrinsic enjoyment from woodworking, soldering, cooking...

Some people are invested in getting you to believe a narrative where coders code, all the time, 80 hours a week even if you don't pay them, like they're one-dimensional widgets instead of people. If anyone tries to feed you that line, I'd take a good hard think about why.

In general, just because you're passionate about something doesn't mean you'll particularly enjoy a day job in that field - just ask all the people who were passionate about doing science, but have quit their phd programs.

You could start calling yourself a "recovering programmer":

http://prog21.dadgum.com/56.html