The rocket internet experience @ PHP.TO.START 2013 in Turin

8,172 views

Published on

Tales from a development team working for one of Rocket Internet's venture in Dubai.

Published in: Technology

The rocket internet experience @ PHP.TO.START 2013 in Turin

  1. 1. A ROCKET INTERNETEXPERIENCE
  2. 2. AGENDA 1. Context 2. Responsibilities 3. Building the team 4. Get started 5. Adapt 6. Mutate 7. Delegate 8. BONUS
  3. 3. 1. Context
  4. 4. 1st April 2012
  5. 5. 2. Responsibilities
  6. 6. Strive towards excellence
  7. 7. No
  8. 8. Make things work
  9. 9. TDD is useless
  10. 10. Automated tests are useless
  11. 11. Symfony2 is useless
  12. 12. PEOPLE, FFS!
  13. 13. 3. Building the team
  14. 14. You cant make everyone you know relocate
  15. 15. You cant relocate your company
  16. 16. How to hire a very good (middle-eastern) php team?
  17. 17. HIRE THE YOUNG
  18. 18. They forget about their watchesand are usually attracted to new technologies
  19. 19. Moreover, there is no big bias.
  20. 20. SPECIFIC TARGETS
  21. 21. "If our people cant use Symfony2 in one week, theyre fired"
  22. 22. Test their goals and their approaches,as they will probablyunderstand and get to play with a lot of cool techs with you
  23. 23. IGNORE CVs
  24. 24. How many PHP indians companies are out there?
  25. 25. How many of them do you know?
  26. 26. We are biased
  27. 27. Ask for partial overtime
  28. 28. No one expects everyone to know about everything, that is why we hire people and train them
  29. 29. Training has a cost that both the employer and the employee have to split
  30. 30. Means overtime forchanging labels its useless, of course
  31. 31. but OT is fine, get over it
  32. 32. Its a matter of what both partsoffer for / in those extra-hours.
  33. 33. Pyramid interview
  34. 34. Who is Frederick Brooks?
  35. 35. What is the second-system effect?
  36. 36. What does PEAA mean?
  37. 37. What is a data mapper?
  38. 38. Why is it cool?
  39. 39. Why is OOP better than procedural code?
  40. 40. What happens when you hit enter in the browser bar?
  41. 41. ...and so on.
  42. 42. Surprise them
  43. 43. An interview is always a good opportunity for learning.Given that you can effectively teach stuff with the pyramid interview...
  44. 44. ...wear shorts if you want.
  45. 45. ...ask how many cabs are out there if you want.
  46. 46. If you ask weird questions...Putting the candidate in a no-comfort zone will let you know how he or she reacts to variable situations and unknown problems.
  47. 47. If you wear shorts...Gain authority on the field, not on paperRemember people not to be judgemental
  48. 48. If you wear shorts... Gain authority on the field, not on paper Remember people not to be judgementalYou can directly go to the beach after work!
  49. 49. Offer fair packages
  50. 50. At the end of it...
  51. 51. 4. Get started
  52. 52. "It takes 3 months to be effectively productive"
  53. 53. Why?
  54. 54. "Because the developers cant understand the code"
  55. 55. Solution #1Fire them all
  56. 56. Solution #1Fire them all
  57. 57. Why dont they understand the code?
  58. 58. "Because the code is not that domain driven"
  59. 59. Solution #2Replace the software
  60. 60. In the next 4 months, we would have replaced ourentire architecture with a RoR application and parts of the architecture with NodeJS...
  61. 61. ...if I was that dumb.
  62. 62. COST / BENEFIT
  63. 63. Know-how and tools for free is something you cant easily drop. Instead of replacing a monolithic approach withanother monolithic approach, you split the system in layers and work on each of those layers.
  64. 64. So, why isnt the code domain-driven?
  65. 65. "Not everyone knows how decoupled DDD works"
  66. 66. And thats perfectly fine.
  67. 67. Imagine Fabien as your boss when you were a Rookie?
  68. 68. Were all born n00bs
  69. 69. Socratic approach
  70. 70. Socratic approachQuestion something
  71. 71. Socratic approachQuestion somethingRaise your thoughts
  72. 72. Socratic approachQuestion somethingRaise your thoughtsLet them elaborate
  73. 73. Socratic approachQuestion somethingRaise your thoughtsLet them elaborateDrown together
  74. 74. Socratic approachQuestion somethingRaise your thoughtsLet them elaborateDrown togetherAccept evidences
  75. 75. Socratic approachQuestion somethingRaise your thoughtsLet them elaborateDrown togetherAccept evidencesReady to move on
  76. 76. The BIB approach
  77. 77. "BECAUSE ITS BETTER!"
  78. 78. Do not change people becauseyou want things to get better. Change things becauseyou want people to feel better.
  79. 79. Do not change people becauseyou want things to get better. Change things becauseyou want people to feel better.
  80. 80. 5. Adapt
  81. 81. "I wanna take 2 weeks of vacation,but I might decided to take an additional week while Im on vacation"
  82. 82. In Your Dreams
  83. 83. Or maybe not?
  84. 84. Different people,different environment, different problems http://geshan.blogspot.it/2012/01/load-shedding-schedule-kathmandu-nepal.html
  85. 85. Dont give anything for granted
  86. 86. 6. Mutate
  87. 87. In ~3 months
  88. 88. In ~6 months
  89. 89. In ~9 months
  90. 90. In ~1 year
  91. 91. Recap
  92. 92. All of this besides day-to-day development
  93. 93. ~3 months: 1 deployment a week
  94. 94. ~6 months: 1 deployment a day
  95. 95. ~9 months: 2/3 deployment a week
  96. 96. ~1 year: ?
  97. 97. "Instead of replacing a monolithic approach withanother monolithic approach, you split the system in layers and work on each of those layers."
  98. 98. SOA
  99. 99. Refactoring your architecture understanding SOA http://odino.org/refactoring-your-architecture-go-for-soa/
  100. 100. A service exists...
  101. 101. Another one might want to deal with the same data...
  102. 102. And ask the first one to compute some data for itself...
  103. 103. And once its done, there might be the chance we want to raise an event...
  104. 104. And monitor if there is a problem...
  105. 105. The paradigm changes
  106. 106. No one is designing Web Services for you anymore
  107. 107. Interfaces are crucial
  108. 108. Software design is crucial
  109. 109. 7. Delegate
  110. 110. A team of 12
  111. 111. A company of ~150
  112. 112. Release management http://odino.org/source-code-workflow-after-3-months-of-github/
  113. 113. Code review
  114. 114. Latter code review
  115. 115. Handling pull requests
  116. 116. Handling pull requests
  117. 117. master / develop / release
  118. 118. master / develop / release
  119. 119. Deployments
  120. 120. Request deployments
  121. 121. Release notes
  122. 122. Advise on release notes
  123. 123. Maintenance
  124. 124. First contact
  125. 125. First contact
  126. 126. Verification
  127. 127. Verification
  128. 128. Escalation
  129. 129. Reduced escalation
  130. 130. Product management
  131. 131. Prioritization
  132. 132. Advise on prioritization
  133. 133. Handle deadlines
  134. 134. Handle Manage critical deadlines
  135. 135. Delegation means...
  136. 136. Faster cycles
  137. 137. More time to pair and teach
  138. 138. Committed team members
  139. 139. Alessandro Nadalin
  140. 140. Alessandro Nadalin odino.org
  141. 141. Alessandro Nadalin odino.org @_odino_
  142. 142. Alessandro Nadalin odino.org @_odino_
  143. 143. BONUS
  144. 144. YOU?
  145. 145. 10. Join us!
  146. 146. Lead Developer
  147. 147. PHP Developer
  148. 148. In Dubai.
  149. 149. namshi.com/careers/

×