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

A Rocket Internet experience @ ForumPHP Paris 2013

on

  • 13,331 views

 

Statistics

Views

Total Views
13,331
Views on SlideShare
13,281
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