Why I *LOVE* being a Software Architect

I was reading a few DeveloperWorks articles the other day - interviews of architects on the next big things and trends in Software and it suddenly hit me - I really do love being a Software Architect - at least by the terms I define "Software Architect"
(see my other blog entries)

There's huge variety in the tasks I do each day
- There's meetings with people - developers, managers, business people, analysts, project managers and testers - each with a different language, different concerns and different needs

- There's always lots of learning to be done, if you want to stay current anyway. I learn through three core sources
1. Reading articles, books, blogs etc.
2. Learning by doing - software development is part craft and part engineering - to hone your craft you need to practice especially to a (realistic) deadline when there's $$$ on the line.
3. Learning from others - whether it's about a design, a unit test, a component or how a bond or mutual fund works you can learn so much from other's feedback, thoughts and ideas

If you're an Architect you should be spending 10-20% of your time just learning. Take J2EE for example - the JDK is always in flux, Java 5 provides, among other things, annotations, generics and new threading utilities - WOW. There's new JSRs, new trends, new open source packages, new Eclipse downloads. You can get overwhelmed easily in the firehose of information out there.

- Best of all there's the nice warm fuzzy feeling you get from "making a difference" - helping to shepherd someone's ideas and business goals in to reality. Mostly, for Architects, that comes from Problem Solving - these can be technical problems, but you'll also face project problems (such as scheduling issues, requirements scope creep), staffing concerns (hiring the best and brightest and then - hardest of all - keeping them) and then simply issues related to writing good solid code.

On the technical problem solving side, a lot of creativity can come in to play which is really great. But since you earn money to get the job done, that creativity must be harnessed and focused on the problem at hand - no-one's paying you to create a new language, or the next big thing per se. You want to leverage your experience and the experience of others (e.g. design patterns) to create a "good enough" solution. In my experience most requirements change about 35-50% by project-end. The "perfect solution" is a misnomer as what's "perfect" at the start of development won't be "perfect" by the end - so your architecture has to be flexible - that takes creativity and experience. To merge the known industry best practices, with the environment you've got and the project itself involves another level of creativity and inventiveness.

Then there's also the more visceral side- I love my job because I'm good at it (or else my employers think so!) and that creates pride and self-confidence and that's reinforcing to one's behavior. There's also the compensation - for whatever reason, supply-and-demand etc. we're paid a lot of money - more money than I'd ever thought I'd earn and that's reinforcing too.
Sometimes I forget just how lucky I am to work in a field I enjoy so much, am quite good at and
can get well compensated for it too. There's always so much to learn, code that can be improved, bugs that can be found, new things you can learn from other people - you're never done with the journey. But sometimes we all should just take a step back and see how far we've come and be thankful (myself included).

How about you? As developer / architect / manager etc. what do you like/love or dislike about your job in this world of software?