Pretty successful attempt to talk funny about serious things. Presented in 2016 on Rivne IT Vacancies Fair hosted by National University of Water Management and Natural Resources.

3. Reference:
The Pragmatic Programmer: From
Journeyman to Master
by Andrew Hunt and David Thomas
Addison-Wesley Professional, October 1999
ISBN-13: 078-5342616224
ISBN-10: 020161622X
http://www.amazon.com/The-Pragmatic-
Programmer-Journeyman-
Master/dp/020161622X
Thanks:
Jeff Atwood aka The Coding Horror

4. Pragmatic adjective prag·mat·ic prag-ˈma-tik - dealing with
the problems that exist in a specific situation in a reasonable and
logical way instead of depending on ideas and theories

5. 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 When Debugging
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. Use Assertions to Prevent the Impossible
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. Workwith 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. Start When You're Ready
57. Some Things Are Better Done than Described
58. Don't Be a Slave to Formal Methods
59. Costly Tools Don't Produce Better Designs
60. Organize Teams Around Functionality
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. English is Just a Programming Language
68. Build Documentation In, Don't Bolt It On
69. Gently Exceed Your Users' Expectations
70. Sign Your Work

9. 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 When Debugging
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. Use Assertions to Prevent the Impossible
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. Start When You're Ready
57. Some Things Are Better Done than Described
58. Don't Be a Slave to Formal Methods
59. Costly Tools Don't Produce Better Designs
60. Organize Teams Around Functionality
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. English is Just a Programming Language
68. Build Documentation In, Don't Bolt It On
69. Gently Exceed Your Users' Expectations
70. Sign Your Work

10. 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 When Debugging
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. Use Assertions to Prevent the Impossible
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. Start When You're Ready
57. Some Things Are Better Done than Described
58. Don't Be a Slave to Formal Methods
59. Costly Tools Don't Produce Better Designs
60. Organize Teams Around Functionality
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. English is Just a Programming Language
68. Build Documentation In, Don't Bolt It On
69. Gently Exceed Your Users' Expectations
70. Sign Your Work

11. 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 When Debugging
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. Use Assertions to Prevent the Impossible
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. Start When You're Ready
57. Some Things Are Better Done than Described
58. Don't Be a Slave to Formal Methods
59. Costly Tools Don't Produce Better Designs
60. Organize Teams Around Functionality
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. English is Just a Programming Language
68. Build Documentation In, Don't Bolt It On
69. Gently Exceed Your Users' Expectations
70. Sign Your Work

12. 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. Remember the Big Picture
6. Invest Regularly in Your Knowledge
Portfolio
7. DRY – Don't Repeat Yourself
8. Make It Easy to Reuse
9. Prototype to Learn
10. Estimate to Avoid Surprises
11. Fix the Problem, Not the Blame
12. Don't Panic When Debugging
13. "Select" Isn't Broken
14. You Can't Write Perfect Software
15. Design with Contracts
16. Crash Early
17. Minimize Coupling Between Modules
18. Don't Program by Coincidence
19. Refactor Early, Refactor Often
20. Don't Gather Requirements – Dig for Them
21. Some Things Are Better Done than
Described
22. Don't Be a Slave to Formal Methods
23. Don't Use Manual Procedures
24. Test Early. Test Often. Test Automatically
25. Find Bugs Once
26. English is Just a Programming Language
27. Gently Exceed Your Users' Expectations
28. Sign Your Work

16. Computing-Tabulating-Recording Company (CTR)

17. https://www.youtube.com/watch?v=QL1dQuK5Wsg
Thomas John
Watson Sr. -
chairman and CEO
of International
Business Machines
(IBM)
“The trouble with every one of us is that we don't think
enough. We don't get paid for working with our feet —
we get paid for working with our heads” (1911)

18. Criminal Procedure Law Section 140.50

19. (code)

26. BWM ZX-6 Concept
3rd year students of Transportation Design School at Turin Based IED (Istituto Europeo di Design)

27. * - although prototyping does not result in “real” solution, there is always a temptation to use it as one ;(
Prototypes may ignore:
- Correctness (use dummy data)
- Completeness (limited functionality*)
- Robustness (no error checking)
- Style (no documentation, even UI)
*YAGNI principle – You Ain't Gonna Need It
Надійність

33. Accuracy: The closeness of a given measurement to its true
value, i.e. whether the measure is correct.
Precision: The stability of that measurement when repeated
many times, i.e. whether the measurement is consistent with
other measurements.
Accuracy – достовірність, Precision - збіжність

39. * - not really, but we are not talking about really specific complex cases here

45. * - Keep It Simple Stupid ;)

51. Keywords:
- Code quality
- Continuous Integration

54. Pragmatic adjective prag·mat·ic prag-ˈma-tik - dealing with the problems that exist in a specific situation in a
reasonable and logical way instead of depending on ideas and theories

55. Pragmatic adjective prag·mat·ic prag-ˈma-tik - dealing with the problems that exist in a specific situation in a
reasonable and logical way instead of depending on ideas and theories

56. Pragmatic adjective prag·mat·ic prag-ˈma-tik - dealing with the problems that exist in a specific situation in a
reasonable and logical way instead of depending on ideas and theories

57. Pragmatic adjective prag·mat·ic prag-ˈma-tik - dealing with the problems that exist in a specific situation in a
reasonable and logical way instead of depending on ideas and theories

58. Pragmatic adjective prag·mat·ic prag-ˈma-tik - dealing with the problems that exist in a specific situation in a
reasonable and logical way instead of depending on ideas and theories
Apollo 13 За все берется, ничего не удается

59. Tough means we are forever accountable for
what we do or what we fail to do.
Competent means we will never take anything
for granted.
Spaceflight will never tolerate carelessness,
incapacity, and neglect – космічний політ
ніколи не потерпить недбалість,
недієздатність і халатність.

61. Ears, Open. Eyeballs, Click. (2005 documentary by Canaan Brumley) Generation Kill (2008 HBO Mini-series)