brighton ruby 2016 recap

35
Brighton Ruby Recap 2016

Upload: matias-korhonen

Post on 12-Jan-2017

17 views

Category:

Technology


0 download

TRANSCRIPT

Brighton Ruby Recap2016

Things I learned and things I liked

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

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

Lesson 2: take advantage of the

weak pound to buy an iPad

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

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

Talks I'd par,cularly recommend

The Point of Objects by John Cinnamond

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

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

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 !

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)

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

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

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

A New Theory of Teams• There are only two hard problems in compu6ng…

• cache invalida6on

• naming things

• (off by one errors)

A New Theory of Teams• cache invalida,on

• when to invalidate

• when to cache

• not a technical problem

• a people problem

• naming things

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

The only hard problem in so1ware is people— Sarah Mei

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

A New Theory of Teams• Current models of so/ware development

• The Factory

• The Workshop

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”

• The Workshop

• so,ware cra,smanship

• 2/4 hard problems explained

• hiring

• turnover

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

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”

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

We are not not hardware resources

We don't make things

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

brightonruby.com