Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
A ROCKET INTERNET
EXPERIENCE

Alessandro Nadalin, 22nd November 2013
AGENDA
1. Context
2. Responsibilities
3. Building the team
4. Get started
5. Mutate
6. Delegate
7. BONUS
1. Context
1st April 2012
2. Responsibilities
Strive towards excellence
NO
Make things work
TDD is useless
Automated tests are useless
Symfony2 is useless
PEOPLE, FFS!
3. Building the team
You can't make everyone you know relocate
You can't relocate your company
How to hire a very good (middle-eastern) team?
HIRE THE YOUNG
They forget about the clock and are
usually attracted to new technologies
Moreover, there is no big bias.
IGNORE CVs
How many PHP indians companies are out there?
How many of them do you know?
We are biased
Ask for partial overtime
No one expects everyone to know about everything,
that is why we hire people and train them
Training has a cost that both the employer
and the employee have to split
Means overtime for
changing labels it's useless,
of course
but OT is fine, get over it
It's a matter of what both parts
offer for / in those extra-hours.
Pyramid interview
Who is Frederick Brooks?
What is the second-system effect?
What does PEAA mean?
What is a data mapper?
Why is it cool?
Why is OOP better than procedural code?
What happens when you hit enter in the browser bar?
...and so on.
Surprise them
An interview is always a good opportunity for
learning.
Given that you can effectively teach stuff with
the pyramid interv...
...wear shorts if you want.
...ask how many cabs are out there if you want.
If you ask weird questions...

Putting the candidate in a no-comfort zone will
let you know how he or she reacts to variab...
If you wear shorts...

Gain authority on the field, not on paper
If you wear shorts...

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

Beach after Work!
Offer fair packages
At the end of it...
4. Get started
"It takes 3 months to be effectively productive"
Why?
"Because the developers can't understand the code"
Solution #1
Fire them all
Solution #1
Fire them all
Why don't they understand the code?
"Because the code is not that domain driven"
Solution #2
Replace the software
In the next 4 months, we would have replaced our
entire architecture with a RoR application and parts
of the architecture ...
...if I was that dumb.
COST / BENEFIT
Know-how and tools for free is something you can't
easily drop.
Instead of replacing a monolithic approach with
another mo...
So, why isn't the code domain-driven?
"Not everyone knows how decoupled DDD works"
And that's perfectly fine.
Imagine Fabien as your boss
when you were a Rookie?
We're all born n00bs
Socratic approach
Socratic approach
Question something
Socratic approach
Question something
Raise your thoughts
Socratic approach
Question something
Raise your thoughts
Let them elaborate
Socratic approach
Question something
Raise your thoughts
Let them elaborate
Drown together
Socratic approach
Question something
Raise your thoughts
Let them elaborate
Drown together
Accept evidences
Socratic approach
Question something
Raise your thoughts
Let them elaborate
Drown together
Accept evidences
Ready to move ...
The BIB approach
"BECAUSE IT'S BETTER!"
Do not change people because
you want things to get better.
Change things because
you want people to feel better.
Do not change people because
you want things to get better.
Change things because
you want people to feel better.
5. Mutate
In ~3 months
In ~6 months
In ~9 months
In ~1 year
In ~1.5 years
Recap
All of this besides day-to-day development
~3 months: 1 deployment a week
~6 months: 1 deployment a day
~9 months: 2/3 deployment a week
~1 year: ½ deployments per week
~1.5 years: whenever s**t is ready
"Instead of replacing a monolithic approach with
another monolithic approach, you split the system in
layers and work on e...
SOA
The paradigm changes
A software design based on discrete software
components, "services", that collectively
provide the functionalities of the ...
You typically start with the
infamous web application
which does everything on its own
Then you realize that to provide
a chat system to your users
PHP might not be the best...
And soon you also decide,
to improve performances,
that your frontend should have its own
in-memory persistence, to be fas...
Then, as always...
SCALE.
And eventually, your lead architect
will come up and tell you
that your Java-based chat
sucks and should be
replaced with....
NODEJS
In human-understandable words, SOA is a software design which
embraces splitting a monolithic, totalitarian software
archi...
A backend service exists...
...and a new frontend pops out
Another one might want to deal
with the same data...
And ask the first one to compute some data...
And once it's done, there might be the chance
we want to raise an event...
And monitor if there is a problem...
WARNING
No one is designing Web Services for you anymore
Interfaces are crucial
Software design is crucial
Don’t limit yourself to develop stuff
ENGINEER THINGS
6. Delegate
A team of 12
A company of ~200
Release management
http://odino.org/source-code-workflow-after-3-months-of-github/
Maintenance
Product management
Delegation means...
Faster cycles
More time to pair and teach
Committed team members
...yawn...
Alessandro Nadalin
Alessandro Nadalin
@_odino_
Alessandro Nadalin
@_odino_
Namshi | Rocket Internet
Alessandro Nadalin
@_odino_
Namshi | Rocket Internet
VP Technology
Alessandro Nadalin
@_odino_
Namshi | Rocket Internet
VP Technology
odino.org
Thanks!
Alessandro Nadalin
@_odino_
Namshi | Rocket Internet
VP Technology
odino.org
7. BONUS
YOU?
Join us!
Sr. Software Engineer
In Dubai.
namshi.com/careers/
http://www.youtube.com/watch?v=NThxiu1HGgM
Thanks!
Alessandro Nadalin
@_odino_
Namshi | Rocket Internet
VP Technology
odino.org
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
A Rocket Internet experience @ ForumPHP Paris 2013
Prochain SlideShare
Chargement dans…5
×

A Rocket Internet experience @ ForumPHP Paris 2013

16 099 vues

Publié le

Publié dans : Technologie, Business

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

×