Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JDD2014: The responsible developer - Thomas Sundberg

401 views

Published on

Developers are the translators between ideas and code. They translate ideas about functionality to code so the end users can benefit from a usable program. This translation has to be done in a careful and responsible way. It should be done by a responsible developer.
I will discuss the properties of a responsible developer and suggest ways you can improve to become a responsible developer.

Published in: Services
  • Be the first to comment

  • Be the first to like this

JDD2014: The responsible developer - Thomas Sundberg

  1. 1. The Responsible Developer Thomas Sundberg Think Code AB @thomassundberg tsu@kth. se
  2. 2. public int getflunberofnesultsll { Hebfilement searchfield = browser. findEleInent(By. name("¢| "II: sea rchField . sendKeys ( "selenin-") : searchField. subnit( I : int tineoutlnseconds = 10: Hebbrivenvlait wait = new Hebbriverflaitlbrowser, time0utInSeconds); Hebfilement searchResultArea = wa1t. untill(Funct: i.on) (driver) -> { return driver. findEleInent(By. .id("1rIs")); }); List<HebEleInent> result = searchResultArea. findfileinentslay. tagNauIe("l1"l); return result. sizel ):
  3. 3. — 30107130 ‘S .427‘
  4. 4. An ordinary person with a passion for programming, who want to do a great job
  5. 5. Mindset
  6. 6. Embrace change
  7. 7. Not a utopi to divide a problem into smaller parts
  8. 8. Will program even if it isn't paid
  9. 9. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockbum Ron . Iefi‘ries Jeff Sutherland Ward Cunningham Jon Kem Dave Thomas Martin Fowler Brian Marick
  10. 10. Communication
  11. 11. Communication Uses the language of the customer
  12. 12. Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  13. 13. Ir%KL&. l LI’ 411%? SCI L15? €Il¢I' $1 LlK&L. I«ILO Working software is the primary measure of progres Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. A4 I ' n I 41 g I‘
  14. 14. The 4 rules of simple design ~ Tests passes Express intent « l| o duplication ~ Small 3.. ..
  15. 15. How do you build a system?
  16. 16. Incremental, adding piece by piece?
  17. 17. Paint by number
  18. 18. Iterative, build and evaluate, build more and change and evaluate
  19. 19. . Jeff Patton
  20. 20. Divide and concur
  21. 21. The Unix way
  22. 22. Solves one problem Can be combined | s|wc-|
  23. 23. if i / /I; el
  24. 24. Small tasks
  25. 25. Small solutions Is wc
  26. 26. The better way to future proof a system I
  27. 27. Unix has been around a long time. ..
  28. 28. 1973 mg an--—-—v]__ nun, I900 — u~u~u~u————— J 1981 im . __, g, .i was an-. ... u,_j :1 was j. v-mo-nu. ’ IUI6 -nu. -u-. . . _. --. I037 _ Assn man 191! | __. ,_, ._. # 1% men . ... ... ... .. 1990 mi —- I--I 1991 1993 I996 I995 I996 I995 Ill! ) 1 i. ..-‘an’ mu . ... _m l . —u--—. 211]! flu) -nu anus . ... i.. u. —. . . ... .., .. ... .,. ..,
  29. 29. How do you build a system?
  30. 30. Walking skeleton
  31. 31. Vertical slices it IIIIII
  32. 32. I-IO‘-“V TO BUILD r‘-ll? ‘-Hl~IUrI ‘~/ I.! .=l’-JLE PRODUCT NOT LIKE THIS A . “ . - 1 .1 LIKE THIS
  33. 33. Simple code is better than smart code
  34. 34. Simple code on smart data (structures) instead of smart code on simple data (structures) A hash table could be smarter than a linked list
  35. 35. istead of simple data (structures) A hash table could be smarter than a linked list
  36. 36. Sharing and learning
  37. 37. Pair programming
  38. 38. Shared code ownership
  39. 39. Sharing and learning
  40. 40. Mentoring other devs You must understand it before you can explain it
  41. 41. ntoring other devs You must understand it before you can explain it
  42. 42. Constantly learning
  43. 43. Win - Win You learn as long as you have students
  44. 44. Want to know that it works
  45. 45. Constantly testing
  46. 46. Constantly testing Writes code that tests code
  47. 47. Write test code first Test Dri eeeeeeeeeeee nt
  48. 48. Test Driven Development
  49. 49. Can keep the code clean
  50. 50. Code is written once
  51. 51. Read and maintained during a long time
  52. 52. Readability simplifies maintenance
  53. 53. The tests must be cleanest Understanding the tests means that you can understand what the system should do
  54. 54. e tests must be cleanest Understanding the tests means that you can understand what the system should do
  55. 55. Clarity always trumps DRY (in a test) Aslak Hellesray, 2011-10-06 (DRY — Don't Repeat Yourself)
  56. 56. Automated acceptance criteria
  57. 57. Outside in
  58. 58. Avoid testing implementation details
  59. 59. Focus on the high level, don't get lost among the details
  60. 60. Scenario: Sign up with a valid e-mail address Given I want to sign up to receive important market information When I enter a valid e-mail address Then should I get a welcome message
  61. 61. Always able to keep an eye on the overall picture
  62. 62. Clean code
  63. 63. The boy scout rule Always leave the code in a better shape than you found it
  64. 64. Refactoring
  65. 65. What does refactoring mean?
  66. 66. It does not mean "Improving the code"
  67. 67. Refactoring means "Improving the code while maintaining the "functionality"
  68. 68. I| o need for (large) rewrites Rewrites are done in small steps with maintained functionality
  69. 69. 3r (large) rewrites Rewrites are done in small steps with maintained functionality
  70. 70. Delivering value
  71. 71. Deploy often
  72. 72. I/ I/III/ 'g
  73. 73. Why? The only way to deliver features to our customers A prototype is worth a thousand words
  74. 74. may to deliver features to our customers A prototype is worth a thousand words
  75. 75. Build the system often, after each commit
  76. 76. Continuous Integration
  77. 77. Keep the build green
  78. 78. Keep the build green Fix broken builds immediately
  79. 79. . ‘ 1 I la‘: ‘II . — I 0: - I ' I I clldw I II I ‘. 7 I I I In I l I I IN I . ‘I: I II I I. .II . non. .. I . I I . .. I . I I . l ll ‘tv. I I ' III N I . {I I . . III I 1 — - . ' I . I . .. I . I
  80. 80. Commit and run is illegal
  81. 81. Continuous Integration
  82. 82. Deliver deployable artefacts A| AIn/ Q l(nnn tho hnrln in 2
  83. 83. Deliver deployable artefacts Always keep the code in a deployable state
  84. 84. Feature switches Hides stuff that's not ready yet
  85. 85. Deploy often
  86. 86. I/ I/IIII I I»;
  87. 87. Never before you go home
  88. 88. Before lunch, early in the week
  89. 89. early in the week Deploy often means deploying small things
  90. 90. Scary to deploy large things Iln I15
  91. 91. No heroes Not brave
  92. 92. Deploy often
  93. 93. II , t
  94. 94. Automated
  95. 95. Laziness wins in the end Viktor Olsson, bass player, arranger and Manual deployment is developer, August 2014 - boring - error prone - stupid
  96. 96. Manual deployment is -bonng - error prone - stupid
  97. 97. Easy to operate Simple to deploy Reread new properties Good logging
  98. 98. Doesn't scare users with bad error messages
  99. 99. "II ‘-‘I I I’. I tfli «I I —l I - , — l I l I I I I I ’/ .."‘. :‘r ‘I J! ‘ ‘ I i, ‘n ', I It , .' . _ 0- , I ~l . "I I ‘I _ 3- II t 0 V I W V l , l '| I ~ ‘ M1591) " I l I I .1- “ll n_ I ‘ I ~, I lfivr ‘I . ‘ .9 ~ . . l_. ‘pl g] L 5 . . I‘-‘ I ' I-‘ ’ I I ‘ ‘I I5, I _ . - I_ I I‘; A . T »_ . Ih. 11- ' ' pl” 4 r I /4 - M. ‘I “ I “ ‘ — — '— ' ". ‘°'> ~, ..'y. «-I I . . . I - J" J’ ' ’ . uu-I . ,,. _‘, “ l ,1 l- flap . . ‘I H . ,x, ,5T . < -‘~ - , . ‘. . U’ St I. l “I I . nun’. l;1.ll_ H. l . ll ll “l gI: g.'. ‘, -01.1"" . . . I , '?. '.*. ‘—iiL"' »'; :1s§'-'-'-i' I I ' ‘I’-'<'--I: - . v : ;n‘Y’]P’I
  100. 100. Constantly learning
  101. 101. Bad news if you prefer status quo
  102. 102. New techniques
  103. 103. New tools
  104. 104. Customers/ Users domain
  105. 105. Tooling
  106. 106. Isn't fooled by sexy tools or framework
  107. 107. Still need to think for yourself
  108. 108. Use the best tools you currently know
  109. 109. CI ILIy fI ILIVV Always be on the lookout for better tool;
  110. 110. A poor craftsman blames the tools, a worse don't even realize how shitty his tools are
  111. 111. r' ’I
  112. 112. Domain knowledge
  113. 113. Divide and concur given our current knowledge
  114. 114. Then do it again with our new knowledge We probably learned something
  115. 115. new knowledge We probably learned something
  116. 116. Guesstimates
  117. 117. Hard and always wrong You underestimate the complexity of the problem and overestimate your own capabilities
  118. 118. 1d always wrong You underestimate the complexity of the problem and overestimate your own capabilities
  119. 119. A WM. ¢. .___ , u. ::; §¢5=r~g_ . . l. - W43 1) ill l). ca°. 5
  120. 120. What you are doing haven't been done before Done or Don't know
  121. 121. Done or Don't know
  122. 122. Being responsible does not mean doing as you are told; that's obedience
  123. 123. Being responsible means doing what we know is right
  124. 124. C“/ flfl/ //(/ /7* (‘E3/r/ /i’«j/ /((1/ea’/2/'2 R i, in‘, the b. .r. A s aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships That is, in pursuit of the items on the left we have found the items on the right to be indispensable. I '. -0:>9.lhu Jndur '~*'1cd, th. .s st. :.un1m'. r: '..1) be in‘-cly _ rd in any funzi, bu: only in . ts mtin-I) zhm.1g‘r. '. l.l. - notio. -.
  125. 125. er "2 A s aspiring Software Craftsmen we are raising the bar of ‘Q-‘_: professional software development by practicing it and helping '3, others learn the craft. Through this work we have come to value: ' Not only working software, ‘ ' _'7 but also well-crafted software ‘*7; Not only responding to change, i but also steadily adding value -, _‘ 2%: Not only individuals and interactions, but also a community of professionals Not only customer collaboration, - { but also productive partnerships That is, in pursuit of the items on the left we have found the _: items on the right to be indispensable.
  126. 126. /
  127. 127. Action points: to Attend Global Day of Code Retreat 15 November to Try TDD ~ Try Pair Programming « Get a GitHub account and share a pet project
  128. 128. The Responsible Developer Thomas Sundberg Think Code AB @thomassundberg tsu@kth. se

×