Kathy Sierra's Blog

Programming Archives

Does it really matter if your tool is cool?

I don't think it's that simple.

There are a bunch of somewhat-related issues I could play with, but for this blog I'm narrowing it down to:

1) The notion of "pick the best tool for the job".

2) The notion that the "coolness" of your tool is not important (and that it may be detrimental to *want* your tools to be cool).

The rule that says mature, responsible programmers "pick the best tool for the job" makes a lot of sense, of course, but in practice very few can (or *should*) live by it. Obviously for most of us there are tradeoffs we have to consider:

* If you aren't already experienced in the "best" tool, there could be a substantial learning curve. So you weigh the benefits of using the tool against the loss of productivity while you come up to speed. The arguments to this are usually something like, "Well, a good programmer would spend time trying to learn as many languages as possible so that his toolbox is bigger." Which brings up another tradeoff:

* Even if you DO have a big toolbox, the phrase "jack of all trades, master of none" comes to mind. There will always be only a very small number who can not just learn but *master* multiple languages, and KEEP their high level of proficiency. So we weigh whether the additional gains by the tool being a somewhat better fit are wiped out by the fact that your ability to exploit that tool are much lower than another, less suitable, tool that you're particularly brilliant with. Which brings up another tradeoff:

* Context-switching isn't free. Each time you switch to another language, even one you know, there's still a certain amount of mental and physical overhead. Reloading the rule set for "working with this language" into your brain can be costly, and with it comes the reloading of your support materials. Even something as simple as rearranging your reference book shelf is a potential hit. Then there's figuring out where to get support -- which website forums, etc.

These are all the standard points, of course, that have been discussed to death already:

being language agnostic

picking an OK tool

But this really leads me to the whole coolness thing. Those in strong support of always picking the best tool argue that when people are in love with their tool, there's the "everything looks like a nail" syndrome. That if they become so enamored with the cool factor of their tool, they'll do whatever is needed to slap the tool into submission just so they can continue to use it on problems far better suited for some other tool.

Is that SUCH a terrible thing? Taken to the extreme, yeah. Trying to do architectural drawings with a crayon is pretty lame, and doing the equivalent with software development tools could really hurt. But there's a big difference between using a tool that's simply not the best fit for the job vs. using a tool that's clearly wrong for the task.

So if you can assume that perhaps being in love with your tool isn't the end of the world, as long as you don't take it to the extreme, and assuming that your tool (like Java) is capable and powerful and works *well* (even if not always the best) for the widest range of problems you're faced with, then what else can we consider about coolness and being in love?

(First, yes I am making the assumption that people who really care about the coolness of their tools are also likely to really love those tools. I love my Mac. I even love my cool skis. And yes, I still love Java. Could be a girl thing, sure, but I've been around enough men in my life to know they're just as capable of feeling the "L" word for their [insert cool gadget including stereo system, car, guitar, power drill, espresso maker, golf clubs, tivo, etc.])

But first, I'll argue that if tool coolness really didn't matter--that it was about what cool things you could DO with it, rather than its inherent coolness or sex appeal--then why does it matter in so many other areas? We are emotional creatures, even when we claim to be logical and rational. If the coolness of our tools didn't matter, we'd all be driving (forgive the phrase) "butt-ugly" cars. Things where not an ounce was spent on design or aesthetics or coolness, so that it could all be spent on things like safety, reliabilty, efficiency, etc. After all -- if the goal is to drive to San Francisco, then THAT's the "cool thing we can do with it", and all we should be concerned about, right? The tool we use to get there is not what matters as long as it's the "right tool for the job" and in that case the right tool would presumably be the one that would get us there with the least amount of pain and expense. And iPods certainly wouldn't be dominating the mp3 player market. And about a zillion other products that rational left-brained engineers buy would look different and be purchased with different criteria.

Coolness matters.

The psychologists and neurobiologists tell us it matters even when we kick and scream and claim it doesn't. Our brains betray us under the scrutiny of an fMRI scan, where parts light up when we see something beautiful or sexy. (There's a whole other issue about WHY we perceive certain gadgets as "sexy", but I won't go there.) The point is, sexy and cool matter to us at our core, as human beings. We cannot escape it. Sure, we can work to "fight" those impulses... but I remember attending a sales training course a decade ago where the teacher's first words were, "The biggest misconception people have is that *consumers* buy emotionally while *business* customers buy on logic. The fact is, EVERYONE makes decisions with an emotional component, it's just that with business customers you have to provide the facts they need so that they can justify their emotionally-made decision and continue to delude themselves that they made The Rational Choice." Think about all the things you've bought in the last year where you told yourself a really good story to justify it..."The extra pixels on that 23" display will make me more productive." and "No, seriously, this car has a better resale value. It's an investment."

