Building a Culture Where Software Projects Get Done

716 views
566 views

Published on

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1dg9k81.

Greg Brockman shares Stripe's principles powering their software projects and the culture instilled to avoid the usual software engineering traps: failed rewrites, delayed timelines, etc. Filmed at qconsf.com.

Greg Brockman is Stripe's CTO. He has been helping build out Stripe's technology stack since joining as the second employee. He built the initial infrastructure powering the Stripe API and these days works primarily on scaling the team and architecture. Greg studied mathematics at Harvard and computer science at MIT.

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
716
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Building a Culture Where Software Projects Get Done

  1. 1. Building a Culture Where Software Projects Get Done Greg Brockman CTO at Stripe @thegdb
  2. 2. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations /stripe-culture InfoQ.com: News & Community Site • 750,000 unique visitors/month • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • News 15-20 / week • Articles 3-4 / week • Presentations (videos) 12-15 / week • Interviews 2-3 / week • Books 1 / month
  3. 3. Presented at QCon San Francisco www.qconsf.com Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide
  4. 4. We don’t know how to build software
  5. 5. EXPECTED Today LIKELY Disappointing Insane Engineering timelines will slip
  6. 6. System complexity never decreases
  7. 7. Rewrites will always fail (that doesn’t stop people from trying, though)
  8. 8. You are not special
  9. 9. Choose wisely how you’re spending your
  10. 10. Roll your own solution to your hardest problems, not your easiest ones
  11. 11. Balance creation versus maintenance
  12. 12. 5.times {print “Automate”}
  13. 13. Once a bug is triggered, it will keep
  14. 14. Invest in technology to support your rate of change
  15. 15. Tests aren’t for your benefit
  16. 16. Create a technology monoculture
  17. 17. You will have technical debt — Image Credit: Philippe Kruchten
  18. 18. Pick a few standards
  19. 19. Have checks and balances against
  20. 20. Minimize distance to the first production use Time to shard everything: 3 months
  21. 21. Have assumption questioners
  22. 22. Bus factor: not just for bus accidents
  23. 23. Use forcing functions (cautiously)
  24. 24. Have a good launch process in place
  25. 25. Have good post-hoc processes in place
  26. 26. Make collaboration great
  27. 27. Find communication sidechannels
  28. 28. Documentation should not be a primary source
  29. 29. Meetings: useful but costly
  30. 30. Have design dictators
  31. 31. Have lots of remotes or no remotes
  32. 32. Greg Brockman gdb@stripe.com @thegdb
  33. 33. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations/stripeculture

×