You a member of an agile development team planning out your next sprint. You have estimate your velocity at 33. You currently have a load of 32. There is a remaining story that has been estimated as having 2 story points (using a Fibonacci sequence). Would it be a mistake to try to fit it?

The problem with turning over rocks is that there’s usually ugly stuff hiding underneath. You retro every 2 weeks and you list out all the stuff that isn’t working. You diligently collect all the deltas and turn those into actions. You collect all the actions from your retro’s and your post-mortems and you track them in a tool where they sit… forever.

When talking about pair-programming, there is always a discussion how to sell it inside a team to peer developers or even worse to managers. Their killer argument is that two people in front of a single computer result in doubled effort needed to complete software. Let my show you why this is wrong and how the advantages of pair programming outweigh the raw typing speed of two individual developers by far.

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.