I think I mentioned in an earlier post how Don Norman, usability guru, was once known for strongly advocating ease-of-use over aesthetics, smugly deriding designers for choosing, say, "sleekness" over ease. And of course even HE has somewhat changed his message -- although he still demands usability, he is (passionately) acknowledging that the emotional aspects of design DO matter. A Lot. (And since I have a rule that says I must try to work in something related somehow to Jini with every post, don't forget my favorite geek book of all time, Gelernter's Machine Beauty).

Cool matters to you. Get over it. It's just part of what makes you human. ; )

But now we come to the Big One. The reason that coolness SHOULD matter: Passion.

Coolness (or just perceived coolness, it really doesn't matter) is linked to passion. The cooler you perceive your tools to be, the more passionate you are about those tools. And passion, while it might lead to the "everything is a nail" syndrome, has an extraordinary amount of value!

Obviously there's quality of life... a life with passion is certainly more fun than one without. And the more passion, the greater the chances that a person has what psychologists label optimal experiences. And the more optimal experiences one has, the more likely one is to describe life as being "happy". So, passion = optimal experiences = happiness. And research says happy people are generally more productive. Certainly they're more spirited and fun to be around...

But that's still not the Big One. That people are happier in their life is just a nice side-effect. After all, plenty of people believe that you do some things for money (work) and then you do some things for the chance to express your creativity and passion (hobbies). Hugh Macleod refers to it as the sex and cash theory. Many people believe that it's naive and immature to expect your job to offer self-actualization and personal fulfillment, and that you're on your own for THAT. Of course the level of enthusiasm and passion on java.net means I'm largely preaching to the choir here; although there's still a division between people who are passionate about the things they create using the tool vs. the tool itself. And often, that distinction really doesn't matter. If you're passionate about doing the work, that's the real key.

Still... here's why having a cool tool DOES matter:

Think about how people behave when they're passionate about a hobby or cause. They read about it voraciously. They stay up late at night trying things. They seek out others who share the same passion. They're always trying to get the latest and greatest. They're excited. They try to go from user to power user to master.

Tool coolness can increase the chances of the tool user becoming passionate. And when the tool user is passionate, all those other good things happen. As a manager, I'd much rather have employees who wanted to learn more, stay current, be excited about learning cool new things, etc. rather than the kind for whom any spare time is spent on their *real* things they think are cool. More importantly, as a product *creator* (and this is where we ALSO come in as developers), I'd MUCH rather have my customer/users be passionate about my product. Then I don't have to resort to advertising gimmicks, since word-of-mouth from people who are passionate is unstoppable and the greatest marketing power today.

Can this be dysfunctional? Of course. Passion can become an unrealistic obsession. But that's the exception, not the rule. And of course we DO hope there's a certain amount of fickleness over the long run... that we don't just say, "this is the only tool I will ever love for the rest of my life." In other words, we hope people can become passionate about multiple tools, even if that passion is sometimes serial as they leave one behind when finally seduced by the newer, still COOLER tool...

I guess I could summarize all this by saying that the idea of tool coolness is *not* disrespectful to the professional community of software developers, but just the opposite. That by working to make a tool cool, the tool itself becomes an object of excitement, enthusiasm, and passion. And THAT has value all by itself. So coolness for coolness sake really DOES matter, because it ulimately ripples throughout someone's daily life in ways that can seriously matter. People have changed careers and lives based on a tool that was just cool enough to spark the light that eventually became something much richer and deeper. I do believe that building tools that give someone the power to do something cool is the most important goal, but often the best way to help make that happen is to make the environment in which they do those things... cool. So I'm not really addressing whether Java IS or IS NOT still "cool and sexy" (personally, I think it is.), because that's a personal choice. But anything any of us can do to try to inject coolness into the tools that WE build (as Sun can and sometimes does with Java), can actually help make the world a better place. : ) (She says, typing this on her very cool G5 iMac while listening to her very cool iPod through her very cool stereo and googling on the very cool saddle she wants to get for her very cool Icelandic horse, and grateful for everyone who helped create these things.)

I feel very lucky indeed that the things I'm paid to do are also the things I find really cool. If we can make that happen for other people, by building the tools WE develop with an eye towards the cool factor, they'll thank us.

(And if anybody involved in the creation of the iPod, or the new iMac G5, or Adobe InDesign, or the J2ME Wireless Toolkit (although I'm still pissed you aren't supporting Macs), or Jini happens to be reading this, thank-you!)

How are you on a blind date?

Maybe your mother knows more about software development than you ever imagined. Perhaps the advice she gave you before that fateful blind date--with that special someone your friends convinced you was The One For You--works for software development as well as dating. The assumption here is that you are crafting something that someone else will be using, and it works the same whether you're designing an API for other developers, or an end-user experience rendered through your Swing GUI or browser-based web app.

Wear Your Good Shirt

Face it--how you look does matter. In fact it matters more now than it did before, as we've evolved (for better or worse) into a Culture of Style. The bar has been raised; your target market (not that you should refer to your prospective date that way, but still...) expects more than just functional today. Look at the iPod phenomenon. Dozens of devices play mp3's, and for less money, but people keep choosing sleek and sexy (or today, colorful) over purely functional. In other words, you can't just get the job done--you need to look good doing it.

Now, before you flame me about how surely Ease of Use (and ReUse) is more important than Look and Feel, keep in mind that the two aren't entirely orthogonal. The most successful designers, engineers, and architects in the world understand that beauty lures the user into the experience in a more intimate, engaged way. Quite possibly my favorite geek book in the world is Gelernter's "Machine Beauty" where he explains "how beauty drives the computer revolution: how lust for beauty and elegance underpinned the most important discoveries in computational history and continues to push research onward today."

And come on--can you honestly say that you have never looked at some code, an algorithm, an API, an implementation, or a UI and used a word like "elegant", "sleek", "slick", "cool", "beautiful", or "sexy"? We're human beings, and we're genetically programmed to respond to beauty. Give someone an ugly-yet-functional application or API and they might find it perfectly acceptable, but they won't have that transcendent experience.

In a previous blog about API design, I suggested Don Norman's book The Design of Everyday Things.. And in that book he claims that there's no excuse for making something hard to use. But some of his proposed solutions are a little, well, unattractive. In fact, he rails on engineers and designers for making something look slick (like by using fewer buttons and instead making the existing controls modal) at the expense of usability. And I agree. But why should it have to be an either/or choice? Usability/functionality vs. elegance/beauty? And even Don Norman admits now that it's time for products that will "appeal to the emotions as well as to reason". His new book Emotional Design is driven by his goal to make products more alluring. He says, "For years I worked hard to ensure that products were usable. Now it is time to make sure they are pleasurable as well. Usable, effective products need not be ugly or dull. So, I'm on a campaign to ensure that our products have beauty and emotional impact as well as effectiveness and understandability."

But wearing your good shirt isn't just about looking good--it's about showing respect for the other person. How would (or if you've got some experience with this, how DID) you feel if your blind date couldn't be bothered to even find something clean? Besides, first impressions tend to be metaphorical... I just got off an airplane a little while ago coming back from the Software Development conference. The airplane seat back tray table was a little dirty, and that always makes me wonder, "What else didn't they maintain on this plane?" (a comment which made fellow java.net blogger Sue Spielman say, "Remind me never to sit next to YOU on a plane"). If your code, API, interface gives users a first impression that you didn't take the extra care to make something look decent, that sets the tone for how they view everything they see of yours after that. And it takes a lot more work to undo a first impression.

OK, so does this assume that every product, bit of code, interface, or API has to conform to some extremely high, fully-accepted standard of beauty? To bring this back to dating, does that mean every male must look like he stepped out of the pages of GQ, and every female the pages of Vogue? Of course not! No, I said, "Wear your good shirt", not "Look like a model." In other words, pay attention to aesthetics. Put it on your priority list. It's about acknowledging that the end-user has an aesthetic sensibility, and putting some effort into making what you've got appealing.

Don't Assume You'll Never Have Competition

You can get away with ignoring the "Wear Your Good Shirt" rule while you have no competition. If you're the only member of whatever sex the datee is looking for, it might be less a factor. If you're the only API, product, framework, game in town, for example, you can probably survive and even thrive being sloppy and unattractive. But what happens when you're no longer the only player in the field?

Don't Be Fake

Don't act like you're one thing and suddenly become another. Be honest. Be real. Be yourself. We've all seen software that starts out nice and friendly, and then switches into something different. A long time ago, there was a comparison made between the Macintosh OS and Windows, that went something like this (can't remember the exact original), "With Windows and the Mac OS, it's like you're in a lovely lobby of a nice hotel. But with Windows, you can make one wrong turn and suddenly find yourself thrown into the boiler room." Being clean and honest is better than being a poser. Brenda Laurel, in her book, Computers as Theatre believes a software system should always "stay in character", and that the end-user should be able to rely on what the system initially appears to be.

Be Fun. Be Someone Others Want To Be With. Don't Be Negative.

I wrote my first book using the publisher's Microsoft Word template. I was depressed for about six months. I sat five feet away from my co-author, also working in Word, and I had to listen to him swear several times a day. When we started our next book, we switched to InDesign. And the world brightened. The weather was always a little sunnier. More flowers bloomed in the yard. The pets and kids were better behaved. Of course, this assumes that InDesign was suited for our particular task, and it was, beautifully. But wow--it was like falling in love.

Make a list, even a short one, of the products, APIs, frameworks that made you happy. That made you think, "This is awesome. This is perfect." Now make a list of the ones you struggled with (I'm wildly speculating that this second list will be, um, longer). Next time you design and build something, try to focus on having that thing end up on someone's "made me happy" list. You'll have their undying loyalty and respect for life.

It's Not About You.

Who would you prefer to be with: someone who you are impressed with, or someone who makes you impressed with yourself? Someone who makes you think, "Wow, that person is so much better than I am." or someone who makes you feel, "I rock!"

You know when you're around someone special when they bring out the best in YOU, as opposed to leaving you in awe of who THEY are. When you feel good about yourself, and your capabilities. On the other hand, the people you're less likely to date are those that leave you feeling somehow less capable. Less smart. Less attractive. Less clever, less interesting, less... you get the idea. Way, way too many APIs, books, products, interface, programs, seem designed to get the user to recognize how smart the designer was, when the most appealing products should leave the user recognizing how smart the USER is. If the API you design leaves the programmer feeling frustrated and stupid, they'll run like hell the next time they're given a choice between something that you've designed and something from another candidate. And we all know that lowering someone's self-esteem is NEVER a good recipe for bringing out someone's finest work.

So don't focus on what YOU do... focus your energy on that other person. Paste a picture of him or her (and if you're building for a large unknown group, just pick a picture of someone who represents a member of that target group) on your monitor. Always remember that your work is about THEM, not YOU. Instead of thinking, "What cool thing can I do?" think, "What cool thing will my work let him do?"

Be Polite.

Your mother warned you about good manners. Imagine you're on a first date and suddenly the person you're dating just gets up and walks away, without a word. No indication of where they're going or when they'll return. Ever had a software app do that to you? The little things like progress meters REALLY matter. If you don't think it's good to be rude, then don't have your software apps be rude either. Let people know what's happening. Reassure them. Reduce their stress.

But I think there's a fairly simple solution, and it gets back to the first blog I made here--make the receivers of your product or service humans. Not abstract "users" that appear on a report somewhere. Not abstract "customers" or "programmers", but REAL living breathing people. Find ways to force yourself to see those who receive your work as individuals with needs, concerns, issues of their own. You KNOW how it feels when you do something that delights someone, right? Like, when you cook something for someone (which in my case, is limited to grilled cheese and pancakes, but still... I'm brilliant at them), and you watch their face intently as they chew the first bite. You're looking for that little smile... that subtle way their face lights up and you know you've made them happy. Think about the ways in which someone else's pleasure makes you feel good. If you can truly conjure that sensibility when you're designing a product or API, you'll have to hire a bodyguard to fight off the rabid fans.

