The Source for Java Technology Collaboration
User: Password:



Kathy Sierra's Blog

Business Archives


What's so bad about making it easier to learn Java?

Posted by kathysierra on January 19, 2004 at 12:55 PM | Permalink | Comments (26)

I was talking with author Dori Smith recently, and it turns out we both experienced a similar phenomenon: angry email and online posts about how we were making it too easy to learn Java. But is that really such a terrible thing? I know there's a lot of on- and off-line grumbling about whether it's a good idea to "teach the unteachable" or try to encourage "people who have no business programming in the first place."

Yes, this is an old debate (I like what Simon Phipps had to say after JavaOne), but my being on the receiving end of some of the anger is still kind of new to me, so I'd like to hear more about what's driving this mini-backlash against the new wave of books and developer tools intended to bring the not-quite-C++-gurus into the Java fold.

Is this in fact "dumbing down" and de-valuing the Java language and/or de-valuing Java programmers? Should we (Dori and I, and all other folks who try to teach Java to others or who build tools like Project RAVE) deliberately impose artificial barriers to entry to help guarantee that only the best and brightest can ever write Java code?

Is it really true, as some claim, that managers everywhere are going to snap up these one-step-beyond-supersizing-it programmers and toss out all the ones with real knowledge and skills? Is it true that if one needs a gentle introduction (or at least a different *kind* of introduction) to, say, the world of OO development, that it means he has no hope of ever becoming good at it?

