Good or bad

Telling the difference is hard.

Press 'c' to toggle code style
Press 's' for speaker notes

Being a programmer is mostly

Drinking coffee
Googling answers on stackoverflow
Making choices

Which framework to use
Which libraries to use
How code should be written

Which frameworks are good, and which are bad.
Which libraries are good, and which are bad.
What code would be good, and what would be bad.

What is good?

What is bad?

"No wireless. Less space than a Nomad. Lame."

Rob Malda (founder of slashdot), on the iPod at its release in 2001.

400 million iPods sold

There's no chance that the iPhone is going to get any significant market share. No chance. It's a $500 subsidized item. They may make a lot of money. But if you actually take a look at the 1.3 billion phones that get sold, I'd prefer to have our software in 60% or 70% or 80% of them, than I would to have 2% or 3%, which is what Apple might get.

Steve Ballmer, Microsoft CEO, 30 April 2007

2 billion iPhones sold
$1 trillion revenue

Why this talk

Some still saw the iPhone as bad:

can't even replace the battery
can't even put a memory card in it
can't even send MMS at launch.

Some thought the iPhone was only selling well for the wrong reasons:

First smart phone to the market. (sic)
Apple products sell well just because they look good.
Apple spends more on marketing than other companies.
Iphone owners are sheep who buy it just because it's popular

If you think something is bad, but it's hugely popular, you're failing to tell good from bad.

Emotions

Math is hard

Emotions

http://www.mongodb-is-web-scale.com/

Which of these is better

Code that is easy to understand, has a good design, and has good test coverage.

Code that is rough around the edges, is full of hacks and isn't fully tested.

Math is hard

https://twitter.com/farbodsaraf/status/923353731948863489

Some languages are crap

English is an objectively crap language.

English can be understood through tough thorough thought though.

Did you read it?
Yes, I read it.

PHP keeps old 'bad designs'
English keeps old spellings

won't
cholmondeley
Featherstonehaugh

English lacks features

Most European languages have a polite and informal way of saying 'you'.

English lacks features

Other languages have deferential ways of talking

Less, "Yo! Get me a some water?"; and more, "It's a warm day for a nice refreshment, no?"

PHP lacks: threads

PHP lacks: Monkey-patching

r = 4/3  # => 1
r.class  # => Fixnum

require 'mathn'

r = 4/3  # => (4/3)
r.class  # => Rational

Neither PHP or English are widely used.

80% of the web powered by PHP

1.5 billion people speak English, and it's the language used for business worldwide.

If you think something is bad, but it's hugely popular, you're failing to tell good from bad.

Lack of consistency

Easier to adopt new ideas.
Easier to grow and adapt.

English - hard to give offense accidentally

With all due respect....
Thanks a bunch!
See you next Tuesday

NEVER SAY THESE PHRASES

Features generally make things harder to use.

'Ease of use' things accumulate massively, but that involve big numbers, so people underestimate their value.

iPod made two things easy

Itunes - made getting music onto it easy
The wheel interface

Nokia had a feature of 'choice'

“Apple should pull the plug on the iPhone.

These phones go in and out of style so fast that unless Apple has half a dozen variants in the pipeline, its phone, even if immediately successful, will be passé within 3 months.

There is no likelihood that Apple can be successful in a business this competitive.” - John Dvorak

iPhone lacked features but had great ease of use

No copy paste, no MMS, no Flash, no Java.
Really simplified the interface. 3 buttons vs 9 buttons + 5 way nipple on my old SE K800i
Spent a huge amount of engineering on making the scrolling smooth

PHP has great ease of use

No threads => shared nothing

No monkey-patching => predictable maths

No long compile step => quick iterations

Serverless? PHP has been doing that since last millenium.

The Black Swan by Nassim Nicholas Taleb

Systemantics (aka Systems bible) by John Gall

How to improve

Spend energy on learning to make better choices
Recognise how emotions affect decision making
Accept you're going to be wrong
Ease of use > features

Some skills are naturally learned

Some things take effort

Recognise how emotions affect decision making

Fun

Playing with new tech
Rewriting from scratch

Not as fun.

Writing documentation is boring
Refactoring old code is painful

Learn new aesthetics - Kintsugi

Learn new aesthetics - Wabi-sabi

https://en.wikipedia.org/wiki/Wabi-sabi

Learn new aesthetics - Wabi-sabi

Derived from the Buddhist teaching of the three marks of existence

impermanence
suffering
emptiness / absence of self-nature

Accept you're going to be wrong

Don't spend too much time on thinking.

Accept you're going to be wrong

Make it easier to correct mistakes.

What JS build tool should we use?

Yarn

Better lock file than NPM
Works just as well as NPM

What JS build tool should we use?

Yarn

~~Better lock file than NPM~~ NPM has equivalent lock file support
~~Works just as well as NPM~~
Not many library developers use yarn, more than a few bugs installing

Well things change.

NPM improved its lockfile support, so that kind of made that basis for choosing Yarn to be irrelevant.

And the second thing we found was that yarn doesn't work quite as well as NPM. The issue mainly is that most JS library developers use NPM, not Yarn, so they don't test their libraries with Yarn. And actually don't care if their library works with Yarn or not.

