Still on my frenetic audio book sprint I finished in 2 weeks :
Crucial Conversations
Made to Stick
The Goal
The 7-Habits Of Hightly Effective People
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 listening to Pamela Slim’s” Escape from cubicle nation”. And I’m reading “Strength finder 2.0”.
And you ? What are you listening ? If you are following the PMBA program, what is you strategy ? Do you read by price/availability or just in random order or by category ? I’m really curious about it.
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.
To know how to tell a story read : La dramaturgie by Yves Lavandier.
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.
Here is the list of sites for free stock photos the author gives :
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 ?
[avhamazon locale=”FR” asin=”2501049837″ linktype=”text” picsize=”medium”] ne fait pas partie du Personal MBA, et je l’ai lu avant de connaitre ce principe (merci @Nat).
You have to read “Refactoring To Patterns” from J.Kerievsky because :
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 ?
Il faut avoir lu “Refactoring To Patterns” de J.Kerievsky parceque :
1. Les design patterns c’est bien mais…
Le projet commence. On lit les spécifications (quand il y a en a, ou qu’elles font plus d’une page), on se penche sur son GribouilleTop et on commence la conception.
Et puis arrive le moment fatidique où on se dit : “Trop bien! Je vais mettre un singleton ici, 3 fabriques abstraites là et un flyweight à cet endroit”.
Normal, les spécifications manquent ou bien on est juste méfiant (et on a raison). Donc on se blinde. En plus ça montre aux autres qu’on connait les patterns sur le bout du clavier. La classe.
Fin du projet (=date prévue +150%) :
Collègue
Dis-moi, Machin, ça sert à quoi tout ce système ?
Jb
Au cas où !
Perdu.
Le déboguage est compliqué, personne ne comprend rien et surtout pour ajouter une option le collègue réinvente la roue, sans passer par votre super implémentation.
C’est ce que l’auteur appelle l’over-engineering (la sur-conception).
A noter que la même chose est possible dans l’autre sens : l’under-engineering (la sous-conception). Dès qu’on veut rajouter une option il faut tout casser.
Voilà pourquoi :
2. …le refactoring vers les patterns c’est mieux !
C’est tout l’argument de ce livre. D’abord, ne pas attendre pour modifier sa conception que la fin du projet arrive. Ensuite parce que c’est normal ! Un produit évolue, et on ne peut pas penser à tout.
Les patterns apparaissent beaucoup plus clairement quand on a commencé à se plonger régulièrement dans le code, et moins au début.
3. Vous n’êtes pas obligé de lire le livre dans l’ordre.
Et ça c’est plutôt cool. Parce que même si, entre nous, on s’endort moins qu’en lisant d’autres livre de ce style, c’est quand même sympa de pouvoir étudier tous ces patterns au moment ou ils sont le plus parlant pour nous.
Vous pouvez lire :
dans l’ordre des pages,
par ordre des exemples (l’auteur donne une table des chapitres qui utilisent le même exemple),
par pattern,
par problèmes de conception.
Et le tout reste très clair. Vraiment bien.
4. Les chapitres sont très bien structurés (parfois trop)
Dans chaque chapitre on trouve :
Un résumé sous forme de schéma avant/après le refactoring et dans quels cas appliquer ce refactoring.
Une longue description (Motivation) sur les pour et les contres (avec beaucoup d’honnêteté) de ce refactoring et un résumé à la fin.
Une section “Algorithme”(Mechanics) qui décrit vraiment très génériquement comment appliquer pas à pas le refactoring. Par exemple : renommez la fonction, puis retirez cette variable, compilez et testez, puis collez cette variable ailleurs etc… Cette section peut être évitée à la première lecture (ce que j’ai fait puisque l’auteur nous y invite) et on y perd rien. Je pense que si on collait tous ces algorithmes dans une application on obtiendrait un plugin Eclipse de refactoring, tout simplement.
Un exemple : entre nous la meilleure section parceque…
5. Pour une fois les exemples ne sont pas “foo” et “bar”.
Les exemples sont des applications et des cas réels que l’auteur expose largement. On les retrouve tout au long du livre et ils sont très clairs. C’est assez rare pour être souligné.
6. En conclusion.
Ce qui est plaisant c’est que l’auteur reconnait qu’il y a des cas ou reconçevoir en pattern n’est pas utile, ou trop lourd. C’est rassurant et honnête. Du coup on lit sans culpabiliser de ne pas y avoir pensé plus tôt. D’ailleurs, il est toujours temps de faire du refactoring. C’est justement le principe.
Question pour ceux qui travaillent en Agile : est-ce qu’on est plus enclin à pratiquer le refactoring que dans une gestion de projet classique ?
Et vous ? Pratiquez-vous le refactoring intensif ? Pas trop peur de tout casser ? Vous en avez le temps ?
Because the author is good at presentations, not books. A lot of the pages seems to fill in the blank between good presentations examples.
A simple way to avoid bullets is to take each bullet and put it on a slides.
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.
