Cool Beans

This is supposedly an internal Netflix memo, but when posted on Slideshare it was discovered and spread virally. As you read through it, you will feel this coolness vortex pulling at you, making you wonder if it could ever be possible to have such a culture where you currently work. Such freedom, respect, fostering of innovation and excellence.

I especially like the sections on being "highly aligned and loosely coupled," which goes against anything I've witnessed before.

Congratulations to Outspokes for a successful launch on Sept 15, and the cool demos in the Demo Pit of TechCrunch 50.

For those not familiar, let me quote their site:

With Outspokes, you instantly gather the feedback of your entire team by doing nothing more than sending them a link to your site. No more arduous screenshot annotation or endless email ping-pong. Empower your team to express their feedback about your website the easy way: on the site itself.

Outspokes.com in the TC50 Demo Pit

I've beta tested it, and thought the web application service quite impressive. The ability to collaboratively change elements and annotate while looking at the live site is something I've never considered and yet so common sense. And, just like any Google widget, it takes only a line of html code to enable it for almost any website. At TechCrunch 50, I overheard one attendee say, "When working with webdesigners on my site, I'd have to take a screen shot, copy that into a Powerpoint, then add highlights and comments for what I'd want changed."

With Outspokes, you can directly receive site feedback from QA, beta-testers, developers, designers, and even marketing without burdening anyone with screen shots or mockups. Change the look-and-feel, report bugs, modify text formatting, add comments, and even agree or disagree with other users' feedback.

