Fluff N Stuff

I just attended the No Fluff Just Stuff (NFJS) tour, hosted by the Northern Virginia Software Symposium. This is a tour of speakers that talk on the following topics: Java, Java server technology, Ruby, Ajax, JavaScript, agile programming, new programming languages (like Groovy).

This is the second time I've attended the talk. I go partly to learn new things, partly to get a sense of what the non-.Net industry is up to, and partly to see how good people give talks. Unlike, say, ETECH, which tends to have weird rules for how they invite speakers, which leads to uneven quality of talks, though often bigger names attending, NFJS generally have pretty good speakers. Speakers have to try out and get rated well to be allowed on a tour that is something like the Lollapalooza of geeks.

Speakers go anywhere between 6 and 12 different cities which is usually held on a Friday afternoon, and a full day on Saturday and Sunday. Speakers typically on two of the days, so they never have to be there the full time.

What makes an effective speaker? Some speakers are excellent at injecting humor. Of the regulars, Dave Thomas is really good at this. But it's hard for most people to be funny. One of the lessons you learn as a speaker is that if you're not terribly funny, then don't try. It really is painful to listen to jokes that simply fall flat. Scott Davis, by contrast, doesn't tell many jokes, but gets so into the subject matter he's covering that you're engrossed in what he has to say.

Some of the secrets of good speaking came out in one of Dave Thomas's less technical talk. He talked about "herding racehorses and racing sheep". In this talk, he gives levels of expertise from the complete novice to the expert, and how each level of expertise (he gives 5), and how you have to talk and treat a person at each level differently. A novice, for example, wants painstaking detail and a good chance of success.

Dave points out a family recipe whose ingredients are given in approximate terms (a pinch, a handful, etc). He says this is basically an expert talking knowing how much they mean by these approximate terms, but how inappropriate this is to a novice who doesn't know whether a handful is small or large or whether it depends on a person's hand.

He also illustrates his point as he recounts learning how to fly a plane. His instructor told him that he would end up doing something wrong, and told him what that wrong thing was, and how to compensate once he knew it was happening. Dave thought, for sure, he'd not make that mistake now that he intellectually knew what was coming, and yet, when it came time to fly the plane, there he was, making this mistake, even though he knew to be prepared for it. And he asked the instructor "how did you know?" and he said "it happens to everyone".

Now, as he's doing this demo, he's jerking his body, making faces, trying to demonstrate the physical nature of what was happening to him. Good speakers can involve their listeners by more than just words.

Scott Davis doesn't do any of this. His approach is more pure. He knows that the way to entice someone to listen is to provide them something they couldn't easily get from a book. He needs enough details about what he's doing so he isn't spouting platitudes ("make sure to comment your code---other people have to read it!"). Instead, he'll have code examples that go from cool to very cool, but all quite do-able.

Here's an example of a talk that would work well in NFJS. How many people say "don't prematurely optimize". Plenty, right? They say, profile, then decide what to optimize. And yet, I've never seen anyone profile in a demo. How does that encourage a novice to learn about profiling? It doesn't. They decide it's too much work, and don't want to bother.

A good talk on profiling would show two or three different ways to profile, the advantages and disadvantages of each, and explain the pitfalls of the various kinds of profiling. For example, in one of the talks, the guy said that people sometime to microbenchmarks because that's what people did in C, and it doesn't work in Java, because of what the JVM does.

Now where can you get this kind of information? Can you pick up a book and read about this? Maybe soon, but not right now. And it's just the kind of insider information you want to hear at something like this. That the intuition you've used for so long is wrong.

Amazing, programming languages have traction at NFJS. For example, I've heard talks about Ruby, JavaScript, and Groovy. You want to hit all the weird things you can do in the languages, not just hash over how to write a loop. For example, in the JavaScript talk, Glenn Vanderburg talked about how you could implement single inheritance in a prototype-based language. He covered closures. He showed the JavaScript object model. Even if you're familiar with Java, this is a completely different language, and more than simply popping up alert buttons.

Glenn's speaking is neither as funny as Dave Thomas, nor as enthusiastic as Scott Davis, but he has good examples, and he's pretty clear in what he does.

