Agile Practices

While I was reading "Pragmatic Programmers" by Venkat Subramaniam and Andy Hunt, I ran into lots of good quips and quotes. BTW, I really enjoyed reading the book. Very well written and doesnt get into a boring lecture, instead keeps it very short and succinct just like what they preach.
I thought it'd be a good idea to summarize some of them for nailing it further into my head.. and also to remind me whenever I feel like Im getting away from the agile practices.. So here they are in no particular order:

• Fix the problem, not the symptom.
• Quick fixes become quick sand.
• You dont have to be great to get started, but you have to get started to be great.
• Learn iteratively and incrementally; Read voraciously.
• Strech beyond purely technical books and topics (project estimation, communication skills etc)
• Learn the new; unlearn the old (which holds you back)
• Only difference between a rut and grave is its dimensions - Keeping old habits past their expiration date is hazardous to your career.
• Small reachable goals keep you moving forward. (Break down your task into smaller and manageable units of code rather than write one do-all function only to realize later that you misunderstood a key point or the client wants to change the process in few areas)
  
• Keep records of decisions and the reasoning behind them. (log, wiki, issue tracking db, etc)
• One test is worth a thousand expert opinions.
• When writing code, choose readability over convenience.
• Instead of being too opaque or clever, follow the PIE (Program Intentively and Expressively) principle.
• Write code to be clear, not clever.
• Dont complicate the design for the sake of perceived performance or elegance.
• Premature optimization is the root of all evil.
• Elegance is easy to understand and recognize, but much harder to create.
• Develop the simplest solution that works - Incorporate patterns, principles and technology only if you have a compelling reason to use them.
• Keeping balance - A box of cotton fibers isnt helpful when you need a sock. (In the name of breaking down functionality into smaller units, do not fragmentize to such an extent that it becomes ridiculously convoluted to invoke a simple function.)
  
• Maintain a log of problems and their solutions.
• Point your colleagues in the right direction instead of handing them the solution.
  
• Code reviews are useless unless you follow up on the recommendations quickly.
• Knowledge grows when given - if you use your candle to light mine, I get light without darkening you.