How to be more pragmatic around the choices we make

How to be more pragmatic around the choices we make

As developers we make choices every day such as what framework to use, what tools to use and what browsers to support. All these decisions have a huge impact on both our experience as developers and the users experience when using out sites. Unfortunately these two areas are not aligned so lets have a look at how we can be pragmatic as developers taking into account both our users and developers experiences.

6c8618df1a325d0fb9644ee221086fb7?s=128

Jonathan Fielding

May 01, 2018
Tweet

Transcript

  1. How to be more pragma&c around the choices we make

    Jonathan Fielding @jonthanfielding
  2. A bit about me… • Engineering Manager at Beamly (WE

    ARE HIRING) • Author of ‘Beginning Responsive Design’ • Regular contributor to open source, including SimpleStateManager, Echo.js, FT’s Polyfill Service, Doccy among many projects • My twiKer username is a accidental mis-spelling and is now a username I use EVERYWHERE
  3. ORen as developers we find ourselves making lots of decisions

  4. These decisions can have a huge impact on our project

  5. It can make a huge difference to our user experience

  6. It can have a major impact on the ergonomics of

    developing our applicaUon
  7. The problem is most of the informaUon out there is

    laced with bias
  8. We oRen see developers saying X is beKer than Y

  9. Pledging their allegiance to their framework of choice

  10. and I myself am guilty of this

  11. So today I want to look at how we make

    these decisions
  12. and encourage you to have confidence in the decisions that

    you make
  13. What makes choosing a technology so difficult?

  14. There is a huge amount of choice

  15. None
  16. Each piece of technology tries to solve a set of

    problems that developers face
  17. It's therefore important to choose the technology that is right

    for your project
  18. There is an overwhelming amount of informaUon to wade through

  19. and with so much choice we need to be pragmaUc

    in making our decision
  20. especially since it is difficult to separate fact from opinion

  21. Learning to be pragmaUc

  22. Let's start with a definiUon of pragmaUc

  23. None
  24. To a developer this means to make choices that fit

    within the constraints of our project
  25. What are the constraints?

  26. Knowledge

  27. We first need to consider the knowledge we already have

  28. And then we need to understand limits to what we

    can quickly pick up
  29. We also need to understand what outside knowledge is available

    to us
  30. Time

  31. We are likely constrained by a deadline

  32. This also impacts the Ume in which we can spend

    researching technology choices
  33. Technology

  34. The user's browser might constrain the features that we can

    use
  35. The user's device might add performance constraints

  36. Constraints impact the choices that you make as a web

    developer
  37. and when being pragmaUc you need to make a decision

    that sits within these constraints
  38. How biases can affect our pragmaUsm

  39. Successful developers are those who are able to evaluate all

    potenUal opUons and choose the one that is best for the situaUon
  40. However, good developers oRen fall vicUm to bad decisions

  41. The most dangerous are our unconscious biases

  42. And unless we are acUvely avoiding them then they can

    affect our decision making
  43. We therefore need to acknowledge our biases

  44. Confirma(on Bias

  45. None
  46. This can manifest itself in both how we search for

    informaUon and how we interpret it
  47. To overcome confirma&on bias you need to seek ways to

    challenge what you think you see
  48. Anchoring Bias

  49. https://www.towergateinsurance.co.uk/liability-insurance/cognitive-biases

  50. During normal decision making, we tend to weigh a specific

    piece of informaUon more heavily than other factors
  51. To overcome anchoring bias you need to look more into

    the other technologies
  52. Gamblers Fallacy

  53. https://vivifychangecatalyst.wordpress.com/2017/05/27/random-walk-gamblers-fallacy-and-gamblers-ruin/

  54. If we have had a problem using a technology before

    we might assume that our 2nd or 3rd Ume using it might go beKer
  55. To overcome gamblers fallacy you need to understand why you

    might have failed at using a technology in the past
  56. The Availability Heuris(c

  57. https://www.towergateinsurance.co.uk/liability-insurance/cognitive-biases

  58. If a technology is featured regularly on a subreddit we

    regularly visit, when it comes to making a decision we're more likely to recall informaUon on it which will bias our decision
  59. To avoid this bias you need to ensure you are

    looking across a selecUon of technologies
  60. External Biases

  61. We also oRen encounter other people's biases when carrying out

    our research
  62. In order to separate fact from opinion, we need to

    know what signs to look for
  63. Watch for buzzwords

  64. Look at how the writer talks about other frameworks or

    technologies
  65. See if you could rewrite the arUcle, using the same

    informaUon, to tell a completely different story
  66. “49% of developers agree that React improves their workflow”

  67. “51% of developers agree that React does not improve their

    workflow”
  68. Making a decision

  69. Clarify your project Define a evaluation criteria Evaluate your success

    Implement Research each option Make the decision
  70. Clarify your project

  71. The first thing that we need to clarify is what

    are the user requirements
  72. There are two different kinds of requirements

  73. Func&onal Requirements

  74. Non-Func&onal Requirements

  75. These requirements will vary based upon what the user is

    aKempUng to achieve
  76. A visitor to a website will have different requirements to

    the content editor who manages the content
  77. To understand both types of requirements you need to ask

    quesUons
  78. Who is your user?

  79. What are they trying to achieve?

  80. How is your site being accessed?

  81. Taking the answers from each of our sets of users

    we can define a set of requirements
  82. Aside from our user requirements we also need to clarify

    other details of the project
  83. Who will be working on the project?

  84. How much Ume do you have to complete the project?

  85. Do you have to integrate with any third parUes?

  86. Define a evalua(on criteria

  87. Earlier we looked at the different kind of biases that

    can impact your project
  88. A way to prevent bias is to idenUfy a clear

    evaluaUon criteria
  89. What func(onality do we need from the technology?

  90. Our funcUonality criteria should address all the func&onal and non-

    func&onal requirements
  91. Will this technology work on the devices I have to

    support?
  92. Does this technology support the needs of my users?

  93. What does the technology offer to developers to improve usability?

  94. Does the technology provide good documentaUon?

  95. Does it work around any bugs in the web plaiorm?

  96. How mature is the technology?

  97. How old is the technology?

  98. Are there many other developers using this technology?

  99. How is the technology maintained?

  100. How long will it take to implement using this technology?

  101. Is the technology familiar to you or your team?

  102. It is important to include in your criteria details around

    whether you or your team has had experience using the technology
  103. Having iden(fied evalua(on criteria you should then put together a

    table lis(ng them all
  104. How mature is the technology? Does the it have comprehensive

    documentation Does it meet my performance requireements Does it allow me to build accessible interfaces …
  105. Apply weighUngs to your evaluaUon criteria

  106. Weighting How mature is the technology? 20 Does the it

    have comprehensive documentation 100 Does it meet my performance requireements 20 Does it allow me to build accessible interfaces 100 … …
  107. Research each op(on against the evalua(on criteria

  108. The first step in researching what technology to use is

    to shortlist those you want to evaluate
  109. First ask your colleagues and other stakeholders what technologies they

    want to include in the evaluaUon
  110. Then you will want to use your favourite search engine

    to find others
  111. Having shortlisted your technologies you now need to start researching

    each against the evaluaUon criteria
  112. Evalua(ng the user requirements criteria

  113. Look at open source components built on top of the

    technology
  114. Look at the other websites that use the technology

  115. Evalua(ng Maturity

  116. The easiest way to determine the age of the technology

    is to look at when the iniUal commit was made
  117. None
  118. None
  119. We can then see how acUve the community is by

    looking at issues and pull-requests
  120. None
  121. To determine how many companies are using the technology we

    can look at hiring trends
  122. Hacker News Hiring Trends https://www.hntrends.com

  123. Evalua(ng developer usability

  124. Look at how well the technology is documented

  125. One soluUon for comparing technologies is to build the same

    applicaUon in each one
  126. Doing this ourselves is Ume consuming

  127. and we might not even end up with soluUons that

    suit the framework
  128. This is where we can look at example web apps

    built by the web community
  129. The first of these is todomvc.com

  130. None
  131. None
  132. None
  133. We can then use these examples to see how code

    is structured for a parUcular framework
  134. None
  135. None
  136. We can also do some benchmarking using the chrome devtools

  137. None
  138. None
  139. None
  140. None
  141. None
  142. None
  143. None
  144. Our second site for looking at implementaUons is Hacker News

    PWA hGps:/ /hnpwa.com/
  145. It features different implementaUons for each of the frameworks so

    you can see different approaches
  146. None
  147. The final is the RealWorld example applicaUon hGps:/ /github.com/gothinkster/ realworld

  148. It provides specificaUons for both the frontend and the backend

  149. Focusing on building a full end to end applicaUon

  150. All three of these tools help us to evaluate the

    framework we are looking at
  151. Enabling us to discover the facts we need ourselves without

    the influence of biases
  152. Make the decision

  153. Rule out the riskiest opUons

  154. Discuss with other developers in your team

  155. Agree on what you want to use

  156. Implement

  157. Build your project using your chosen technology

  158. Make a note of any problems you face which you

    can then reflect on later
  159. Evaluate the success

  160. Look at what went well

  161. IdenUfy areas that you are unhappy with

  162. Highlight any technical debt accrued

  163. Summary

  164. Approach choosing technologies you use in your projects with an

    open mind
  165. Make decisions based on the type of project

  166. Consider your users func&onal and non- func&onal requirements

  167. Alongside the ergonomics you want from a technology

  168. I hope you go away feeling confident in making these

    decisions
  169. A special thanks goes out to Charlie Fielding along with

    the folks at Beamly for being the guinea pigs for this talk
  170. Thank you, any ques(ons?