I attended a talk by Andrew Glover who talked about Groovy. For the most part, he did reasonably well, but he was incredibly self-conscious about talking. He kept saying things like "I'm going to get dinged on the reviews for that". That's just the kind of thing that you shouldn't say. It's trying to get sympathy from the audience. I understand that live demos are hard to give. It can slow you down, and they are prone to errors. I was reasonably happy with the live demos he was giving, though I can see how they tend to disrupt the flow of a really good presentation.

Andrew would also occasionally do something with his wrist, as if he were wearing a watch that was too loose, and had to keep adjusting it. That was mildly distracting. Aside from these issues, he hit some of the more unusual features in Groovy, something that makes it worth trying out.

Before I talk about Jared Richardson (now that I've mentioned his name, his Google RSS search) I should mention one guy who hung out to the end (other than me). Jared had just finished his talk on Cruise Control and how to set it up. The talk had wandered a bit, but I don't think too many people minded. He had said that when the build fails, the alerts could be emailed or sent via RSS or any of a myriad number of ways that Cruise Control has built in. (I had wanted to say he should tell a joke that Oprah wish she had this product---she needs Cruise Control, all right).

This guy comes up and asks about RSS. Apparently, he had never heard of it. And this is, I think, key to something that's very interesting about the software community. It is incredibly large, and a small, rather devoted percentage, spends a great deal of time trying to keep up with industry.

To illustrate what I mean, suppose you were a math major. Would you decide to work on math outside of class? Perhaps a person wanting to get a Ph.D. would do exactly that. After all, it's their life work. But maybe if you're not that inclined--a job as an accountant will do just nicely, thanks---you wouldn't bother.

Among those who major in computer science, there are some that are avid about computers outside of the major. They install Linux on their machines, even if there are myriad details that make this painful, which is why Mom and Dad won't touch it, even if they use computers. How many people have spent a few days hacking at their installation so it would get all their drivers to run, so their configuration and packages are just so? This is the kind of time most people would say is a waste. And yet, avid computer science types do this.

I once asked a class how many had built their own computer? More than half the class said they had done this. These days, especially in the last few years, it's easier than ever. You probably can't do too much that would fry the motherboard anymore. And even if you're too scared to do it yourself, you could probably find someone to help you out. It's no longer as cost-efficient to do it as it used to be. A comparable Dell is likely to cost less and have a warranty. But it's a great way to learn how a computer "works".

Still, it's something you don't learn in a computer science class. You have to pick that up on your own. People have learned how to work with MySQL and PHP and set up their own Apache web servers. Covered in a CS class? Nope. At times, the people teaching computer science are mired in the past, unwilling to keep up with the technology as it charges breakneck pace through.

How many people read Slashdot? Or Kuro5hin? I never cared for either, but I'm somewhat addicted to Reddit. It's nice and simple and always has a few articles I want to read. Occasionally I peer over at Memeorandum, mostly because I know the guy who created it. How many of you have set up a photo account at Flickr? How many tag? How many feel that you have to learn about this? Learn Ruby on Rails? Learn Ajax? Are you ready to write a Groovlet? How about a Zimlet?

You can get on perfectly well in the computer industry doing the job you do and never have to think about any of this, and yet, the industry expects you to know something about it. It's as if we were a bunch of writers, but had to keep up with new writers out there, and new technologies that make writing easier.

So here was this guy who knew nothing about RSS. Perhaps he knew nothing about CSS either. They sound the same, but are quite different. We explained to him what it was and how he could try it out. Some people are addicted to their RSS feed. They value it more than their email. I could never quite get into it. Perhaps I should try it again. But notice the kind of behavior I have to pick up, how I'm being compelled by the computer community to do this because it's the latest, hip thing to do.

Should you blog? Do you tag? Do you have an account on Myspace? Do you host your own site? Do you have a domain name registered? And you know there's something coming up on the horizon. Is it mashups? All these open APIs telling us to make our own maps, build our own Google Map for whatever we want (a particularly odd mashup locates sexual predators).

People like that attending conferences make you realize that, even within the software industry, there are technophiles, alpha-geeks, people who love, love, love the new stuff.

And this, ultimately is why we can never be like the nurses in Dave Thomas's example about novice learning, who can mentor new nurses, educating them to be better nurses. It's simply too easy to write software. You can always ask someone "have you heard about this software tool, or that social networking website" or something and at least once, they're going to say no. I doubt there are nurses that are coming up with novel nursing techniques so prolific that not even a handful of nurses won't somehow know it.

As a computer technologist, I have to decide what's worth learning, and what's not. I've always been aware of much of what's going on without knowing it extremely well. I remember when the design patterns book came out, but it was many years later before I really got some of the ideas. I've heard of Ruby for a few years now, much before Rails. I've heard of Perl for 15 years, Python for over 10.

Still, plenty of people say "why?". Computer science professors, especially those that are really mathematicians, utter the same. It's what Paul Graham refers to as hackers. Hackers are technologists. They have the desire to create from code. Many computer science academics don't. Programming is a mere tool. They see it as functional. They don't approach programming like great writers approach writing.

I remember a professor, who taught data structures, relating a story of how his colleague complained about having to learn Java to teach data structures. He had done plenty well teaching data structures without every learning object-oriented programming. Did the data structures change? (No, its implementations did). Indeed, some teachers I know don't bother with the language details. They draw pictures and let the students figure out how to translate that to code. It's not worth expending brain cells figuring out what exceptions are in Java and why they should care.

OK, back to Jared. Jared's fairly new to the NFJS tour, but he's already had a book out called "Ship It!". He's now had about half a year's experience giving talks.

I think he has potential, though I'd advise him on the following things (alas, he and ten other people might read this, if even that). He used to work for a company called SAS (I think), which apparently was a mess before he showed up, and fixed things up. As he likes to point out, it's not so much he was a genius as they were really the pits.

I'm sure he's gotten comments to the effect that this is the part of his presentation that he might eventually want to drop, or now that it's going to be in the past tense, then refer it that way. It always seemed like this weird plug for the company. Few of the other speakers seem to mention their job that much, and it sounds a bit better, in my opinion.

The other aspect I think he should work on is figuring out a good catchy subject to cover. I've seen several of Jared's talks. He's done several on tools. I saw Glenn Vanderburg's talk on tools too. They both struck me as not having a great deal of useful take-away. Both talked about the need for version control, continuous integration, bug-tracking, wikis, and so forth. That's all fine and dandy, but really, that's not so interesting.

What is more interesting is to find mistakes people run into when using these systems. How are wikis abused? How can they get out of hand? What can you do about it? What makes a good bug report? How do you avoid over-reporting the same bug? How can testing make you a better coder.

I've wanted someone to talk about unit test by opening up Eclipse, and then showing different ways to set up the unit tests, from sharing the same package, to creating parallel src and test directories, to having completely separate projects. Then, run Corbertura and see the results it produces. Run a profiler to show me how bad things are getting. Tell me that I need better functional tests.

Then, run it in IntelliJ. See how it works there. Maybe I'll think, hey, that's much cooler than Eclipse. Even a good Eclipse vs. IntelliJ would be really cool because (I suspect) both IDEs are so far above and beyond emacs and vi that you want it to do the work. Many people, once they master Eclipse (or even get minimally competent, as Eclipse is a beast), swear they'll never go back. It makes them that much more productive. How could I write a plug-in for Eclipse? How can I run other languages like Ruby in Eclipse?

Eclipse is a great talk in the making.

Sometimes a good talk brings up ideas you've never though of. For example, people have said that you should write software with low coupling and high cohesion. What do those concepts mean? How do I do that?

Jared has a background as a test manager. What makes a good tester? How can a developer learn to be a good tester? How can testing lead to better written code? Show an example of code that's hard to test and hard to read, and show how to make it easier to test, and easier to verify.

Jared has a talk on mock objects. It takes a general approach to how one would use mock objects. In and of itself, it's pretty good, but he doesn't actually build anything from it (well, he does do a password thing). It might be interesting to think about how you could build a simple online store to sell t-shirts, and show how to go about using mock objects to make this work. If there are enough details, a person could go home and set it up themselves.

Perhaps he could then point to a website with the remainder of the information so they can try it out without having to introduce the idea to management.

In summary, I think there are several keys to a great technical talk. First, a person should learn something new that they may not be able to find easily in a book. This may challenge previously held assumptions (i.e., how to test code in Java vs. C). It may compare and contrast against something familiar (Ruby vs. Java). Key to the talk is figuring out what you think your audience knows. Some people assume way too much, some not enough. Finally, it can help if there's something a person feels they can use in the workplace that puts them a little ahead of their coworkers, something that makes them think it was worth giving up a weekend for.