The more software I have created, the more I have considered myself "design-minded", especially with regards to user experience. It's not that I am designing software myself, but rather that I observe and place more value on design than I used to.

Coincidentally, I've noticed some changes in my habits as a developer. I spend much more time, proportionally, deciding on things like behavior separation, function use cases, and naming. I've gone from thinking code style guides "can't hurt" to believing they are a strong indicator of a quality codebase. I now consider code reviews an integral part of working on a team.

We tend to view design and development as exclusive areas, two halves of a whole process. I think it's actually the case that design, as a practice, lies on a layer above programming. That is, design contains universal truths and strategies that work in programming (and other fields), and programming is comprised of more specific techniques.

This is because a significant part of programming is not just the computations and output, but designing code so that you, and others, are able to use it with ease and effectiveness.

Names, function signatures, class hierarchies, and interfaces are all a kind of UX – they afford certain usages, and determine your path of interaction with the code.

Code style guides are essentially UI, even if they are a very limited expression of it.

Code reviews are much like user testing; after all, your teammates are the end-users of your code.

These aren't perfect analogies, but I think they serve as evidence that design principles can be applied to anything that humans interact with, even if the primary goal is not the interaction itself. Try to think below the surface, and look for ways these principles map to whatever you do. If your job involves making things, learning about design will give you another framework to use to improve your work.