I'm serious about the picture thing. I pasted pictures of customers in my cube. I made a sign when I was at Sun that said, "Someone just paid $3,000 for my service. Was I worth it?" and eventually I started seeing those same signs tacked up throughout our building. (With some minor word changes, although I can't understand why... ; ) And if you're a manager, encourage your staff to watch video tapes of REAL people or better yet, TALK to real customers. Last time I blogged about this someone commented that if management is doing their job correctly, workers shouldn't have to have any contact with customers. In other words, the spec should say it all. But what I'm talking about goes beyond the cold, hard, specification and into the realm of emotions and beauty and passion.

I have to believe that if I had a webcam at home, and the developers of Adobe InDesign could watch me at work, it would make them happy to hear me say, "I LOVE this program!" at least once a day (and this is after more than a year of full-time use). That doesn't mean that I don't have some issues and complaints, but as it is with any worthwhile relationship, when you're head over heels in love, you don't dump them just because they don't meet every possible need.

Perhaps instead of reading so many technical books, developers should go back and ask their mothers for some good old fashioned dating advice. And hey, just because you're already in a long-term, committed relationship doesn't mean you should take ANYTHING for granted. Imagine how delighted your long-term partner would be if you came home one day acting much the way you did back in the days when you were still trying to impress them ; ) Just because you've got customers you don't believe can, or will, go anywhere else shouldn't be an excuse for slipping on the fundamentals. Putting a smile on someone's face can be so easy... you can usually delight someone simply by doing just a tiny bit more than they expected. Imagine a world where we all work just .01% harder at trying to put a smile on someone else's face : )

