Quick recap based on my messy notes from Brighton Ruby 2016. Watch the Brighton Ruby videos for actual details…

1. Brighton Ruby Recap
2016

2. Things I learned and things I liked

3. Warning: It's been several months,
so my recollec3on may be hazy…

4. Lesson 1: don't buy flights that leave at 8am

5. Lesson 2: take
advantage of the
weak pound to buy
an iPad

6. Lesson 3: use said iPad to take
unreadable, handwri3en notes

7. Brighton Ruby
• A one day Ruby conference
• Put together by one person: Andy Croll
• five of the talks are already up on: brightonruby.com
• The Point of Objects by John Cinnamond
• Rails 5 Features You Haven’t Heard About by Sean Griffin
• How We Make SoBware: A New Theory of Teams by Sarah Mei
• Security is Broken by Eileen Uchitelle
• Mary Richards and the Delicate Art of YOLO by Britni Alexander

9. Talks I'd par,cularly recommend

10. The Point of Objects by John Cinnamond

11. The Point of Objects by John Cinnamond
• Moved through the history of compu4ng
• Went through how programming computers went from
physically moving cables around to object oriented programming
• Historical context for why OO programming emerged
• Procedural languages were invented to abstract away from the
machine
• Object oriented programming abstracts away from itself

12. The Point of Objects by John Cinnamond
• Object oriented programming abstracts away from itself
• it's not about the technology
• supplies tools for real people
• helps you stop and think
• delay caring about details
• focus on what you're trying to achieve
• you should protect from change by crea<ng new classes

13. The Point of Objects by John Cinnamond
• For example, if you're crea3ng a registra3on page for a conference
• what you care about is saving a<endee details and crea3ng an
a<endee list
• you don't care about parsing form data
• you can abstract away the ancillary parts un3l you've wri<en
the parts you need
• You should watch the talk, it's really interes3ng !

14. h"p://brightonruby.com/2016/the-
point-of-objects-john-cinnamond/

16. What is Processor? by Sam Phippen
• Runs through how a processor (CPU) works
• How it works, how it processes instruc:ons
• The video hasn't been released yet
• The slides are online, but they're preBy inscrutable without the
actual talk (hBps://speakerdeck.com/samphippen/what-is-
processor)

17. How We Make So+ware: A New
Theory of Teams by Sarah Mei

18. A New Theory of Teams
• About how so+ware is made and how teams are organised
• What's a good metaphor for so+ware development teams?
• What makes awesome teams awesome?
• collabora=ve
• produc=ve
• they build the right thing
• most devs have never been on an awesome team

19. A New Theory of Teams
• Most so'ware projects fail
• nothing of value produced
• 2/3 of projects fail
• and we don't know why
• Fundamentally developers build the wrong thing
• Clean code is not enough

20. A New Theory of Teams
• There are only two hard problems in compu6ng…
• cache invalida6on
• naming things
• (off by one errors)

21. A New Theory of Teams
• cache invalida,on
• when to invalidate
• when to cache
• not a technical problem
• a people problem
• naming things

22. A New Theory of Teams
• cache invalida,on
• naming things
• o2en seen in jQuery/JS: function(data) { … }
• what is it for?
• understanding goals is hard
• also a people problem

23. The only hard problem in so1ware is
people
— Sarah Mei

24. A New Theory of Teams
• Hard people problems
• Hiring: one diva ruins the whole team
• Turnover: one person leaving is hard on the teams
• Growth: the mythical man month problem
• Produc3vity: hard to measure

25. A New Theory of Teams
• Current models of so/ware development
• The Factory
• The Workshop

26. A New Theory of Teams
• The Factory
• we're building a “product”
1. build it
2. ship it
3. maintenance
• explains 0/4 of the “hard problems”

27. • The Workshop
• so,ware cra,smanship
• 2/4 hard problems explained
• hiring
• turnover

28. A New Theory of Teams
• The Stage Model
• So.ware development is like pu9ng on a theatre produc;on
• starts with a script
• the team makes it real
• read-throughs change the result

29. A New Theory of Teams
• The Stage Model
• with more rehearsals changing direc5on gets more difficult
• group work with a deadline
• audience reac5ons affect the play
• explains 4/4 of the “hard problems”

30. A New Theory of Teams
• The Stage Model
• Hiring: it's hard to join the exis5ng produc5on
• Turnover: if one person leaves, it jeopardises the whole
produc5on
• Growth: you can't just add people to make it beAer/faster
• Produc3vity: can't be measured because there's no “product”
at the end

31. We are not not hardware resources

32. We don't make things

33. People are at the centre of so/ware
development, not products

34. h"p://brightonruby.com/2016/how-
we-make-so<ware-a-new-theory-
of-teams-sarah-mei/

35. brightonruby.com