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.

1. Preocupações de um
Desenvolvedor Ágil
Paulo Igor

3. Não é apenas CÓDIGO

4. impacta a vida de milhares de pessoas

5. transforma a vida das pessoas

7. “Grandes poderes trazem grandes
responsabilidades” (Ben Parker)

9. Comodidade
Qualidade de Vida
Tempo
…

11. #FAIL

13. Programar é uma arte!

14. Qualidade

15. “Programar é um
processo criativo e
que exige
aperfeiçoamento”
Programar é uma arte!

16. …é necessário praticar!

17. DNA do programador

18. Preguiçoso e criativo!!!

19. “Simplicidade: a arte de maximizar a
quantidade de trabalho que não
precisou ser feito”

20. ...mas funciona!!!

21. Passa a encarar os problemas com naturalidade…

22. Pragmatic Programmer

23. The Pragmatic Programmer

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

26. Técnicas e Práticas

27. Pair Programming

28. Qualidade do Código
“Clean Code” (Uncle Bob)

29. Ta uma bagunça, mas funciona!

30. Agora sim! 

31. Refatoração
“Refactoring: Improving the Design of
Existing Code” (Martin Fowler)

32. Testes

33. Testes Manuais

34. Testes Automáticos
JUnit, JBehave, TestNG, Rspec, Cumcuber, Test::Unit, …

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

36. Automatização

37. Especificação Testável
Concordion / FitNesse

40. TDD / BDD
“TDD - Kent Beck / BDD - Dan North”

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

42. Blindagem do Código

43. Design Evolutivo
“TDD - Kent Beck / BDD - Dan North”

44. Continuous
TDD / BDD
Integration
“TDD - Kent Beck / BDD - Dan North”
(Martin Fowler)

45. Continuous Delivery
(Jez Humble e David Farley)

46. Continuous Delivery
(Jez Humble e David Farley)

47. da qualidade não se abre mão

48. “Arte de
Programar”

49. “controle a força”

50. “Treinar pra quê?”

51. BOM SENSO!!!

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

53. Deixe seu legado!!!

54. Obrigado!
Paulo Igor