A Rocket Internet experience @ ForumPHP Paris 2013
Upcoming SlideShare
Loading in...5
×
 

A Rocket Internet experience @ ForumPHP Paris 2013

on

  • 13,542 views

 

Statistics

Views

Total Views
13,542
Views on SlideShare
13,492
Embed Views
50

Actions

Likes
6
Downloads
20
Comments
0

3 Embeds 50

https://twitter.com 37
http://www.linkedin.com 12
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

A Rocket Internet experience @ ForumPHP Paris 2013 A Rocket Internet experience @ ForumPHP Paris 2013 Presentation Transcript

  • 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 interview...
  • ...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 variable situations and unknown problems.
  • 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 with NodeJS...
  • ...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 monolithic approach, you split the system in layers and work on each of those layers.
  • 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 on
  • 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 each of those layers."
  • SOA
  • The paradigm changes
  • A software design based on discrete software components, "services", that collectively provide the functionalities of the larger software application
  • 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 faster and you put it into another service
  • 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 architecture into smaller pieces, thus making them independent, loosely coupled and more maintainable
  • 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