So the decision we made was correct at the time, for the things we based the decision on. But now it was clearly the wrong decision based on things we found out about later.

At the risk of being cynical, the main reason for not doing this is that it protects senior people making decisions from being shown to be wrong.

Protecting senior people in an organisation from being shown to be wrong, is one of the classic ways of an organistion starting to die.

Individuals value features over 'ease of use'

People get a kick out of delivering features

People get less of a kick out of making 'ease of use' improvements

Organisations value features over 'ease of use'

People get rewarded for delivering features.

People don't get rewarded for delivering ease of use.

“Not many people have gotten a raise and a promotion for stopping features from shipping.” - Raymond Chen
https://devblogs.microsoft.com/oldnewthing/20061101-03/?p=29153

Choices for 'ease of use'

Make it easier to run code from IDE than browser.
Debugger needs to be instantly available.
Automate deployments, tests.
Decouple your code from your framework.
Name things so they are easy to read.

What not to do

Cut for time

Laws of physics
Side effects often more important than the main thing. e.g. OO is rubbish but autocomplete in IDEs is great.
Avoid 'clever words' which distort how you think e.g. 'webscale', 'facade', 'interface segregation'
Ask people how sure they are, rather than yes/no questions.
Write estimated values down i.e. how much would choices be worth

Fin

https://joind.in/talk/2c761

Twitter: @MrDanack

Tshirt: https://teespring.com/php-thor-mjolnir

The wrongest thing ever

“there’s a big temptation to make English the language of reference even more in the future. It worries me because I don’t really want us to end up speaking a language without subtlety on sensitive subjects.” - Sylvie Guillaume, French MEP and European Parliament’s vice president.

Why is KFC popular around the world.

Be prepared to be wrong.

Decouple your code
Write tests
Spend less time thinking deciding between good or bad

Be prepared to be wrong. Particular around choosing libraries and frameworks....there is an incredibly high chance that whatever you choose is just not going to be the right choice....so write your code so that as much of it as possible is decoupled from _any_ library. (that includes your own libraries). Brucie bonus - this is very likely to make your code easier to test as well. a good way to measure this is to keep asking - if we removed this library how much of the other code would we need to alter - aka I fucking hate active record/eloquent. If you're not good at something, spend less time doing it. Spend less time making decisions. Which of the following scenarios is likely to have the best result for the i) A committee of 5 people spend a week choosing which library to use. ii) A single person spends 5 weeks choosing which library to use. iii) A single person spend 5 minutes choosing which library to use, and then spending the next 5 weeks trying it out......then finding out what it wrong with it, and realising that what you need from that library is quite different from what you thought was important.

iPhone models in 10 years

iPhone iPhone 3G iPhone 3GS iPhone 4 iPhone 4S iPhone 5 iPhone 5c iPhone 5s iPhone 6 iPhone 6 Plus iPhone 6s iPhone 6s Plus iPhone SE iPhone 7 iPhone 7 Plus iPhone 8 iPhone 8 Plus iPhone X

Nokia models in just 2007

Nokia N800 Nokia N93i Nokia 6110 Navigator Nokia 6131 NFC Nokia N76 Nokia 3110 classic Nokia E61i Nokia E65 Nokia E90 Nokia N77 Nokia 5070 Nokia 5700 XpressMusic Nokia 7088 Nokia 8800 Sirocco Gold Nokia 6120 classic Nokia 1200 Nokia 1208 Nokia 1208b Nokia 1650 Nokia 2505 Nokia 2630 Nokia 2660 Nokia 2760 Nokia 2760h Nokia 3109 classic Nokia 6500 classic Nokia 6500 slide Nokia 8600 Luna Nokia 3500 classic Nokia 6121 classic Nokia 6267 Nokia 5611 XpressMusic Nokia 6131i Nokia 7500 Prisma Nokia 7900 Prism Nokia 6555 Nokia 500 Auto Navigation Nokia 5310 XpressMusic Nokia 5610 XpressMusic Nokia N81 Nokia N81 8GB Nokia N95 8GB Nokia 8800 Sirocco Edition Nokia E51 Nokia 6301 Nokia 2135 Nokia N810 Nokia 6066 Nokia NM705i Nokia 8800 Arte Nokia 8800 Sapphire Arte Nokia N82 Nokia 3110 Evolve Nokia 6263

53!!ONE!!! different models.

List from http://nokiamuseum.info/category/launching-year/2007/

Good or bad? - telling the difference is hard.

A large part of being a programmer is making choices, whether it's what framework to use, what libraries to use or just how to structure code. Every day when we're programming we try to take choices that are good, and avoid choices that are bad.

But what if actually we're all terrible at telling the difference between good and bad? What if we're all just not very good at a fundamental skill needed to do our jobs?

In this talk I'm going to try to demonstrate a couple of common epistemological mistakes that people make, how you can try to analyze what is good and what is bad a bit better, and how to limit the consequences that come inevitably when bad choices are made.

Good or bad? - telling the difference is hard.

But what if actually we're all terrible at telling the difference between good and bad? What if we're all just not very good at a fundamental skill needed to do our jobs?