To API designers/spec developers: pity those of us who have to LEARN this...

There have been some interesting and useful discussions and guidelines on API design from people like Steven Clarke and Bill Venners. And the discussion can get pretty heavy.

But I'll just mention one idea: APIs should not be exempt from fundamental usability principles. I'm coming from the selfish perspective of one who has to actually learn to *use* these things, and, more recently, as someone who has to try to help others do the same. And if for no other reason than to make myself feel better, I'm going to suggest that if you have real trouble working out an API and you're thinking that it REALLY shouldn't be that hard... perhaps it really isn't YOU. So before you start questioning how on earth they ever gave YOU a PhD in astrophysics when you can't even work out one frickin' interface, take a deep cleansing breath and repeat this little positive affirmation: "It's not me. I AM smart. I have the to prove it. But oh what I wouldn't give to wrap my hands around the neck of the one who designed this API..."

It's easy to rail on API designers when you're on the other side, I know. I've personally authored some of the most unreadable and unmaintainable code in the history of software. But at least I have the decency to feel guilty about it, especially after having spent a few years studying usability and learning theory. I don't want to single any group out, but I have to make at least *one* example; it's from the EJB spec (which, don't get me wrong, I LOVE. It's perhaps one of the most reader-friendly specifications to come from Sun).

Usability principal: Things which behave differently should look different.

