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

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. 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.

52. If you wear shorts...
Gain authority on the field, not on paper
Remember people not to be judgemental

53. If you wear shorts...
Gain authority on the field, not on paper
Remember people not to be judgemental
You can directly go to the beach after work!

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/