Thursday, December 23, 2010

97 Things Every Programmer Should Know

1. Act with Prudence

2. Apply Functional Programming Principles

3. Ask, “What Would the User Do?” (You Are Not the User)

4. Automate Your Coding Standard

5. Beauty Is in Simplicity

6. Before You Refactor

7. Beware the Share

8. The Boy Scout Rule

9. Check Your Code First Before Looking to Blame Others

10. Choose Your Tools with Care

11. Code in the Language of the Domain

12. Code Is Design

13. Code Layout Matters

14. Code Reviews

15. Coding with Reason

16. A Comment on Comments

17. Comment Only What the Code Cannot Say

18. Continuous Learning

19. Convenience Is Not an -ility

20. Deploy Early and Often

21. Distinguish Business Exceptions from Technical

22. Do Lots of Deliberate Practice

23. Domain-Specific Languages

24. Don’t Be Afraid to Break Things

25. Don’t Be Cute with Your Test Data

26. Don’t Ignore That Error!

27. Don’t Just Learn the Language, Understand Its Culture

28. Don’t Nail Your Program into the Upright Position

29. Don’t Rely on “Magic Happens Here”

30. Don’t Repeat Yourself

31. Don’t Touch That Code!

32. Encapsulate Behavior, Not Just State

33. Floating-Point Numbers Aren’t Real

34. Fulfill Your Ambitions with Open Source

35. The Golden Rule of API Design

36. The Guru Myth

37. Hard Work Does Not Pay Off

38. How to Use a Bug Tracker

39. Improve Code by Removing It

40. Install Me

41. Interprocess Communication Affects Application Response Time

42. Keep the Build Clean

43. Know How to Use Command-Line Tools

44. Know Well More Than Two Programming Languages

45. Know Your IDE

46. Know Your Limits

47. Know Your Next Commit

48. Large, Interconnected Data Belongs to a Database

49. Learn Foreign Languages

50. Learn to Estimate

51. Learn to Say, “Hello, World”

52. Let Your Project Speak for Itself

53. The Linker Is Not a Magical Program

54. The Longevity of Interim Solutions

55. Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly

56. Make the Invisible More Visible

57. Message Passing Leads to Better Scalability in Parallel Systems

58. A Message to the Future

59. Missing Opportunities for Polymorphism

60. News of the Weird: Testers Are Your Friends

61. One Binary

62. Only the Code Tells the Truth

63. Own (and Refactor) the Build

64. Pair Program and Feel the Flow

65. Prefer Domain-Specific Types to Primitive Types

66. Prevent Errors

67. The Professional Programmer

68. Put Everything Under Version Control

69. Put the Mouse Down and Step Away from the Keyboard

70. Read Code

71. Read the Humanities

72. Reinvent the Wheel Often

73. Resist the Temptation of the Singleton Pattern

74. The Road to Performance Is Littered with Dirty Code Bombs

75. Simplicity Comes from Reduction

76. The Single Responsibility Principle

77. Start from Yes

78. Step Back and Automate, Automate, Automate

79. Take Advantage of Code Analysis Tools

80. Test for Required Behavior, Not Incidental Behavior

81. Test Precisely and Concretely

82. Test While You Sleep (and over Weekends)

83. Testing Is the Engineering Rigor of Software Development

84. Thinking in States

85. Two Heads Are Often Better Than One

86. Two Wrongs Can Make a Right (and Are Difficult to Fix)

87. Ubuntu Coding for Your Friends

88. The Unix Tools Are Your Friends

89. Use the Right Algorithm and Data Structure

90. Verbose Logging Will Disturb Your Sleep

91. WET Dilutes Performance Bottlenecks

92. When Programmers and Testers Collaborate

93. Write Code As If You Had to Support It for the Rest of Your Life

94. Write Small Functions Using Examples

95. Write Tests for People

96. You Gotta Care About the Code

97. Your Customers Do Not Mean What They Say

No comments:

Post a Comment