This is fundamental user interface or product design 101. Humans will assume that if two buttons share the same shape and color, for example, that they'll generally have the same kind of behavior. So product designers are expected to do things like, "Make the navigation buttons look and feel different from the control buttons..." One of the worst violations of this is in products which use the pure evil of "modes". You know what modes are--where a button is overloaded so that in one mode it does THIS but in another mode it does THAT and... Donald Norman (who recently spoke at the Emerging Tech conference) writes fabulous books, at least one of which should be REQUIRED reading for every programmer: "The Design of Everyday Things". He does a great job of letting you off the hook by explaining how it's not your fault you can't work that device, and that product designers are either being lazy or trying too hard to save money by making fewer buttons.

Example API violation: lifecycle callback methods for Entity and Session beans.

When I try to help someone learn EJB, I spend way more time than I should with things like, "What's that? Why is there an unsetEntityContext() for Entity beans but NOT for Session beans? Oh, because you have to have a callback for when the bean instance is being destroyed. What? That's what ejbRemove() is for? Oh, no, that's just for Session beans. With Entity beans, ejbRemove() means "delete from the underlying persistent store", so... since ejbRemove() was given a profoundly different meaning for Entity beans than what it means for Session beans, well, they had to have something else to call when an Entity bean instance is about to die." And then do all that again with ejbCreate(), of course. (And don't forget that both ejbRemove() and ejbCreate() have corresponding methods in the client interfaces... remove() and create(), which also share these differences.)

According to usability fundamentals, giving the Entity bean interface the same methods as the Session bean interface, but giving those methods completely different meanings, adds MUCH more cognitive strain than if developers simply had to learn two totally new method names. You simply can't wrap your brain around learning that a set of methods does one thing for this object, and something drastically different for this other, very closely related, object. In other words, they made ejbRemove() and ejbCreate() use modes! If you're in Entity mode, they mean one thing. If you're in Session mode, something different. Not that we all don't *get it* and remember it, eventually, but it takes longer and we could be doing other more important things. Like skiing.

Again, I feel a little bad picking on this one example from EJB, especially when there are so many other things I really like about that spec. But it's the one that's caused me the most frustration, because I have to go through this process of helping people learn—and then unlearn/relearn—these methods every time I try to teach EJB.

Now, for some APIs it probably is just a question of better docs. But better docs wouldn't help the fundamental problem of something like modes, so better docs isn't the solution for everything.

My suggestion is that each and every programmer be strapped into the Don Norman Appreciation Chair and forced to read "The Design of Everyday Things". It's fun, fascinating, and enlightening. I have a whole book list after that, but I'll save those for later. My goal in life is to make MY life as easy as possible, and I truly believe that if everyone pitches in, you'll really help me out on that. Because unlike so many of you, I am one of those unfortunate souls who is NOT a quick learner. If not for speed dial, I wouldn't be able to call home. Imagine how long it takes me to memorize well-designed and well-named APIs, let alone the truly confusing ones...

Rekindle your passion for programming

I'm sitting here at MacWorld Expo in San Francisco. I flew more than a thousand miles to get here, and I'm paying for it out of my own pocket. Why? Because it gets me excited. I'm surrounded by cool technology (I've waited my whole life for Apple's new GarageBand software). I do it because I'm happier and more productive if I stay enthused, and attending conferences has always worked for me. So I pay it for it myself, even if it has no direct *business* value.

Life's better when I'm motivated and passionate. And yeah, sometimes it's *easy* to stay enthused, like when I worked as a game developer. But as much as I deeply appreciate enterprise Javabeans, as an EJB developer the most thrilling part of writing and deploying a bean for me was coming up with a JNDI name (and we had a naming convention anyway, so that pretty much sucked the creativity out of *that* decision). So when I moved from doing fun GUI things (which I loved) to doing server-side enterprise things (which I, well, did *NOT*, unless it was Jini, but that's a whole different story), I had to find my own ways to stay pumped up. I don't mean pumped up for *life*-- that's what skiing is for. I mean pumped up for *work*. I'll be damned if I'm going to spend 7 to 12 hours a day with no passion. Life's just too short (or is it too long? I can never remember which one works best here) to spend that much time without this level of excitement.

