Pragmatic Programming

The tensions between business & engineering and some thumb rules of how to be a pragmatic engineer.

1. Pragmatic Programming Vishnu Gopal
2. About Me Programmer, loves to build products. • Around ~15years experience programming. • First job was at SlideShare • Was part of & founded a few startups. • Currently very interested in frontend stuff. • Joined Doist 12th May. • @vishnugopal on Twitter, Github • vishnugopal.com
3. Topics 1. The what & why of pragmatic. A personal definition. 2. Prioritise change: One basic thumb rule to judge “pragmatic” 3. The Pragmatic Programmer book
 4. Innovation Points & NIH syndrome 5. Measure what you want to improve
4. The what & why of pragmatic. A personal definition.
5. Business++ Technology++ Middle way = pragmatic.
6. Business Technology 1. “Good for customer” 2. Brings in revenue 3. A feature that a customer is asking for 4. Good for sales & sales leads. 5. Convincing investors. 1. “Build good software” 2. Reduce tech debt 3. Improve architecture 4. Build team skills. 5. Contributes back to open source.
7. Business >> Technology
8. Technology >> Business
9. Pragmatic might be an answer to this conflict.
10. Business Technology Pick “React” for fast development. Build a marketing landing page using a static site provider Introduce Cypress for integration testing Quickly launch a feature so that we can get featured on Techcrunch Allocate some work in a sprint to fix bugs. Make a specialised white- labeled version of the product just to make the first sale
11. Business & Technology should work hand-in-hand.
12. Business Technology Understand technology problems and fit them into business buckets like “budget”, “roadmap” and “investor decks” Understand business problems and use the right technology pieces to solve them.
13. Business Technology Understand technology problems and fit them into business buckets like “budget”, “roadmap” and “investor decks” Understand business problems and use the right technology pieces to solve them. Pragmatic
14. Business Technology Understand technology problems and fit them into business buckets like “budget”, “roadmap” and “investor decks” Understand business problems and use the right technology pieces to solve them. Pragmatic: “The Middle Way”
15. Business Technology Pragmatic: “The Middle Way” 1. Lifelong search. 2. More “art" that science. 3. It’s ok to zigzag as long as you recognise you are zigzagging & come back to the middle way.
16. Prioritise change: One basic thumb rule to judge “pragmatic”
18. 1. Find out where you are 2. Take a small step towards your goal 3. Adjust your understanding based on what you learned 4. Repeat
19. When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.
20. Example: “My sales team wants to do A/B testing for our landing pages” 1. Code-based static site provider: Jekyll 2. Build an in-house A/B testing solution 3. Switch to a fully-managed landing page provider 4. Find a library that implements A/B testing 5. …?
21. Make future change easy.
22. What are the current & future requirements?
23. Example: “My sales team wants to do A/B testing for our landing pages” 1. I want to track conversions. 2. I want pretty graphs 3. I want to do segment-based targeted pages 4. ..?
24. 1. How much money can I spend? 2. When do I want it to be done?
25. More art than science :)
27. Innovation Points & NIH
29. “You have a limited number of innovation points to spend”
30. Big Rocks = things unique to your product. Small Pebbles = stuff that directly helps your business Sand = everything else.
31. Big Rocks = your core product idea Small Pebbles = Slack, Email, Google Analytics, … Sand = glue that holds everything together.
32. Big Rocks = closed-source “IP” Small Pebbles = outsource everything (open- source or paid) Sand = spend ~10-20% of your dev-budget.
33. Optimize your development workflow so you spend >80% of your development time on the big rocks.
34. Utilize open source. Maybe it doesn’t do exactly what you want, but if it does 80%, and it’s not a big rock, use it as pebbles (outsource) + sand (glue you write).
35. “Develop a voice over IP solution for mobile operators”
36. What is the big rock here?
37. Big rock = the crucial piece that delivers value to customers.
38. Pieces that connect to mobile operator The telephony and call bridging logic The business logic & workflow around voice interaction GUI & backend CRM tools to manage workflows
39. Pieces that connect to mobile operator The telephony and call bridging logic The business logic & workflow around voice interaction GUI & backend CRM tools to manage workflows
40. Pieces that connect to mobile operator The telephony and call bridging logic The business logic & workflow around voice interaction GUI & backend CRM tools to manage workflows Commercial product from a vendor for SIGTRAN connectivity Open source product Asterisk for call bridging In-house developed framework Mix of a Rails CRM library + glue code to pull in data into a database.
41. Big rock != the most technically challenging piece.
42. Big rock = the crucial piece that delivers value to customers.
43. Measure what you want to improve
44. Unless you measure, there is no way to quantify improvement.
45. Lagging measure: directly measures your improvement.
46. Leading measure: measures something that might/will influence what you want to measure.
47. Revenue Lagging measure = cash in bank. Leading measure = number of new sales leads.
48. Software Quality Lagging measure = number of bugs reported in production. Leading measure = coverage% for new code.
49. Some good things to measure for pragmatic programming.
50. 1. Customer satisfaction. NPS, qualitative surveys, …
51. 2. Software Quality Code Coverage, bugs reported, …
52. 3. Usage DAU/MAUs, engagement metrics, …
53. “Customers are reporting so many bugs in production!”
54. Build lagging measures to see the reality of the situation 1. Bugs by customer 2. Severity of bugs 3. Bugs effort estimate 4. Sprint metrics
55. Build leading measures to track influence & change 1. Code coverage for existing code 2. Code coverage for new code 3. Feature coverage for user workflows 4. Defect Escape Rate
56. So that is a small window into pragmatic programming.
57. There was very little about programming in there
58. Levelling up as a programmer = understanding nuances of business too
59. But do read the book. “Rubber duck debugging” “Broken windows theory”
60. Thank you Questions?