Jean-Paul S. Boodhoo

I think slides are really good as long as they are short and few.  Just a few bullet points to keep me on track and tell me at a high level about what you are about to show me with code.

As far as coding on the fly -- I don't recommend it.  Definitely could be some here and there, but the sample app should be very nearly complete.

That said, it depends on the topic.  If you're showing how to write a unit test from scratch, then type it from scratch.  If you're showing how to do something with LINQ, have almost everything else in place.

Too many errors and unexpected things can occur when coding on the fly in front of a group, plus it takes longer and that means less possible depth or breadth to the presentation because so much time is spent typing.

In summary, I'd say:

PPT: 15%

Showing code (w/commentary): 45%

Writing code (w/commentary): 20%

Just talking: 20%

I've seen (4 1/2 out of 5) most of your DNRTV episodes, and I'll say that watching something being built from the ground up helps me MORE than attempting to stare at pre-built code.

What I THINK would help is more diagrams attempting to explain at a high level what you're trying to accomplish. Explain the diagram at the beginning, and return every so often to the diagram to say "hey, we're now implementing THIS BLOB SHAPE HERE" and point it out. A diagram, or a basic outline (or both), would help.

This isn't a strong recommendation, just something I think would help.

JP, they'll always be someone who wants what you don't give them. That's the nature of the beast. I actually got negative points on some of my presentations where I didn't have any powerpoint (which is my preference) because the attendees "had nothing to refer to" and "nowhere to take notes". Go figure.

It's a tough balance between what you want to do and catering to the masses. I don't believe a large number of people would want 50/50 (slides/code) however there are some that want that (as your feedback can attest to). So do you bend to the request of a few? If *everyone* was saying they need slides to get value out of it, I could say yes but I've never seen that.

I soak up information from code and discussions and conversations, but maybe I'm an odd duck. One thing you might want to think about is using code snippets rather than writing it out. Sure, you're a duck on acid when it comes to coding and the screen is a blur, but maybe using snippets will allow you more time to talk about the code and deliver better bang for the buck? Just a thought.

Don't know if there's a formula that works for everyone. I just do my own thing and people eventually get to know how I present. It costs me negative points some times when people want ppt instead of code, but I chalk it up to individualism. That's Comp Sci. Baby!

I can tell that this is already going to turn into a case of "you can't satisfy everyone" just looking at the comments.

I've seen too many disastrous experiences when someone can't recover from coding on the fly to be comfortable with that - it's also unfair to the audience.  Now, that being said (and please don't take this as obseqious, I mean it because I've seen you present) you are one of the few people who doesn't seem to have this issue from what I've witnessed.  That being said, I find it much easier when code is pre-built and steps involved are highlighted piece by piece.  

There are occasional times where one needs to code on the fly (how else can we show a refactoring) but even then I am a fan of having something pretty solid as that is fairest to my audience when I am presenting.  YMMV of course.  Slide deck density for me varies on how high-level the talk actually is.  For an intro level presentation I'm likely to spend more time discussing concepts, patterns etc. first and then using the code to dive into what I've been referring to.

I saw a fantastic presentation at a convention a while back. Lots of coding and no distasters and everybody clapped thinking this guy really has his stuff together. Afterwards someone yelled a big compliment and the guy yelled back - "thank Camtasia!"

Yes, he pre-recorded the whole thing but could pause and go-back whenever he wanted. You really couldn't tell he wasn't typing. It was the coolest thing I ever saw!

Real-time coding rarely works perfectly and just waste everybody's time. Scott Guthrie can't even do it perfectly and he's the planet guru.

I love seeing code on the fly.  It gives so much credibility to the presenter.  The caveat... I need to download the code afterwards, because it is such an intense experience.  I am there and can see each piece of the presentation coming together but once the presentation is over I feel like I just got hit by a Mack truck, when I try to commit all of that experience to memory.  I really like the idea of committing the end result to a public source repository so that I can see the end result as-is.

50% PowerPoint? There's no justification for that. Even if your subject *is* PowerPoint.

If the presenter can pull it off (which you can), I like watching coding on the fly. It's easier to grasp than when someone shows you something all at once. It's like having someone explain an existing codebase to you vs. pair programming on a new codebase.

But if coding on the fly slows you down to much (??!!?), having R# templates or code snippets at the ready would help, as Bil suggested.

I love live-code presentation. The slides are useful to focus on the arguments, but the code is better to understand how really the things are to be done.

