Lessons From Becoming an SDK Developer

In this talk, Oscar will share what his experience has been in the transition from being an app developer to become an SDK developer at PSPDFKit: what it has taught him, the challenges he has faced, and how it made him a better engineer. He will outline some simple tips and tricks from the SDK developer perspective that can help any iOS developer, even if they’re not developing an SDK themselves.

Transcript

1. Lessons From Becoming an SDK Developer iOSConf SG 2019 1
2. Oscar Swanros @Swanros oscar@swanros.com iOS Software Engineer PSPDFKit GmbH pdfviewer.io
5. twitter.com/tapirofoto
11. Photo by Iker Urteaga on Unsplash
12. Photo by Johny vino on Unsplash
14. Sounds familiar? ✋
16. ⛑ Congratulations!
21. Building an SDK involves much more than tools.
22. The lessons I've learned
23. • Empathy is your first line of defense. The lessons I've learned
24. • Empathy is your first line of defense. • You've gotta think about design! The lessons I've learned
25. • Empathy is your first line of defense. • You've gotta think about design! • Being patient pays off. The lessons I've learned
26. Empathy
27. Empathy the ability to understand and share the feelings of another.
28. Having empathy is…
29. Having empathy is… • not wasting your users' time.
30. Having empathy is… • not wasting your users' time. • helping them get out of trouble (before they even get into it).
33. If someone is trying to use your SDK…
34. If someone is trying to use your SDK… • are they in a rush?
35. If someone is trying to use your SDK… • are they in a rush? • are you solving something super complicated?
36. If someone is trying to use your SDK… • are they in a rush? • are you solving something super complicated? • all of the above?
37. If someone is trying to use your SDK… • are they in a rush? • are you solving something super complicated? • all of the above?
38. Saving time
39. Saving time • Be as transparent as possible.
40. Saving time • Be as transparent as possible. • Make an effort to feel right at home.
41. Saving time • Be as transparent as possible. • Make an effort to feel right at home. • Don't overcomplicate stuff.
42. Helping out
43. Helping out • Invest in documentation.
44. Helping out • Invest in documentation. • Doing support as a mean to get better.
45. Doing support for an SDK is like code review, but 100x better.
46. Design
47. Design guides our users into the correct way of using our products.
48. Designing…
49. • UI Designing…
50. • UI • API Designing…
51. • UI • API • Architecture Designing…
52. • UI • API • Architecture Designing… • UI • API • Architecture
55. • It is what it is.
56. • It is what it is. • You decide what ships.
57. • It is what it is. • You decide what ships. • Features are not included "by mistake."
58. • It is what it is. • You decide what ships. • Features are not included "by mistake." • It is what it is.
59. • It is what it is. • You decide what ships. • Features are not included "by mistake." • It is what it is. • There's no guarantee what it could be.
60. • It is what it is. • You decide what ships. • Features are not included "by mistake." • It is what it is. • There's no guarantee what it could be. • Users will hold it wrong.
61. Relevant questions…
62. • What will this UI/API imply? Relevant questions…
63. • What will this UI/API imply? • Is this something that can fail? Relevant questions…
64. What will this UI/API imply?
66. let result = component.perform(with: [items])
67. let result = component.perform(with: [items]) objectStore.fetchInBackground(completion: (Result<A, B>) -> Void)
69. What's the implication?
73. In which scenarios won't this work?
74. Distinguish between user errors and programmer errors
75. Distinguish between user errors and programmer errors
76. Distinguish between user errors and programmer errors podtail.com/podcast/fatal-error
77. User Error Programmer Error
78. User Error • Maybe the user can fix it at runtime? Programmer Error
79. User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. Programmer Error
80. User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. Programmer Error
81. User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. •There's no way this will work. Programmer Error
82. User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. •There's no way this will work. •Decide if it's fatal or we can still carry on. Programmer Error
83. User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. •There's no way this will work. •Decide if it's fatal or we can still carry on. •Show a big scary error message. Programmer Error
84. User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. •There's no way this will work. •Decide if it's fatal or we can still carry on. •Show a big scary error message. •Crash. Programmer Error
85. Think like an engineer.
86. Think like an engineer. Meaning, you probably won't read the instructions.
87. Patience
88. Patience the capacity to accept or tolerate delay, problems, or suffering without becoming annoyed or anxious.
89. ⏰
90. Quicker == better
91. ✋
92. "You've got to think more about what you're doing." ✋
93. Rushing things ends up making your customers trust you less.
95. Patience
96. • Is a virtue that you have to consciously exercise. Patience
97. • Is a virtue that you have to consciously exercise. • Not always easy to stay calm! Patience
98. • Is a virtue that you have to consciously exercise. • Not always easy to stay calm! • It pays off. Patience
99. You can only afford to be patient if you've invested in empathy and design.
100. Quicker != better
101. Tips to reach zen
102. • Robust test suite. Tips to reach zen
103. • Robust test suite. • Good documentation. Tips to reach zen
104. • Robust test suite. • Good documentation. • Keep improving your work every time you change something. Tips to reach zen
105. • Robust test suite. • Good documentation. • Keep improving your work every time you change something. • Make sure information is accessible. Tips to reach zen
106. To recap
108. • Be empathetic towards your users.
109. • Be empathetic towards your users. • Make an effort to be conscious about the design decisions you make.
110. • Be empathetic towards your users. • Make an effort to be conscious about the design decisions you make. • Understand that patience is key.
111. Thank you! @Swanros oscar@swanros.com