The pragmatic programmer

Summary

Well, this is an excellent book, and one which bears reading a few times I think. Just packed with lots of really excellent useful advice from the trenches. Some of it was a little more hardcore engineeringy than where I am currently at. It's broken up into sections so there are whole areas you can skip over if you're more interested in either the technical / project management etc. parts of things.

  1. Care About Your Craft
  2. Think! About Your Work
  3. Provide Options, Don't Make Lame Excuses
  4. Don't Live with Broken Windows
  5. Be a Catalyst for Change
  6. Remember the Big Picture
  7. Make Quality a Requirements Issue
  8. Invest Regularly in Your Knowledge Portfolio
  9. Critically Analyze What You Read and Hear
  10. It's Both What You Say and the Way You Say It
  11. DRY—Don't Repeat Yourself
  12. Make It Easy to Reuse
  13. Eliminate Effects Between Unrelated Things
  14. There Are No Final Decisions
  15. Use Tracer Bullets to Find the Target
  16. Prototype to Learn
  17. Program Close to the Problem domain
  18. Estimate to Avoid Surprises
  19. Iterate the Schedule with the Code
  20. Keep Knowledge in Plain Text
  21. Use the Power of Command Shells
  22. Use a Single Editor Well
  23. Always Use Source Code Control
  24. Fix the Problem, Not the Blame
  25. Don't Panic
  26. "select" Isn't Broken
  27. Don't Assume It—Prove It
  28. Learn a Text Manipulation Language
  29. Write Code That Writes Code
  30. You Can't Write Perfect Software
  31. Design with Contracts
  32. Crash Early
  33. If It Can't Happen, Use Assertions to Ensure That It Won't
  34. Use Exceptions for Exceptional Problems
  35. Finish What You Start
  36. Minimize Coupling Between Modules
  37. Configure, Don't Integrate
  38. Put Abstractions in Code Details in Metadata
  39. Analyze Workflow to Improve Concurrency
  40. Design Using Services
  41. Always Design for Concurrency
  42. Separate Views from Models
  43. Use Blackboards to Coordinate Workflow
  44. Don't Program by Coincidence
  45. Estimate the Order of Your Algorithms
  46. Test Your Estimates
  47. Refactor Early, Refactor Often
  48. Design to Test
  49. Test Your Software, or Your Users Will
  50. Don't Use Wizard Code You Don't Understand
  51. Don't Gather Requirements—Dig for Them
  52. Work with a User to Think Like a User
  53. Abstractions Live Longer than Details
  54. Use a Project Glossary
  55. Don't Think Outside the Box—Find the Box
  56. Listen to Nagging Doubts—Start When You're Ready
  57. Some Things Are Better Done than Described
  58. Don't Be a Slave to Formal Methods
  59. Expensive Too Do Not Produce Better Designs
  60. Organize Around Functionality, Not Job Functions
  61. Don't Use Manual Procedures
  62. Test Early. Test Often. Test Automatically.
  63. Coding Ain't Done 'Til All the Tests Run
  64. Use Saboteurs to Test Your Testing
  65. Test State Coverage, Not Code Coverage
  66. Find Bugs Once
  67. Treat English as Just Another Programming Language
  68. Build Documentation In, Don't Bolt It On
  69. Gently Exceed Your Users' Expectations
  70. Sign Your Work

Selected quotes from Pragmatic Programmer, From Journeyman To Master - Andrew Hunt, David Thomas - Addison Wesley, The - 1999

On estimates - On the other hand, a diver trapped underwater and running out of air is probably interested in an answer down to the second. What's the value of pi If you're wondering how much edging to buy to put around a circular flower bed, then "3" is probably good enough. [10] If you're in school, then maybe "22/7" is a good approximation. If you're in NASA, then maybe 12 decimal places will do. [10] "3" is also apparently good enough if you are a legislator. In 1897, Indiana State Legislature House Bill No. 246 attempted to decree that henceforth pi should have the value of "3". The Bill was tabled indefinitely at its second reading when a mathematics professor pointed out that their powers did not quite extend to passing laws of nature. One of the interesting things about estimating is that the units you use make a difference in the interpretation of the result. If you say that something will take about 130 working days, then people will be expecting it to come in pretty close. However, if you say "Oh, about six months," then they know to look for it any time between five and seven months from now. Both numbers represent the same duration, but "130 days" probably implies a higher degree of accuracy than you feel. We recommend that you scale time estimates as follows: Duration Quote estimate in 1-15 days days 3-8 weeks weeks 8-30 weeks months 30+ weeks think hard before giving an estimate So, if after doing all the necessary work, you decide that a project will take 125 working days (25 weeks), you might want to deliver an estimate of "about six months." The same concepts apply to estimates of any quantity: choose the units of your answer to reflect the accuracy you intend to convey

What to Say When Asked for an Estimate You say " I'll get back to you"

The O () notation is a mathematical way of dealing with approximations. When we write that a particular sort routine sorts n records in O ( n 2 ) time, we are simply saying that the worst-case time taken will vary as the square of n. Double the number of records, and the time will increase roughly fourfold. Think of the O as meaning on the order

The key to managing growth of requirements is to point out each new feature's impact on the schedule to the project sponsors

he who hesitates is sometimes saved

Landing Pilot is the Non-Handling Pilot until the 'decision altitude' call, when the Handling Non-Landing Pilot hands the handling to the Non-Handling Landing Pilot, unless the latter calls 'go-around,' in which case the Handling Non-Landing Pilot continues handling and the Non-Handling Landing Pilot continues non-handling until the next call of 'land' or 'go-around' as appropriate. In view of recent confusions over these rules, it was deemed necessary to restate them clearly.

If a bug slips through the net of existing tests, you need to add a new test to trap it next time

Books Computing books can be expensive, but choose carefully and they're a worthwhile investment. Here are a handful of the many we like. Analysis and Design Object-Oriented Software Construction, 2nd Edition. Bertrand Meyer's epic book on the fundamentals of object-oriented development, all in about 1,300 pages [ Mey97b ] . Design Patterns. A design pattern describes a way to solve a particular class of problems at a higher level than a programming language idiom. This now-classic book [ GHJV95 ] by the Gang of Four describes 23 basic design patterns, including Proxy, Visitor, and Singleton . Analysis Patterns. A treasure trove of high-level, architectural patterns taken from a wide variety of real-world projects and distilled in book form. A relatively quick way to gain the insight of many years of modeling experience [ Fow96 ] . Teams and Projects The Mythical Man Month. Fred Brooks' classic on the perils of organizing project teams, recently updated [ Bro95 ] . Dynamics of Software Development. A series of short essays on building software in large teams, focusing on the dynamics between team members, and between the team and the rest of the world [ McC95 ]

VisualWorks www.objectshare.com Home of the VisualWorks Smalltalk environment. Noncommercial versions

Page created on 6 Jun 2020