The document discusses concerns and best practices for agile developers. It outlines 70 tips from the book "The Pragmatic Programmer" covering topics like continuous improvement, testing, refactoring, and automating processes. It also discusses techniques like test-driven development, design evolution, continuous integration, and ensuring code quality without compromising on quality. The overall message is about caring for one's craft as a developer through practices like refactoring early and often and using common sense.
24. 1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
Care about your craft
Think! About your work
Provide options, don’t make lame excuses
Don’t live with broken windows
Be a catalyst for change
Remember the Big Picture
Make a quality a requirements issue
Invest regularly in your knowledge portfolio
Critically Analyze What You Read and Hear
It's Both What You Say and the Way You Say It
DRY—Don't Repeat Yourself
Make It Easy to Reuse
Eliminate Effects Between Unrelated Things
There Are No Final Decisions
Use Tracer Bullets to Find the Target
Prototype to Learn
Program Close to the Problem domain
Estimate to Avoid Surprises
Iterate the Schedule with the Code
Keep Knowledge in Plain Text
Use the Power of Command Shells
Use a Single Editor Well
Always Use Source Code Control
Fix the Problem, Not the Blame
Don't Panic
"select" Isn't Broken
Don't Assume It—Prove It
Learn a Text Manipulation Language
Write Code That Writes Code
You Can't Write Perfect Software
Design with Contracts
Crash Early
If It Can't Happen, Use Assertions to Ensure That It Won't
Use Exceptions for Exceptional Problems
Finish What You Start
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
Minimize Coupling Between Modules
Configure, Don't Integrate
Put Abstractions in Code Details in Metadata
Analyze Workflow to Improve Concurrency
Design Using Services
Always Design for Concurrency
Separate Views from Models
Use Blackboards to Coordinate Workflow
Don't Program by Coincidence
Estimate the Order of Your Algorithms
Test Your Estimates
Refactor Early, Refactor Often
Design to Test
Test Your Software, or Your Users Will
Don't Use Wizard Code You Don't Understand
Don't Gather Requirements—Dig for Them
Work with a User to Think Like a User
Abstractions Live Longer than Details
Use a Project Glossary
Don't Think Outside the Box—Find the Box
Listen to Nagging Doubts—Start When You're Ready
Some Things Are Better Done than Described
Don't Be a Slave to Formal Methods
Expensive Too Do Not Produce Better Designs
Organize Around Functionality, Not Job Functions
Don't Use Manual Procedures
Test Early. Test Often. Test Automatically.
Coding Ain't Done 'Til All the Tests Run
Use Saboteurs to Test Your Testing
Test State Coverage, Not Code Coverage
Find Bugs Once
Treat English as Just Another Programming Language
Build Documentation In, Don't Bolt It On
Gently Exceed Your Users' Expectations
Sign Your Work
70 Tips
25. 1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
Care about your craft
Think! About your work
Provide options, don’t make lame excuses
Don’t live with broken windows
Be a catalyst for change
Remember the Big Picture
Make a quality a requirements issue
Invest regularly in your knowledge portfolio
Critically Analyze What You Read and Hear
It's Both What You Say and the Way You Say It
DRY—Don't Repeat Yourself
Make It Easy to Reuse
Eliminate Effects Between Unrelated Things
There Are No Final Decisions
Use Tracer Bullets to Find the Target
Prototype to Learn
Program Close to the Problem domain
Estimate to Avoid Surprises
Iterate the Schedule with the Code
Keep Knowledge in Plain Text
Use the Power of Command Shells
Use a Single Editor Well
Always Use Source Code Control
Fix the Problem, Not the Blame
Don't Panic
"select" Isn't Broken
Don't Assume It—Prove It
Learn a Text Manipulation Language
Write Code That Writes Code
You Can't Write Perfect Software
Design with Contracts
Crash Early
If It Can't Happen, Use Assertions to Ensure That It Won't
Use Exceptions for Exceptional Problems
Finish What You Start
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
Minimize Coupling Between Modules
Configure, Don't Integrate
Put Abstractions in Code Details in Metadata
Analyze Workflow to Improve Concurrency
Design Using Services
Always Design for Concurrency
Separate Views from Models
Use Blackboards to Coordinate Workflow
Don't Program by Coincidence
Estimate the Order of Your Algorithms
Test Your Estimates
Refactor Early, Refactor Often
Design to Test
Test Your Software, or Your Users Will
Don't Use Wizard Code You Don't Understand
Don't Gather Requirements—Dig for Them
Work with a User to Think Like a User
Abstractions Live Longer than Details
Use a Project Glossary
Don't Think Outside the Box—Find the Box
Listen to Nagging Doubts—Start When You're Ready
Some Things Are Better Done than Described
Don't Be a Slave to Formal Methods
Expensive Too Do Not Produce Better Designs
Organize Around Functionality, Not Job Functions
Don't Use Manual Procedures
Test Early. Test Often. Test Automatically.
Coding Ain't Done 'Til All the Tests Run
Use Saboteurs to Test Your Testing
Test State Coverage, Not Code Coverage
Find Bugs Once
Treat English as Just Another Programming Language
Build Documentation In, Don't Bolt It On
Gently Exceed Your Users' Expectations
Sign Your Work
1 – Care about your craft
35. 1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
Care about your craft
Think! About your work
Provide options, don’t make lame excuses
Don’t live with broken windows
Be a catalyst for change
Remember the Big Picture
Make a quality a requirements issue
Invest regularly in your knowledge portfolio
Critically Analyze What You Read and Hear
It's Both What You Say and the Way You Say It
DRY—Don't Repeat Yourself
Make It Easy to Reuse
Eliminate Effects Between Unrelated Things
There Are No Final Decisions
Use Tracer Bullets to Find the Target
Prototype to Learn
Program Close to the Problem domain
Estimate to Avoid Surprises
Iterate the Schedule with the Code
Keep Knowledge in Plain Text
Use the Power of Command Shells
Use a Single Editor Well
Always Use Source Code Control
Fix the Problem, Not the Blame
Don't Panic
"select" Isn't Broken
Don't Assume It—Prove It
Learn a Text Manipulation Language
Write Code That Writes Code
You Can't Write Perfect Software
Design with Contracts
Crash Early
If It Can't Happen, Use Assertions to Ensure That It Won't
Use Exceptions for Exceptional Problems
Finish What You Start
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
Minimize Coupling Between Modules
Configure, Don't Integrate
Put Abstractions in Code Details in Metadata
Analyze Workflow to Improve Concurrency
Design Using Services
Always Design for Concurrency
Separate Views from Models
Use Blackboards to Coordinate Workflow
Don't Program by Coincidence
Estimate the Order of Your Algorithms
Test Your Estimates
Refactor Early, Refactor Often
Design to Test
Test Your Software, or Your Users Will
Don't Use Wizard Code You Don't Understand
Don't Gather Requirements—Dig for Them
Work with a User to Think Like a User
Abstractions Live Longer than Details
Use a Project Glossary
Don't Think Outside the Box—Find the Box
Listen to Nagging Doubts—Start When You're Ready
Some Things Are Better Done than Described
Don't Be a Slave to Formal Methods
Expensive Too Do Not Produce Better Designs
Organize Around Functionality, Not Job Functions
Don't Use Manual Procedures
Test Early. Test Often. Test Automatically.
Coding Ain't Done 'Til All the Tests Run
Use Saboteurs to Test Your Testing
Test State Coverage, Not Code Coverage
Find Bugs Once
Treat English as Just Another Programming Language
Build Documentation In, Don't Bolt It On
Gently Exceed Your Users' Expectations
Sign Your Work
61 – Don’t use Manual Procedures
41. 1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
Care about your craft
Think! About your work
Provide options, don’t make lame excuses
Don’t live with broken windows
Be a catalyst for change
Remember the Big Picture
Make a quality a requirements issue
Invest regularly in your knowledge portfolio
Critically Analyze What You Read and Hear
It's Both What You Say and the Way You Say It
DRY—Don't Repeat Yourself
Make It Easy to Reuse
Eliminate Effects Between Unrelated Things
There Are No Final Decisions
Use Tracer Bullets to Find the Target
Prototype to Learn
Program Close to the Problem domain
Estimate to Avoid Surprises
Iterate the Schedule with the Code
Keep Knowledge in Plain Text
Use the Power of Command Shells
Use a Single Editor Well
Always Use Source Code Control
Fix the Problem, Not the Blame
Don't Panic
"select" Isn't Broken
Don't Assume It—Prove It
Learn a Text Manipulation Language
Write Code That Writes Code
You Can't Write Perfect Software
Design with Contracts
Crash Early
If It Can't Happen, Use Assertions to Ensure That It Won't
Use Exceptions for Exceptional Problems
Finish What You Start
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
Minimize Coupling Between Modules
Configure, Don't Integrate
Put Abstractions in Code Details in Metadata
Analyze Workflow to Improve Concurrency
Design Using Services
Always Design for Concurrency
Separate Views from Models
Use Blackboards to Coordinate Workflow
Don't Program by Coincidence
Estimate the Order of Your Algorithms
Test Your Estimates
Refactor Early, Refactor Often
Design to Test
Test Your Software, or Your Users Will
Don't Use Wizard Code You Don't Understand
Don't Gather Requirements—Dig for Them
Work with a User to Think Like a User
Abstractions Live Longer than Details
Use a Project Glossary
Don't Think Outside the Box—Find the Box
Listen to Nagging Doubts—Start When You're Ready
Some Things Are Better Done than Described
Don't Be a Slave to Formal Methods
Expensive Too Do Not Produce Better Designs
Organize Around Functionality, Not Job Functions
Don't Use Manual Procedures
Test Early. Test Often. Test Automatically.
Coding Ain't Done 'Til All the Tests Run
Use Saboteurs to Test Your Testing
Test State Coverage, Not Code Coverage
Find Bugs Once
Treat English as Just Another Programming Language
Build Documentation In, Don't Bolt It On
Gently Exceed Your Users' Expectations
Sign Your Work
47 – Refactor Early, Refactor Often
52. 1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
Care about your craft
Think! About your work
Provide options, don’t make lame excuses
Don’t live with broken windows
Be a catalyst for change
Remember the Big Picture
Make a quality a requirements issue
Invest regularly in your knowledge portfolio
Critically Analyze What You Read and Hear
It's Both What You Say and the Way You Say It
DRY—Don't Repeat Yourself
Make It Easy to Reuse
Eliminate Effects Between Unrelated Things
There Are No Final Decisions
Use Tracer Bullets to Find the Target
Prototype to Learn
Program Close to the Problem domain
Estimate to Avoid Surprises
Iterate the Schedule with the Code
Keep Knowledge in Plain Text
Use the Power of Command Shells
Use a Single Editor Well
Always Use Source Code Control
Fix the Problem, Not the Blame
Don't Panic
"select" Isn't Broken
Don't Assume It—Prove It
Learn a Text Manipulation Language
Write Code That Writes Code
You Can't Write Perfect Software
Design with Contracts
Crash Early
If It Can't Happen, Use Assertions to Ensure That It Won't
Use Exceptions for Exceptional Problems
Finish What You Start
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
Minimize Coupling Between Modules
Configure, Don't Integrate
Put Abstractions in Code Details in Metadata
Analyze Workflow to Improve Concurrency
Design Using Services
Always Design for Concurrency
Separate Views from Models
Use Blackboards to Coordinate Workflow
Don't Program by Coincidence
Estimate the Order of Your Algorithms
Test Your Estimates
Refactor Early, Refactor Often
Design to Test
Test Your Software, or Your Users Will
Don't Use Wizard Code You Don't Understand
Don't Gather Requirements—Dig for Them
Work with a User to Think Like a User
Abstractions Live Longer than Details
Use a Project Glossary
Don't Think Outside the Box—Find the Box
Listen to Nagging Doubts—Start When You're Ready
Some Things Are Better Done than Described
Don't Be a Slave to Formal Methods
Expensive Too Do Not Produce Better Designs
Organize Around Functionality, Not Job Functions
Don't Use Manual Procedures
Test Early. Test Often. Test Automatically.
Coding Ain't Done 'Til All the Tests Run
Use Saboteurs to Test Your Testing
Test State Coverage, Not Code Coverage
Find Bugs Once
Treat English as Just Another Programming Language
Build Documentation In, Don't Bolt It On
Gently Exceed Your Users' Expectations
Sign Your Work
30 – You Can’t Write Perfect Software