PHP.TO.START 2013 - The Rocket Internet experience

In questo talk si presenta come e' stato gestito il reparto tecnico di una delle startup di Rocket Internet basate a Dubai, Namshi.com. Dalla formazione del team, alle metodologie utilizzate, passando per gioie e dolori nell'esperienza da Lead Developer.

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