Software development takes all kinds. I'm not talking about appearances or job titles. I'm talking about motivations and fulfillment.
In my years of writing code and leading projects, I've come to learn a bit about how my teammates, and I, experience success, through a few manifest archetypes.
Always a source of conversation, the Developer-Mathematician, seeks truth, pure and provable. They don't want to create software. They want to unearth timeless, universal absolutes that happen to be in the neighborhood of computers.
Catch them crafting functional code, writing property-based tests, or exhaustively searching their bookmarks for that one paper on arXiv.
To be honest, purity and formalism can chafe when building most software. Proofs are still more suited to dissertations than development. Still, it's good to strike a healthy balance between research and development. Make time to try new testing strategies, start a weekly paper club, and keep those fundamentals sharp.
Less formal than the mathematician, but not always more practical, the Developer-Architect is brimming with potential. They want to create something original, important, and particularly elegant. They want to create something that outlasts them, something worthy of use, maintenance, and study. The creation need not be immortal or universal; the more of their mark that is left on it the better.
Find them making high-concept pitches in response to clear gaps in the open-source ecosystem, or discussing best practices that are suspiciously similar to their own practices. If your Developer-Architect is low on ideas or recently saw one of their ideas superseded or implemented without them, they may become despondent.
Software designers derive a lot of pleasure from the design process, but need to be reminded that architecture is far from the hardest part. To avoid turmoil and despondency, Developer-Architects must code their own implementations and design only a few steps ahead. Creative code can be very good code, and may well be worth the risk and wait.
Least formal, but no less professional, the Developer Engineer is the workhorse of the software industry. Engineers build for the sake of building. Recognize them by their willingness to experiment with code, and their lack of attachment to code. If it doesn't work, the engineer has confidence: Toss it, we can build it better again.
For motivation, the engineer needs clear requirements and a modicum of appreciation for a spec well-met. For fulfillment, the build itself often suffices, so avoid process and interruptions.
Proofs and designs aside, I still believe when we channel the Developer Engineer, we channel our best selves. A sense of confident understanding of the problem, married with unbounded pragmatism, leading to working, shippable code. It will have bugs, and it may not be abstracted quite right for future extensibility, but it will work.
We all go through phases, play different roles, and work with all sorts. Embracing the mathematician, architect, and engineer, as well as others, from tinkerers to hustlers, has taught me more than I could have learned by my undifferentiated self.
The key is recognizing your current motivations and finding alignment of these angles within a company, within a team, and within oneself.