The document contains a presentation by Phil Calçado from SoundCloud about best practices for building and supporting software services at scale. Some of the key points discussed include: - Building teams around goals rather than systems and making layers/responsibilities explicit. - Embracing asynchronous workflows and end-to-end testing. - Short-lived branches with automated testing and fast feedback/reverting when needed. - Emphasizing empathy, continuous deployment, 20% exploration time, and measuring outcomes.

1. The Startup Hangover:
Supporting 15 mil users
Phil Calçado - SoundCloud
@pcalcado
http://philcalcado.com
Wednesday, May 23, 12

2. ohai!
i’m phil.
Wednesday, May 23, 12

3. i work here:
Wednesday, May 23, 12

4. Wednesday, May 23, 12

5. Wednesday, May 23, 12

6. law we make up
Wednesday, May 23, 12

7. law we make up
Wednesday, May 23, 12

8. law of nature
Wednesday, May 23, 12

9. law of nature
Wednesday, May 23, 12

10. Wednesday, May 23, 12

11. Wednesday, May 23, 12

12. Wednesday, May 23, 12

13. Wednesday, May 23, 12

14. Wednesday, May 23, 12

15. Wednesday, May 23, 12

16. Wednesday, May 23, 12

17. how to survive?
Wednesday, May 23, 12

18. Wednesday, May 23, 12

19. Wednesday, May 23, 12

20. Wednesday, May 23, 12

21. ~2008
App
Wednesday, May 23, 12

22. ~2011
App
Wednesday, May 23, 12

23. law of nature
Wednesday, May 23, 12

24. no point in
fighting nature
Wednesday, May 23, 12

25. Service A Service B
Service C
Wednesday, May 23, 12

26. teams are built
around goals,
not systems
Wednesday, May 23, 12

27. making layers explicit
Wednesday, May 23, 12

28. a set is a collection
of your sounds
Wednesday, May 23, 12

29. add other users’
sounds to a set
Wednesday, May 23, 12

30. application layer
vs.
domain layer
Wednesday, May 23, 12

31. law we make up
teams are end-to-end
Wednesday, May 23, 12

32. great for
“lateral hires”
to a team
Wednesday, May 23, 12

33. law we make up
you built it?
you support it
Wednesday, May 23, 12

34. automate yourself
out of support
Wednesday, May 23, 12

35. law we make up
async by default
Wednesday, May 23, 12

36. Wednesday, May 23, 12

37. law we make up
pull requests or pairing
as
code review
Wednesday, May 23, 12

38. Wednesday, May 23, 12

39. short-lived
branch
Wednesday, May 23, 12

40. Wednesday, May 23, 12

41. branch goes green
Wednesday, May 23, 12

42. Wednesday, May 23, 12

43. discussion
Wednesday, May 23, 12

44. Wednesday, May 23, 12

45. law we make up
use the best tool for the
job, but practice empathy
Wednesday, May 23, 12

46. no-brainer choices:
ruby, go, scala, java, R
Wednesday, May 23, 12

47. our fav outliers:
node.js, clojure,
haskell, python
Wednesday, May 23, 12

48. law we make up
everyone is an architect
Wednesday, May 23, 12

49. bad calls are ok,
gather feedback fast and
make sure we can revert it
when needed
Wednesday, May 23, 12

50. law we make up
end-to-end testing
before checking in code
Wednesday, May 23, 12

51. impersonators/stubs/
mocks
for everything we can
Wednesday, May 23, 12

52. and we often can
Wednesday, May 23, 12

53. Wednesday, May 23, 12

54. law we make up
product manager
is a benevolent dictator
Wednesday, May 23, 12

55. and they often can code
Wednesday, May 23, 12

56. law we make up
20% time is sacred
Wednesday, May 23, 12

57. just don’t have the whole
team going away at once
Wednesday, May 23, 12

58. law we make up
no multi-tasking
Wednesday, May 23, 12

59. everyone is a singleton
Wednesday, May 23, 12

60. law we make up
“done” means
someone is using it
(a.k.a. continuous
deployment)
Wednesday, May 23, 12

61. cycle time: ~3 days
Wednesday, May 23, 12

62. law we make up
measure all the things
Wednesday, May 23, 12

63. Wednesday, May 23, 12

64. Qs?
Phil Calçado - SoundCloud
@pcalcado
http://philcalcado.com
Wednesday, May 23, 12

65. http://bit.ly/work-at-soundcloud
Wednesday, May 23, 12