Here in Italy we organize some workshop with no slide, we call it "RealCodeDay".

I think Powerpoint should only be used to show the subject title of what you are talking about - no bullet points!

I think a cookery show approach should be taken to the coding. I like to see the intellisense coming up and how the presenter approaches building up a block of code, but once they have scratched the surface its good (in most cases) to switch to 'one you made earlier'.

I attended the Visual Studio 2008 in Dublin recently and the presentation was great - really good speaker and great coding examples - but the powerpoint slides left a lot to be desired - way too complicated. I felt we should have had handouts of the powerpoint and the powerpoint could then have been very simple.

I have never watched a live presentation of yours but I have watched all of your "Patterns" videos on DNRTV.

My own observation is that the videos spend too much time with you writing code. This time in my opinion could better be spent explaining the code if it were already written. If the videos were on TDD then I would understand but they were on "Patterns" which could have been prewritten.

With patterns the emphasis should be on the code that represents the pattern rather than on the method (TDD) you used to code it.

I hope this helps

JP - In the the context of the DNR TV venues where I've seen you present, a PowerPoint would have only been a distraction.  It was far more instructive to see you code things up as you relayed the objectives and justifications for each design as you progressed.  The great thing about that presentation style is that an overall rhythm is obtained and more is learned as the focus remains on the code.  If you switched to a slide or two, then back, the mind has to alter paces and I think you would not learn as much.  The advantage of the screencasts is that I can rewind and replay if I've missed a point.

In a live presentation I would think swapping between PowerPoint and coding would still be distracting.  Also, I would not want to glance down at a handout, miss something you've covered on your screen, etc.  That said, maybe you can frame things up on 2-3 slides that detail your goals, turn off the slide, and present as you do so well.

I like on-the-fly coding when the presenter is recreating some code he knows already works.  I also don't mind the presenter demonstrating poor design choices and then showing how to resolve them in code.  However, watching someone struggle through simple compilation errors or wading through code completion to try and find the method he knows "has to be there" is awful.  Likewise, going off on a tangent to answer the question of one audience member can be excruciating if your answer doesn't benefit the rest of the audience or is off topic for the presentation.  This is particularly true if the presentation is short (around an hour); the audience can come away feeling their time was wasted.

JP

  I have a question about the session....

Was this session a conference session or was the session part of one of your week long classes?

What was the topic ?

The code 'IS' the design so seeing more of it is better.  

Whether there should be more coding vs more pre-built examples.... I'd say pre-built code 'snippets' that are too complicated to explain, and at the very least type all the 'glue' code that shows how everything fits together.

As for PowerPoint, at least include a few to show agenda, high-level design, subsections of the design diagram if needed, and additional resources (presenter's contact, code download location, etc.).

JP,  ++  for ,say 70%-80% of real-time code w/ commentary. I think, though, that the biggest factor in deciding how your teaching time should be distributed is the level of your audience - something difficult to know ahead of time. The more someone is at the beginning of the learning curve, the more he needs to see concrete examples. Some topics obviously lend themselves more to real-time coding with commentary, e.g. TDD/BDD.

By the way, any chance Nothin But .NET will be coming to my town? (Los Angeles)?

@Rod,

The session in question was a generics presentation that I did a last week.

Thanks,

JP

@kklein,

Nothin But .NET will be coming to Los Angeles...... if there is more interest expressed!! Get people to email me letting me know they would be interested and commited to attending!!

Thanks,

JP

I'd say it depends on the presenter.  It does take an outstanding presenter to pull of the no Powerpoint all Demo.  I've really only seen one person who can pull this off: Brad Abrams.

I think the most effective use of PowerPoint/Demo mix I saw was at MIX08 this past week, and it was Scott Hanselman's presentation.  His approach was to show working code and explain what it was doing.  Occasionally, he would alter the code to change the results to make a point.

Personally, I gave a demo about a week ago as a part of a larger presentation, and it focused on working code, but showed some minor changes and how that improved the code.  For larger blocks of code that needed to be changed, I kept the snippets handy so that they could just be dropped in.

Anyways, that's my 2 cents...

JP, the way Nothin But .NET course went was probably one of the best ways to present. No PPT slides distraction, code was flowing and design was obvious, but what is important that all comments made during the coding or explanations provided as we paused to code, were captured along with the recorded screencast recording, which made it possible "to go back in time and relate code to what was said at the moment of it writing". This is the valuable thing, to see the code and  relate to the context it was done with.