Is there no way a Java developer can be any good without a CS degree? (Although there's always a certain amount of snobbery on both sides -- the CS grads (who may not have had real world experience) vs. the hard-core real-world vet who doesn't need no stinkin' degree.) Is there only one True Path by which a human can become a good Java programmer? And if there is, WHO decided what that path was supposed to look like? Is it possible that the path looks like that simply because... well, simply because it always HAS looked like that?

I might be kidding myself, but I like to think that *anyone* who is capable of learning to do this, and has the passion and interest in working at it and growing and improving, deserves the chance. Just because someone needs (or maybe just WANTS) an easier, brain-friendlier way to get started doesn't automatically mean that person is an idiot/dummy. And it doesn't mean that this person is doomed to write terrible code for life, bring large-scale projects to their knees, and signal the final dealth blow to the careers of seasoned developers.

OK, it sounds like I'm being melodramatic, but these are almost verbatim statements I've heard. But the weirdest thing for me is that some of the more vocal complainers I've heard from act as though they themselves were *born* with their knowledge and skills. But once upon a time, they too were absolute beginners. Everyone has to start somewhere.

Roger Schank, one of my favorite AI professors (founder of the Cognitive Science Society, former director of the Yale Artificial Intelligence Project), claims that the whole approach to teaching (and especially technical subjects) in higher ed in the US is almost completely contrary to everything we know about how the brain works. He claims (and the learning theories certainly seem to back this up) that students learn *in spite of* the ways in which complex subjects are taught in school, rather than *because of*. So, why do these methods still persist in universities? He believes there is a certain amount of, "Well, *I* had to suffer through it like that, and by god, SO WILL MY STUDENTS." And the whole thing just propogates forever, including extending into corporate training.

I guess I'm really bringing in multiple arguments here, so I'll try to summarize the main questions I have:

* Is it wrong to make it easy for those without a formal CS background or years of programming experience to learn Java and/or OO?

* Is it wrong to make learning a complex (and serious) technical topic *fun*? Does it degrade the topic? Does it degrade/insult those who worked hard to become expert at that topic?

* Now that just about all C/C++ programmers already know Java, who are these next 7 million going to be?

* Assuming there *is* at least *some* danger (and I believe there is) that some will come in to programming jobs lacking the understanding and appreciation we know they need, is there something we can do?

* In other words, rather than complaining that these next 7 million are going to be our downfall, can we take steps to help the new folks learn and appreciate more of the art and craft of OO development?

These new folks are going to need not just some "how-to" skills, but also "what-to" and "why-to" and "when-to" understanding. I'm not buying the whole sky-is-falling idea, but still, the concerns aren't completely without a basis. So, what can we do to help?



Have your developers seen a real customer in the wild?

Posted by kathysierra on December 22, 2003 at 03:08 PM | Permalink | Comments (14)

A couple of years ago, I addressed an all-hands meeting for a small division of a Very Big Computer Company I Won't Name. This little division had just over 100 employees. I began with a single question, "How many of you have seen a customer in the last 30 days?" (about two hands went up.) "The last 90 days?" (one additional hand). "The last YEAR?" (couple more hands). So, these folks managed to maintain at least two degrees of separation from those who ultimately received their work.

Nice, that. When they don't have to see or talk to customers, they can tell themselves happy little stories like, "This is what our customers want." or "It's not our fault." Meanwhile, those of us who *did* face the customer, almost daily, took the heat. Sure, these other employees heard about quality problems--reports were generated each month, and groups with especially poor quality were "spoken to". But I was astonished by just how poor the quality had to be before it was considered unacceptable. And sure, there were plenty of regular reports with titles like, "Voice of the Customer", where we were given info about what the customers (faceless and nameless) supposedly said and wanted. But there was no *real* voice (the kind you could actually hear) behind the report. No real human with stress of his own. No person whose life we were actually affecting, good or bad.

It seems that as long as customers remain some abstract concept and not real living, breathing, humans, people can justify an awful lot of crappy quality. Meanwhile, the folks who *do* interact with the customer are often among the lowest-paid (receptionists, customer service, entry-level tech support, etc., phone order processors). Hardly anyone ever paid attention to what these folks had to say, and instead listened only to others of their own kind... the kind who did lots of Really Important Work in a nice, hermetically-sealed customer-free environment. No messy clients to get in the way of the real work.

The most depressing part of this story is that the facility where these folks worked had customers in-house virtually every day. Lots of them. If only the employees would walk the 400 yards or so down the main campus hallway. But I decided that if I couldn't bring the employees to the customers, I'd bring the customers to the employees. At least in video. So I grabbed someone with a video camera, and I randomly asked some customers if they'd spend five minutes and let us interview them. Nobody refused.

At first I thought, "Oh, this'll be perfect--these customers will complain and that'll *really* show these employees the negative impact of their work, and that should motivate them to improve. They can't just throw their work over the fence and forget about the impact." And then I began the interviews. Did the customers complain? Oh absolutely. Clearly. Explicitly. "Yes!" I thought, "This is good stuff. This will work."

But then something else happened during the interviews.

Something completely unexpected.

Without prompting, many of the customers insisted on explaining the ways in which the products and services had affected their lives in a *positive* way. In a heartfelt way. In a few cases, a life-changing way! These were living, breathing humans... with more than just a checklist of complaints. They had fears. They had stress. They had dreams. I caught them on camera talking about how this particular service had given them a new direction in their career. One guy said that he never imagined he'd be able to accomplish the things he could do now that he had one of our products, and you could almost see his self-esteem ratcheting up. One woman claimed that a week working with the training and support staff had taken her from hyper-anxiety to relief and hope that things in her work life would improve in ways that truly, deeply mattered to her.

My first reaction was to edit the hell out of it. "Gotta take out that positive stuff", I thought, "that will only *encourage* the employees to continue what they're doing, and make them think there's no need to improve."

But then I wondered... while attaching a name, face, and voice to a customer *complaint* might help improve quality, letting folks know just how important their work really is in HELPING someone's life might do even more. Knowing that someone really *cares* about your work is perhaps more important that simply knowing that someone *complains* about it.

So I left it all in (although I rearranged a few things so that the whole video presentation ended with the customers saying their most encouraging words). In a twist, my partner Bert was one of those interviewed customers. And shortly after that, he began telling me a story (I'm hoping he'll blog more about it, but here's my short version) about a software development job he had for about ten years. The company made extremely sophisticated AI-based broadcast scheduling software, that was initially sold to small radio stations and eventually made its way into large television stations and even cable channels like AMC and BET.

The story was that everyone--EVERYONE--in the company had to do regular rotations through tech support and customer training. Made no difference who you were. Managers. Algorithm gurus. Sales. Everybody had to spend time (and not just once at the beginning of their job) answering the damn support calls and teaching the customers how to use the software. Can you imagine? Can you picture what would happen if EVERYONE who worked on a software program had to spend time teaching customers to use it? If they had to experience the frustration not just during development, but AFTER it's deployed in the field?

Now, XP and other development models like "The Handcuff Technique" do make heavy use of customer input, often demanding that a customer be part of the development team. But what happens *after* the product is out in the world? How often are the developers involved and accountable to the customers *after* the product is deployed? And what would it be like if *everyone* in the company spoke with and--shocking--LOOKED at real customers on a regular basis?

But it can be done simply, quickly, and for virtually no budget. Borrow a video camera. There are no excuses these days--if you (or SOMEBODY there) has a machine with Mac OSX, you can get a cheap digital video camera and edit the video using the (free) iMovie software that comes with OSX. If you can't manage that, take still photos and a simple voice recorder and get them talking. It's crucial that developers (and everybody else on the team) hear the REAL voice of the customer (not just the printed, compiled, sanitized PAPER "voice of the customer" reports that many companies generate).

Then circulate the videos/pictures/voice recordings. Let your team know there are REAL humans back there. Let them know that thier work matters. Really matters. And no, it doesn't have to matter as in, "You're building the software that's going to save thousands of unwanted puppies..." It can be as simple as, "You just made this woman's life a tiny bit easier. And guess what, she's going to use that 10 extra minutes to check on her kids at the in-house company day care." Or maybe even, "You just made things a little more fun for this guy. He can now do something cooler and more interesting than he could before." Think about it. Think about the ways in which some of the simplest, most mundane-seeming products or services have had a butterfly effect on your world. And don't just do it once. Do it quarterly. Or monthly. Keep the customer's face in the employee's face.

Help your team find out how their work is changing lives, and it'll change the lives of your team. Even if it's just a tiny bit, the butterfly effect could be dramatic. It's so easy to think that our work just doesn't really matter in the real world. But it always does. Whether you're building a game, an eCommerce product, a training service, a book, a scheduling program, and even if you believe it's the most boring product or service in the world. If even a single human has to use it, you're having an effect. It really could change lives.

Or maybe I'm just caught up in the whole "It's a Wonderful Life" spirit of the season ; )





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds