Actually with this method you can rapidely be overwhelmed. You shall :

Only listen in your car (I listen while shaving and dish washing but it’s to much.)

Slow down some times by not listening for one day. Just taking time to think.

Review it by writing a small article on each book. Even if somebody else did it.

Use a spreadsheet or any other mean to keep track of what you read. Otherwise you will loose sense of priority. In my Excel page for the Personal MBA I also put price of the books, and rate my desire to read them from 0 to 3. Then I can sort to determine what will be my next reading/listening.

Read a book in parallel (fiction is a good idea to breathe a little).

I apply only a few of this tips for the moments. But writing them today helps me realize what I should do.

I’m currently reading 10 Days to Faster Reading. It’s great to see improvement while reading. A stopwatch is needed, so I can’t read exactly when I want.

The moments where I have time to read is actualy : in my car, while shaving, while cleaning dishes… That’s when I can’t hold a book, but when my mind is free and I’m alone. The two essential condition to me for reading.

This is why I decided to listen to the books of the PMBA list (at least those I can find in audio form).

I just finished Presentation Zen from the PMBA list (thanks to my local library).

A good coeincidence is that I just went to the Eclipse Day Paris (a tech conference about the Eclipse Platform on which I’m working). I had the occasion to see a lot of good speakers with interesting subjects doing very bad presentations.

I just finished Presentation Zen from the PMBA list (thanks to my local library).

A good coincidence is that I also went to the Eclipse Day Paris (a tech conference about the Eclipse RCP Platform on which I’m working). I had the occasion to see a lot of good speakers with interesting subjects doing very bad presentations.

Don’t use slides, Powerpoint or Keynotes

Just use what you need. Could be slides. Slides are good as a tool.

Maybe you just need to give documents. Maybe just speak. Sometimes I wish I could mime my ideas.

This was a relief to see a recognized book confirm my thoughts on the subject : you don’t have to draw out your Powerpoint each time you want to speak to someone. Just like you don’t have to plan a meeting to work with other people.

Why the visual support does not matter ? Because you tell a story. And people just love stories, not slides.

Lean how to tell a story (not with this book though)

The problem about Presentation Zen is that the author insists on telling a story but gives no clue about what a good story is.

Someday I’ll post about what makes a story interesting or not. In the meanwhile the important principle to know is : story is conflict. If there are no obstacles between the protagonist and his goal, there is no story.

By the way, this is why I don’t understand the purpose of SlideShare. A standalone presentation is not interesting. It should be coupled with Youtube for example. Then you have the slides and the interesting part : the story and the person telling the story. Not just slides.

Buy Pictures

I think the author is payed each times he quotes a certain stock photo site. In every page the site is mentioned. I won’t give the name here. But he has a point : put great pictures in your presentation.

The best is to put them full screen. Just get rid of page number and company logo. Use pictures. Like in a movie. You don’t see the name of the director on the bottom of each shot.

You don’t have to put pictures everywhere just to illustrate each word with a photo. This is a presentation not a rebus.

Never use cliparts again, but don’t use business images either ! People with bright smile, tie and shaking hands are my nightmare.

Read only 33% of this book

Because the author is good at presentations, not books. A lot of the pages seems to fill in the blank between good presentations examples.

You can find good examples also by searching videos of the great presenters.

The book was here to motivate me and formalize some ideas, not much.

Be bullet proof

A simple way to avoid bullets is to take each bullet and put it on a slides.

And instead of reviewing 7 bullets during 7 minutes. Just put 7 slides (with either a picture, a quote,…) and spend 1 minute on each slide.

Don’t listen to your teachers

If someday someone is looking at my old presentations, I’m gonna die. My teachers wanted me so bad to put crazy and useless stuff on my slides. And I listened to them !

Horrible stuffs like :

Page numbers on each slides. And you know why ? To help them criticize me after my presentation by referring to the page number. Just because they won’t listen to me, just note the problems by their pages !

Agenda, or plan of the presentation. WTF ?! This is not a document, it’s a presentation !

Go to a tech conference to see bad examples

I know why this book is called Presentation Zen : because to endure some of the presentations I saw yesterday you gotta be Zen and non-violent.

I heard a first speaker complaining about the lectern. He said “I feel less boring when I’m free of my movement”. How much I understand. This is what I felt when he was speaking. He seemed locked behind a microphone. What a shame.

Another speaker was really good, and I liked his story. But the slides looked like a philosophy homework of a 16 years old teenager : so predicatable and boring (A, A1, A2, A3, B, B1….) He told it himself : “I’m not good at slides”.

For example this man told us a great story about the creation of BIRT and the strategy of Actuate to go Open Source in order to tackle competition. He finished the story by telling that employee of this company are really happy with the decision of the CEO to do that. And sometimes then buy him a tequila to thank him. A good idea could have been to go backward and beginning by putting a Glass of tequila full screen while telling the story.

A third one, was also aware of the problem on his slides but did’n changed a thing ! Strange to note that people know what wrong but don’t change. One of his slides included a huge diagram, impossible to read. And he knew it. He told us. So why keeping it ?

It’s my turn

And maybe I won’t use slides. I must report what I saw at the Eclipse Day. I think slides are not a good idea. Maybe I’m too afraid to fail after all I said…

And you ? What was the last great presentation you saw ? Was there slides ? Share any link here !

Nothing interesting here. Except for some advice or refeflections about self-management.

I went to the WHSmith library the other day. I was looking for some PBMA books to buy. It’s more expensive than amazon. So I took this book thinking it was the real “Getting Things Done”. But it was not the same…

Anyways I read it. Here is what I remember.

The book is divided into short chapters (what I like since I’ve been doing micro-reading lately). I read during breakfast, during a SVN Checkout, during a break…

It’s about managing your time. More than that : it’s about managing risks : if I forget to do this, what is the risk ? Should I do that before ? etc… Intersting approach to time management.

The most useful part is the one explaining this principle : never allow yourself to add something to your todo-list if you can do it NOW.

That’s what I did for this article. I was going for adding it to my todo-list. But I realized it would be easier to write it now quickly.

To quote Rework : Good enough is fine. Go for small victories.

Small articles are better than no article.

And you ? What are you reading lately ? Did you ever buy a book by mistake ?

1. Design patterns are good but…

Project begins. You read specifications (if there are some, or if they are more than one page long), you go to your DoodleTop and you start the conception.

And then comes this moment, you know when you say : “Cool ! I’ll put a Singleton here, 3 abstract factories there and a flyweight over here”.

Of course, specifications are missing or you are just suspicious (and you are right). So you harden and generalize your conception. And of course, it shows all you colleagues that you know your pattern 101.

End of the project (=deadline +150%) :

Colleague A

Hey man, what’s all this stuff in your conception all about ?

Jb

You know : just in case !

Fail.

Debugging is painful, nobody can understand your code, event you and most of all : to add one tiny option your colleague must re-invent the wheel, without using your conception at all.

That’s what the author calls over-engineering.

The opposite exists also and is called (you guessed it) : under-engineering. When you want to add one feature you have to break everything.

This is why :

2. …refactoring to patterns is better !

This is the whole point of “Refactoring To Patterns”. First because you must not wait for the end of the project to refactor and clean the code. Then : because it’s natural to refactor ! A product evolves and specs change over the project time.

Patterns emerge more precisely when project has already started and you spend more time coding.

3. You don’t have to read it from page 1 to 367

Pretty cool. Because even if this book is more a page turner than a lot of the same style, it’s better to study patterns when you really need them, not in your bed during your vacations.

You can read :

in the order of the pages,

in the order of the examples (the author gives a table of all chapters grouped by same examples),

by patterns,

by conception problems.

And it stays clear. Really good.

4. Chapters are really well structured (sometimes too much)

In each chapter you find :

A summary of the problem as a before/after UML diagram.

A long description (Motivation) about pros and cons (with much honesty) of this refactoring and a summary at the end.

A step-by-step (Mechanics) section describing very generically how to apply this refactoring. For example : rename this method, then remove this variable, compile and test, then paste this variable elsewhere etc… You don’t have to read this section at the first time (that’s the authors suggestion). I think that if you’d paste all those steps in an application you’d have an Eclipse refactoring plugin.

An example : the best part because…

5. Examples are not “foo” and “bar”

Examples are real world applications. And the author uses them a lot. So at the end you know perfectly 4 or 5 examples and that’s all. They are clear but not to simple. This is rare enough to note it.

6. To conclude

What’s pleasant is that the authors knows that refactoring to pattern is sometimes overkilling.

This is honest and reassuring. Hence you read without gilt of not having refactor before, because sometimes you don’t need to. And it’s never too late to begin. That’s the principle of on-the-go refactoring.

Question for the readers out there who work with Agile : does refactoring have more space in the Agile methodology ?

And you ? Do you practice refactoring a lot ? Or are you afraid to break everything ? Do you simply have time to do it ?