Blog‎ > ‎

Compilation of Tips from Pragmatic Programmer!

posted Apr 13, 2015, 3:03 PM by Unknown user
  1. 1. Care about your craft. 
  2. Think! About your work. ← mantra
  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 (and avoid duplication[tip11])
  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 ← lazy code, strict to accept, promise little return
  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 tools 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