Here is the list of my Personal MBA progression so far. It’s close to 25% in 18 months.
Tag: readings
How to finish 4 books in 2 weeks without reading !
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.
Getting Things Done
[avhamazon locale=”US” asin=”0007341113″ linktype=”pic” picsize=”medium”]
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 ?
5 reasons to read “Refactoring To Patterns” by J.Kerivsky
[avhamazon locale=”US” asin=”0321213351″ linktype=”pic-text” picsize=”medium”]
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 ?