Recommended
More Related Content
Similar to A Rocket Internet experience @ ForumPHP Paris 2013
Similar to A Rocket Internet experience @ ForumPHP Paris 2013 (20)
More from Alessandro Nadalin
More from Alessandro Nadalin (20)
Recently uploaded
Recently uploaded (20)
A Rocket Internet experience @ ForumPHP Paris 2013
- 1. A ROCKET INTERNET EXPERIENCE Alessandro Nadalin, 22nd November 2013
- 2. AGENDA 1. Context 2. Responsibilities 3. Building the team 4. Get started 5. Mutate 6. Delegate 7. BONUS
- 3. 1. Context
- 7. NO
- 10. Automated tests are useless
- 12. PEOPLE, FFS!
- 13. 3. Building the team
- 14. You can't make everyone you know relocate
- 15. You can't relocate your company
- 16. How to hire a very good (middle-eastern) team?
- 17. HIRE THE YOUNG
- 18. They forget about the clock and are usually attracted to new technologies
- 19. Moreover, there is no big bias.
- 20. IGNORE CVs
- 21. How many PHP indians companies are out there?
- 22. How many of them do you know?
- 23. We are biased
- 24. Ask for partial overtime
- 25. No one expects everyone to know about everything, that is why we hire people and train them
- 26. Training has a cost that both the employer and the employee have to split
- 27. Means overtime for changing labels it's useless, of course
- 28. but OT is fine, get over it
- 29. It's a matter of what both parts offer for / in those extra-hours.
- 31. Who is Frederick Brooks?
- 32. What is the second-system effect?
- 33. What does PEAA mean?
- 34. What is a data mapper?
- 35. Why is it cool?
- 36. Why is OOP better than procedural code?
- 37. What happens when you hit enter in the browser bar?
- 38. ...and so on.
- 39. Surprise them
- 40. An interview is always a good opportunity for learning. Given that you can effectively teach stuff with the pyramid interview...
- 41. ...wear shorts if you want.
- 42. ...ask how many cabs are out there if you want.
- 43. 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.
- 44. If you wear shorts... Gain authority on the field, not on paper
- 45. If you wear shorts... Gain authority on the field, not on paper Remember people not to be judgemental
- 46. If you wear shorts... Beach after Work!
- 48. At the end of it...
- 50. 4. Get started
- 51. "It takes 3 months to be effectively productive"
- 52. Why?
- 53. "Because the developers can't understand the code"
- 54. Solution #1 Fire them all
- 55. Solution #1 Fire them all
- 56. Why don't they understand the code?
- 57. "Because the code is not that domain driven"
- 58. Solution #2 Replace the software
- 59. In the next 4 months, we would have replaced our entire architecture with a RoR application and parts of the architecture with NodeJS...
- 60. ...if I was that dumb.
- 61. COST / BENEFIT
- 62. Know-how and tools for free is something you can't easily drop. Instead of replacing a monolithic approach with another monolithic approach, you split the system in layers and work on each of those layers.
- 63. So, why isn't the code domain-driven?
- 64. "Not everyone knows how decoupled DDD works"
- 65. And that's perfectly fine.
- 66. Imagine Fabien as your boss when you were a Rookie?
- 67. We're all born n00bs
- 70. Socratic approach Question something Raise your thoughts
- 71. Socratic approach Question something Raise your thoughts Let them elaborate
- 72. Socratic approach Question something Raise your thoughts Let them elaborate Drown together
- 73. Socratic approach Question something Raise your thoughts Let them elaborate Drown together Accept evidences
- 74. Socratic approach Question something Raise your thoughts Let them elaborate Drown together Accept evidences Ready to move on
- 75. The BIB approach
- 77. Do not change people because you want things to get better. Change things because you want people to feel better.
- 78. Do not change people because you want things to get better. Change things because you want people to feel better.
- 79. 5. Mutate
- 80. In ~3 months
- 81. In ~6 months
- 82. In ~9 months
- 83. In ~1 year
- 84. In ~1.5 years
- 85. Recap
- 86. All of this besides day-to-day development
- 87. ~3 months: 1 deployment a week
- 88. ~6 months: 1 deployment a day
- 89. ~9 months: 2/3 deployment a week
- 90. ~1 year: ½ deployments per week
- 91. ~1.5 years: whenever s**t is ready
- 92. "Instead of replacing a monolithic approach with another monolithic approach, you split the system in layers and work on each of those layers."
- 93. SOA
- 95. A software design based on discrete software components, "services", that collectively provide the functionalities of the larger software application
- 96. You typically start with the infamous web application which does everything on its own
- 98. Then you realize that to provide a chat system to your users PHP might not be the best...
- 100. And soon you also decide, to improve performances, that your frontend should have its own in-memory persistence, to be faster and you put it into another service
- 102. Then, as always...
- 103. SCALE.
- 105. And eventually, your lead architect will come up and tell you that your Java-based chat sucks and should be replaced with...
- 106. NODEJS
- 108. In human-understandable words, SOA is a software design which embraces splitting a monolithic, totalitarian software architecture into smaller pieces, thus making them independent, loosely coupled and more maintainable
- 109. A backend service exists...
- 111. ...and a new frontend pops out
- 113. Another one might want to deal with the same data...
- 115. And ask the first one to compute some data...
- 117. And once it's done, there might be the chance we want to raise an event...
- 119. And monitor if there is a problem...
- 121. WARNING
- 122. No one is designing Web Services for you anymore
- 124. Software design is crucial
- 125. Don’t limit yourself to develop stuff
- 126. ENGINEER THINGS
- 127. 6. Delegate
- 128. A team of 12
- 129. A company of ~200
- 131. Maintenance
- 132. Product management
- 133. Delegation means...
- 134. Faster cycles
- 135. More time to pair and teach
- 137. ...yawn...
- 138. Alessandro Nadalin
- 140. Alessandro Nadalin @_odino_ Namshi | Rocket Internet
- 141. Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology
- 142. Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology odino.org
- 143. Thanks! Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology odino.org
- 144. 7. BONUS
- 145. YOU?
- 146. Join us!
- 148. In Dubai.
- 150. Thanks! Alessandro Nadalin @_odino_ Namshi | Rocket Internet VP Technology odino.org