So why do I post about it? I once worked with one of the founders, Jerry Cheung, at UC Berkeley (I hope to say that often in the future when he's famous). I am amazed that co-founder Arthur Klepchukov's CS 169 software project has taken off into its own company. I wish them success in their new startup, and encourage you to incorporate Outspokes if you have any kind of website.

On August 19, the Silicon Valley Web Java User Group had the chance to hear Dan Allen (author of Seam in Action) talk about JSR 299: Contexts and Dependency Injection (CDI), and what's new in JavaServer Faces 2.0. Dan gave me permission to post the audio recording of this fascinating Java tech talk. This is quite a big change to JEE 6, and I can't wait till it's supported across the major Java containers.

There was so much new to talk about that we ran out of time. Hopefully I can also track down the slides so some of the code examples can be followed.

• JSR 299: Contexts and Dependency Injection for Java EE (90MB, 1 hour 34:35 minutes).
• JSF 2.0: What's new in JavaServer Faces 2.0 (15.9MB, 16:34 minutes).

Update Sept 10, 2009: Here are links to the slides so you can follow along.

• CDI
• JSF 2.0
  

Thanks to Google headquarters for a great venue, and to the SV Web JUG for organizing the event.

This title came from my misreading of Are you a language wonk?, a blog article about building a language. Sounds really cool, but I currently have no interest in creating my own language. The topic brought to mind a discussion I had with a very sharp former Cal student. He stated to all the newb programmers in the team, "Good programmers are language agnostic."

This got me to thinking about all the different religious battles I've witnessed (and been in) about what the best programming language is for the task at hand. Without delving into heuristics, bias, and conventions, here are a few things I think support mht's claim:

•  It is likely much easier for younger minds to switch-task and switch-context often.
• Having the ABC's in place, i.e. the theory (versus learning only by projects that require a certain job to be done) helps one be more platform-agnostic.
• We will, under stress or deadline, always resort to the path of least resistance. In programming, this is the path that we know best, the one where we are most practiced. (This is why it's good to regularly practice outside one's own comfort zone.)
• Learning on the job (also known as "experience") is not a substitute for personal interest and personal development in computer science.
• Mastery takes 10,000 hours. But master one language, and there is collateral benefit to other languages.
  
• Writing lots of code is the only way to mastery.

So think about your job. Are you tied to a single way of thinking/doing? Do you have strong opinions of what is "the best" without having fully understood the alternative languages? These are signs you are still on a monk's path to mastery, and would benefit from some agnosticism.

Recent rejection of the official Google Voice application from the iTunes App Store has prompted me to write something that's been grumbling in the depths of my soul. (Well, not quite that deep, but still, grumbling.)

Google has, once again in their spirit of giving paradigm-shifting technology, given away for free a telephony system called Google Voice. Basically it's a service that consolidates all your varying numbers into a single number. Not a new idea, but with things like voicemail transcription, and the long-wanted but hardly ever implemented phone blocking/screening features, I must say it's far and away one of the most useful free telephony services ever to be given to the eager public.

Android (an open mobile operating system created by Google) developers and Blackberry developers have already released applications to utilize this great system natively on supporting phones. But the question always comes up, "When is the iPhone app going to be ready?"

This is a sticking point for me. A thorn. Yes, the iPhone is unbelievably amazing. Usability of the OS alone makes it stand out as the ultimate take-everywhere device. If I am not at my computer, I am probably holding my iPhone if not thinking about holding it. It is undeniably a market leader, the standard by which all are compared.

But there's the despised side to Apple. It's their controlling side. They've played it well by having super-secret product development, generating buzz and causing a frenzied cult following for anything latest-greatest to come out of their Chinese factories. They've kept their design elements uniform, and their development environments very well-integrated; they've controlled their features by constantly simplifying, doing away with the superfluous (what they deem superfluous) and forcing users to realize that they don't need things like LPT ports, PCMCIA slots, and Firewire 400. And so with these undemocratic decisions, still keeping a pulse on usability design somehow, they've managed to provide us with products we admire and covet, even to the point of forsaking features we used to really like.

This, of course, has nothing to do with Google Voice, which merely hopes to give you free calls and better services than AT&T, but Apple has pulled the plug on any apps that use this service, citing duplicated features, and arbitrarily rejecting something we all could really (and do want to) use on our take-everywhere device.

It's really time for Nokia and Android to step up. I wanted to write a more comparative post about the pros and cons of developing on each platform. Having hammered out code in each environment, I've come to appreciate and dislike some things about each. But with this latest F-U from Apple, I'm just going to get to the gist of competitors:

• Android needs to fix its garbage collection so the performance doesn't suck so much.
• Android needs a UI guru.
  

I mean, it's a great system. A pleasure to write in (albeit a bit legacy Java-like), and best of all, it's so free! And I don't mean let's go download it for free, free-- but free as in code what you like free. With some terms-of-service exceptions Android development involves no App Store bonehead who is going to axe your months-of-labor baby because it competes with their existing official app or irks the carrier. As for UI, let's face it. If I'm dragging a tab with my finger, and it freezes for a half-second, then jumps and makes me select something else accidentally, that's just plain annoying. Annoying to the point of not wanting to use the phone anymore. It's that much of a deal-breaker.

So no matter how great the OS is, if it doesn't perform in a usable way, it will ultimately be set down in favor of what Just Works™.

• Nokia needs to quit meandering in J2ME and linux wannabe obscurity (and S60 inaccessibility), set out some  welcoming development tools and, once again, design awesome usability.

Thing about Nokia S60 (and Win) development is you have no real crazed following of "for fun" side-project-turned-startup developers. I try to find programming resources in these areas, and they don't hold up a candle to the deluge of iPhone-- and now Android-- dev resources. User groups are easy to find in those other non-Nokia platforms, too.

Nokia and Blackberry’s hardware and carrier focus has thus far led to lack of investment/interest/capability in software SDK design & developer support.

Diesel McFadden in response to an article by Christine Gonzalez

Inaccessibility, and developer pain, are not a ways to build a kickass mobile OS. I'd really like to see this major mobile player kick developer-friendliness up a few notches and quit being so arcane.

The more Apple does stuff like this, the more it is a loud call, a superb opportunity, for other competing OS providers to come up with a superior user experience and draw more into their fold. What better way to create a following than to have thousands of determined coders evangelizing for the greatness and intuitive ease-of-use of your products.

Apple can also see this as an opportunity to lighten up, and to let people have what they want even if it doesn't agree with Apple superiority. But I have a feeling that might be asking too much.

As programmers or service providers, our lifeblood is our customers. Well, duh! you may say. Yet many a (young) programmer would like to think they could just code away at their desks creating elegant and properly formatted perfection, avoiding "useless meetings," and being largely abstinent of the business side of things.

But what happens when things fail? Fail massively? What happens when our front-line support staff are forced to face the music as dozens, if not thousands, of customers start calling in? How do you manage an audience that is starting to share horrible things about your products?

It's bound to happen... Are you prepared for it?

I was recently reading an article by HighTechDad about the do's and don'ts of customer service. HTD is well-versed in this area, having run Customer Service departments in the past. He shares some experiences and provides many tips about keeping your cool and getting to resolution from the customer or company perspective, e.g.:

• Offer solutions
• Try to go beyond the expected
• Don’t let the customer know that you are frustrated
• Be friendly and conversational
• Try to connect at some level with the customer (e.g., if you know their location, ask about it)

In this day and age, you don't want people walking away from your service reps feeling deprived or ignored. Especially since there's the added vector of complaint when your socially-networked customers instantaneously broadcast their pain and suffering to hundreds of friends, family, coworkers, business contacts, Twitter followers, and blog readers.

Many companies dread the periods of high support traffic and view it in the "lock down" mentality; a mindset of merely dealing with damage control. Service representatives are trained to tell frustrated and/or impatient people that: Yes, we know there's a problem, we don't know exactly what happened, we don't know yet when it will be fixed, and we are sorry for the inconvenience. Customers who deal with "enterprise vendors" in particular are almost used to the abuse and don't expect much from a submitting a trouble ticket. I believe people on all levels, from the coder in the trenches, to the person who has to answer the phones, can go beyond what is expected to help retain customers and let them know they keep us alive.

The difference between how a company treats us when they make a mistake can be the ultimate in loyalty building (or destroying). A mistake handled well might makes us more loyal customers than we would have been had we never experienced a service problem. Remember this with your customers when you make mistakes on the job.

- Chad Fowler, The Passionate Programmer

From the end-user point of view, nothing sucks more than having a valued service suddenly fail to perform at the minimum acceptable level. Even retail purchased items that were once prized possessions (before they broke) cause us much disappointment when they fail to do their function. If I paid hard-earned money for it, it better perform. We've all been there: High elated expectations come crashing down as we realize, "What? It doesn't work? Why? What alternatives do I have? Do I really want to stick with this and try to get it fixed? Can I refund it? Nooo, can't it just work! Aaagh, why's life so hard?"

A Good Bad Good Customer Service Experience

Recently I visited a well-reviewed winery called Darioush. This was about 2 wineries into a trip, so I had already sampled and enjoyed a bit of Napa Valley to this point. But what wines I thought were good were far and away superseded by the ones at Darioush. I had no problems handing over $80 for a bottle of wine that I absolute had to take home with me.

You might be thinking, "Who cares? I thought this was about customer service! Why are you talking about your dumb yuppie-wannabe wine trip?" Well, let me get to that.

Once I got home, I unpackaged the wine to admire its serene bottled beauty. But then I noticed a little purple residue in the cork wrapper. I knew immediately this meant the cork was leaking, which meant the wine was probably bad. From high to low. What to do? Such an insignificant single item in the grand scheme of wine production. Dejected, I went to their website sent them a note about my discovery. For a few seconds I considered driving the 40 miles the next weekend to exchange it in person, but in the end I resigned myself to $80 down the tubes. Sigh.

The next day I got a call from a number I didn't know. The person on the other line asked for me by name and was suddenly apologetic about my experience with my wine purchase. Without even questioning the nature of the problem, she was ready to send me a replacement bottle immediately, and only needed to verify my original purchase and get my shipping address. Wow, just like that, they want me to be happy with their product. They've gained a loyal customer in me.

Then I waited a week and a half.

Bad. What happened to my shiny customer service impression? It faded into mild acceptance. I felt like I was duped, like a yes-man (or woman in this case) told me what I wanted to hear then left me in the paperwork. "Immediately" was not really so much. Once again let down, I counted it a loss and sent another short message via their website.

The following day I got a FedEx tracking number originating from Napa. No call, no reply.

They followed through on their promise, albeit with a little reminder. This, coupled with a great product, was good enough for me. I can still share the story about how they went beyond initial expectations to keep me happy, but the story is not as punchy as it could have been. They have, my loyalty, retained.

Moral of the story? If you're the customer, don't come to the table feeling entitled; manage your own expectations. For the service representative: Be honest and receptive (even if it's bad news) and be ready for your product to fail. You never know who's socially networked and waiting to share. Do whatever you can to transform the mistake or problem into a chance to build loyalty, and, perhaps most important of all, follow through on your promises.

--
* This article title I got from Chad Fowler's book referenced in the quote. Please read this book if you're in any sense working with code, it has some fantastic advice.

We lament the loss of material things, and try to honor the "old ways" that were more tangible and harder to erase. The digital age comes with it a seeming cheapening of these pieces of information in that they are so easily lost, hidden, stored away, and forgotten. And yet, the digital age is much more like life in a way. It is transient, so easily lost, so temporary and temporal. Death is constant with digital media. There is no lasting, there is no permanence. Everything is in transition, and in almost inconceivable bits and bytes that can be wiped with a misdirected EM pulse, corrupted NAND module, or disk platter failure.

Death is merely transition. How attached we are to the old state, is how heavily we feel the sense of loss. But digital (computer) media is always bound for transition and nothing is guaranteed. In this sense it is very much like life, like reality. And much less an illusion than the "old ways" of information storage that we romanticize.