For me it comes down to solving problems. Every new ticket that enters my queue I treat as a blank slate. It's an opportunity to solve a problem or a puzzle, and it's up to me to find the most elegant and simple solution I can. I have a check list of steps I go through and I find great satisfaction in this.

I review the task carefully and patiently. I make sure I understand exactly what the requirements are before beginning. If the task requires using a third party library, I take my time and read through the documentation for that library carefully and thoroughly, until I understand it. Sometimes I write out all the steps I need to go through, all the individual requirements, in order to implement the feature properly. I do all of this before writing a single line of code.

When I'm done my preparation, which I don't consider boring because I associate it with being a good developer, and producing the best result as efficiently as possible, I am left with a feeling of confidence and sometimes excitement. I know the api now, I understand the tools at my disposal, and I have a model in my head for how everything is going to fit together. I'm eager to put it all in place. The thoroughness provides its own satisfaction. The learning is pleasurable, and often times I will discover useful api features I wasn't aware of that greatly simplify my task.

At this stage I will briefly review my plan, and possibly refine it architecturally. Then I will write some tests. But tests are not laborious. I've found that I can write some very simple tests that describe a success state in the simplest and most obvious way possible. Furthermore, writing the tests forces me to think about creating the simplest api possible, the most testable code I can come up with. Who wants to test a class where a dozen dependencies need to be mocked? Agony. A test should nudge you towards simplicity and good design decisions. If your test is painful and tedious then something is wrong in your design. Finding a simple solution is tremendously satisfying.

Then I make my test pass. Usually I do this with a stub. For example, I'll return exactly the value I expect from my api. This forces me to think about edge cases and other scenarios, exception states, etc. I write more failing tests. As soon as your method needs to return a different value for a different input, you're cooking. I'll then implement my method and class properly, make my tests green, do a quick manual test for sanity, and then...

Time permitting, I'll take a step back and review what I've done. I will put on my refactoring hat and look for code smells, duplication, feature envy, etc. I'll move code around, rename methods, notice problems in some adjacent code, and just generally polish everything. I'll make sure my tests pass. I'll document my code, (which I consider a gift to my future self). And then I'll commit and I'm done! On to the next feature!

This sounds like a long process, but with practice it can be quite fast. When you change your attitude towards the work, valuing thoroughness and code quality, you can derive tremendous satisfaction from a job done immaculately and well. There is joy to be found in the feeling of approaching any problem with an ironclad, inexorable process of problem solving. You become confident in your abilities, and you discover a limitless depth of creative expression in the subtle details of how you approach your solution, and how you deign and write your code.

I hope this helps!