Information overload and managing flow
The last day kicks off with a keynote given by Scott Hanselmann, who is one of my “heroes” if you like. I always wanted to see him live, he is usually informative and really funny. Here is some off his tips on the subject:
Effectiveness – doing the right things
Efficiency – doing the things right (jumping off a cliff in a efficient way :))
Triage – sort information. Don’t leave things in your inbox
Do it – drop it – delegate it – defer it = pick one.
Sort your data streams (twitter, email, colleague) into Signals and Noise
Email that you’re cc:ed on are not as important To:
Mailing list
Don’t check emails in the morning - “If you are the fastest responder to a problem, you will get all the problems.”
Check email three times a day – for 20 minutes each.
You cannot beat the system by putting in more hours.
Use the Pomodoro Technique and schedule your work (emailing, phoning, blogging, coding etc.)
Audit your input and streamline it.
“You can’t cut if you don’t measure” – Scott Hanselmann
Tools
- Rescue Time – introspective retrospectives
- 43 folders looks quite messy but powerful
- Sync to paper – check out http://pocketmod.com/
- Write things down that you want to do during a week. And check that the list is done or not at the end of the week
- Evernote
- Remember the milk instead of todo.txt
- Use email rules as above (to:/cc: and calendar invites)
This was very funny and informative. The funniest is that he did basically the same as the Zen-guru Marc Lesser. But oh so different…
The Pair Programming Show
This promise to be great. The first slide says “How to teach pair programming?” It looks to be, just as the title, as a show. With props and the whole thing – nice. The presentation is done by Niclas Nilsson and Hans Brattberg
Also they promise to show some of the bad things that we can experience when teaching/learning pair programming.
Pair programming is about; communication, learning and communication. So be patient, split time with keyboard equal, talk, not show. It’s hard! But the only way to get everybody up to speed.
Without an engaged navigator you don’t collaborate and share mind. Then you get any of the advantages of pair programming. A complicated operation is always performed with two doctors. Would you rather have one?
There are now giving some great points on why pair programming is feasible and economical. For example this chart.
It’s easier to stand up for code quality and not “hacking” when you are two people together… Also it’s harder to hide technical debt.
They had an excellent summary slide of benefits with too much for me reloop here.
Breaking out of dependency hell
This talk is given by a tired Ayende. He has promised to use his designated victim method… Better stay alert.
He talked about the use Dependency Injection, Inversion of Control containers and Convention over configuration to manage solution complexity.
Using a Inversion of Container will make us feel like you lose control of your dependencies. And that is the whole idea – if you micro-manage your dependencies will give you a static system that is hard to change (Open-Close-principle, open for extension but closed for modification).
Another benefit from using an IoC is that you get opportunity to use aspect-oriented programming, to handle cross cutting concerns.