A Rocket Internet experience @ ForumPHP Paris 2013

15,669 views
15,451 views

Published on

Published in: Technology, Business
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
15,669
On SlideShare
0
From Embeds
0
Number of Embeds
61
Actions
Shares
0
Downloads
35
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

A Rocket Internet experience @ ForumPHP Paris 2013

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

×