So I go to conferences. That's *my* way. I've been doing it for the last 15 years, and it has always been worth every penny (although I try desperately to get my employers, when I'm employed, to pay for them).

Do I go to learn? Yes, but that's not my main goal. I go to become swept up in the enthusiasm. To risk my life trying to catch the t-shirt tossed to the crowd at the end of the demo. To see the dog walking the floor with a webcam on his back.

I'd love to hear about conferences (or any other events or activities) that get YOU excited, but here are my all-time favorites:

MacWorld San Francisco.

The Game Developer Conference (I don't care WHO you are, or whether you have ANY interest in building games, you'll still love this one)

JavaOne (duh)

GeekCruise (to be honest, this is one I have not paid for myself... I went as a speaker)

Siggraph

Now, I have to say that my experience with a conference will be very different from someone else's... a lot of people don't like JavaOne, for example. But I always go in with the attitude that I WILL get something beneficial from the show, by allowing myself to be caught up in the excitement. I don't go in with the expectation that I'm going to learn a gazillion killer tips and land a new job/promotion/raise. Last year's JavaOne, for example, was worth it just to hear Josh Bloch do his "Tiger, Tiger Burning Bright" poem. Not as cool as a Coldplay concert, but this guy has a lot of fans (me included), and most of the (standing room only) folks in the room were pumped up about Tiger after that. And yes, that enthusiasm fades as you get back to your cube and realize you have still MORE to learn (and still no time in which to learn it), but I believe that in some dark corner of your mind, that sense of excitement still hovers, waiting for you to encourage it. To water it and keep it alive.

To rekindle the flame and help remind you why you DO love Java, and why writing Java (even if it's not what you get to do on your day job) makes you part of a very exciting group. ; )

So, some might say that it's an employer's job to keep that spark going, by paying for the development of the developers. And I believe that this is one of the best investments an employer can make. But I'm not willing to make my level of personal passion dependent on my employer. Yes, my employer DOES benefit by the enhanced quality and productivity and creativity that comes from my having attended these conferences, both from a learning-new-things and feeling-more-excitement perspective. But if my employer's too short-sighted to see that, I'm doing it anyway. I'm doing it for the quality of MY daily life.

And to get the latest iSkin for my iPod (in a shade of blue that matches my eyes, of course).

This work is licensed under a Creative Commons License.