[ Hello! ]
Just a quick survey before I start talking.
Who here is a programmer?
[ I am. ]
Who here is interested in learning to program?
Excellent.
There will probably be more useful advice
in here for you.
Anyway, hello.
My name is tef,
and I am a really terrible programmer.
I started programming to find out how things work.
I started taking things apart.
When I was actually two, I took apart the
household phone with a screwdriver.
The third time, my parents couldn’t
put it back together.
I kept taking things apart to find out how
they work, and now after more than
a decade in the industry, I am constantly
surprised that things actually do work.
I am a really bad programmer.
I write bugs.
I forget to write tests.
I write documentation that isn't really
in English.
And in a code review, I am the most apologetic
person you will ever see,
which for some of the people in the audience
may come as quite a surprise.
But frankly, I know we can do better.
That's your optimism quota for the talk.
[ (Laughter) ]
Anyway, I’m here to talk to you about mistakes
I’ve made, mistakes other people have made
and how we can learn from them.
Really, I’m kind of taking about the people
in the industry and the practices in the
industry rather than the code that we write.
I'm not going to sit and talk to you about all
of the bits and bobs involved,
or get into hideous technical detail,
or at least I’m going to try not to get into
hideous technical detail.
But really, the standard disclaimer applies.
This is my opinion.
It doesn't reflect my work, my friends,
my lifestyle choices or anything else,
or reality.
Now, some people have found my opinions
useful but personally, I have only found
they actually get me into trouble.
I'm actually quite wrong about programming a lot.
But frankly, it's never stopped anybody else
writing about it on the internet.
So that's a perfectly good place to start.
People who are wrong on the internet.
Now, there is this constant theme in
programming where people try to divide the
world into good versus evil, or good versus bad
to give it a less political name.
Now, when people talk about good and bad
programmers, what they normally mean is this.
[ (Laughter) ]
The insinuation is if you make all the mistakes
they made and [cargo cult] their personality,
you will be as successful as they will be.
Sometimes it's a little bit more veiled.
Now, a noted programmer who likes to call
this the Blub Paradox.
Has anybody heard of the Blub Paradox?
Basically, it's a smug LISP user.
I won't call them out by name.
But he made his money selling an unmaintainable
LISP program to Yahoo.
So unmaintainable that they replaced
it with Perl.
[ (Laughter). ]
They could not find anyone smart enough
to understand the hideous mess that
he had wrecked.
And in learning from selling all of his
stuff off, he decided to write an essay
called the Blub Paradox, about anybody
else who didn't understand how clever he
was being wasn't as good a programmer as he was.
He also claimed that if people understood LISP,
they would have prevented September 11 2001.
This is actually on his website.
He doesn't link it anywhere because he feels
some shame but it's still there.
[ (Laughter) ]
The next one is a more recent one.
Somebody decided the best way to explain
programming was in terms of politics.
Now, if you've ever talked to a programmer,
they like using accurate terms.
So what he decided to do was go,
'Programmers who like these languages are Liberal.'
'And programmers who like these languages
are Conservative, and as a software Liberal,
I think this one's right.'
So what he actually managed to do,
which is an amazing thing for a blogger,
which was actually drag down conversation.
Prevent any intelligent discussion.
Now people are happily posting on their
internet going,
"I'm a software Libertarian."
[ (Laughter) ]
Why do people do this?
Why do people feel the need to divide
the world into good and evil?
There are two reasons.
Everyone loves a simple answer to a hard question.
Especially a wrong answer.
And people love blog hits.
It's been well known in tech journalism for years
that the best way to get page views is not
to say anything informative or right,
or informed.
It's to troll people.
[ (Laughter) ]
And that's exactly what he's done.
Now, just to go onto an aside,
there are many asides in this talk.
I make no apologies.
How many of you have heard the myth of
the genius programmer, or that some programmers
are 10, 50, 100, a million times better than
other programmers?
How many know where that comes from?
Somebody has watched a talk I linked
on my Twitter feed.
Right, this came from a study in 1960 about
batch processing versus interactive processing...
With 12 people in an afternoon.
And since that day, everybody has repeated
the myth that there are fantastic programmers,
somehow geniuses that can reach out and
create wonderful worlds.
But honestly, after working in the industry
for a while, I don't really believe it's true.
The people who sort of repeat this myth
are the ones who sort of go,
"I have nothing left to learn because
I'm fantastic!"
Some of the other people repeat this myth as
if to go, "I can't do this. It's too hard."
All this myth does is prevent people from
learning and trying to grow as people,
and trying to learn and understand things.
It's a constant excuse for ignorance on both sides.
Really, when you ever hear the term,
'A genius programmer,'
sometimes it's called a rock star or a ninja,
a founder, an entrepreneur.
What they mean is someone who is willing
to work 80 hours a week and only get paid
for 20 of them.
This is another common myth in programming.
For some reason, people think owning a penis
means that they understand computers.
It's terrible.
If you believe this, you’re not only a terrible
programmer, you are likely a terrible person too.
If anybody wants to take me up on an argument
about this afterwards, I'll fucking have you.
[ (Laughter) ]
[ (Applause) ]
I'm really hoping once we can sort the gender
divide, the race divide in programming,
we can move onto more important issues
closer to my heart, like tabs versus spaces.
But...
[ (Laughter) ]
I don't actually have a lot of hope.
There was actually a study done.
They divided people into two groups,
one of which was told gender has a difference
on your ability.
The other one wasn't.
And the group that was told gender has a
difference, weirdly enough the gender that was
told they are better than the others
did slightly better.
In the other group, everyone did better.
Everyone.
If you believe these sorts of myths,
all it is is an excuse.
People who go, try and find something is too hard,
they go, "Well, obviously I don't have a penis.
I don't understand this."
Or they go, "I have a penis, thus I've understood
everything there has ever needed to be understood
in the world."
Bad people.
But frankly, since it's so easy to divide
the world into good and bad,
I'm going to have a go too.
And you can have a go at me for this later.
Personally, I’m a little bit from column A
and a little bit from column B.
Can people read this at the back?
[ Yeah. ]
Basically, sometimes I refuse to try to learn
and other times I just blatantly refuse.
But really, programmers make mistakes all the time.
Everyone here has written a bug.
Everyone who has ever written a programme
has written a bug.
It's a constant field of mistakes.
But the biggest mistake I've ever seen in
programming is optimism.
[ (Laughter) ]
Don't get me wrong.
Optimism is necessary, if you actually for a
moment understood the absolute challenge
of programming, trying to understand everything
that's going on, all of the interlinked
libraries, all of the operating system calls...
You would go mad.
Absolutely insane.
Optimism is absolutely necessary to do programming.
Otherwise we would sit and curl up into a
small ball, drinking whiskey.
But you can tell an optimistic programmer.
They have this saying.
It goes, 'You would think that.'
You would think that they would be able to
sort this thing out.
You would think that they'd be able to fix
this bug.
Every time they're being optimistic.
They are underestimating the absolute difficulty
and treachery of programming in the real world.
Don't get me wrong, things could be better.
Things could be much better but we go out of
our way to fix bugs.
We run tests, hopefully.
But really, we don't do anything to fix the
situations that lead to bugs.
We don't go around trying to fix people.
Mistakes come from the environment too.
Really, if we really want to find out why bugs
keep happening, we have to fix our processes.
We have to fix the mentality that lets us
write so many things rather than accepting
it as a gradual inevitability that we are so
incapable of doing our job that we have to
spend the next nine months patching things.
Really, it's not an endemic problem.
It's systematic.
Now, code really reflects social structures.
Now, this quote comes from a man called
Melvin Conway who published a paper called
Conway's Law, or now called Conway's Law.
And they thought it was a joke, so they refused
to publish it.
But he sat and looked at all of the structures
of teams writing code and when you had a
four person team, you got four modules.
You can see where I’m going with this.
Eight person team, eight modules.
Frankly, code is a reflection of the personality
of the user.
Some people might have heard the term of
a God object.
A God object is an object in a programme
that seems to handle way more than it should,
all the responsibilities.
Every single thing that can be done is a
method somewhere buried in a 6,000 line program.
These objects come from God-like programmers,
people who believe they are responsible for
everything that is going on in the system.
Our people leave worshippings,
they occasionally try and poke it, twist it or
otherwise but they sit and treat it with respect
and fear.
But as much as I’m picking on individuals
making mistakes and the processes that do that,
groups make mistakes too and I’d like to tell you
some of my favourite group mistakes.
Who's heard of bikeshedding?
Right.
This comes from a book called Parkinson's Law.
He argued that if you were trying to build a
nuclear power plant, what would happen is
you sat and talked about the cooling systems
and various other bits and pieces.
Everybody would be silent around the meeting.
They didn't know what they were talking about
so they'd be quiet.
But there was a bike shed at the nuclear
power plant and everybody wanted to know
which colour to paint it.
Suddenly, the meeting room erupted.
Everybody had their favourite colour
and preferences.
Quintessentially, when there’s no domain
experience, there is no actual knowledge
involved in the decision,
everyone can contribute and everyone will,
whether you like it or not,
and they won't shut up about it.
Quintessentially, everybody wants to feel
part of the process, wants to feel that
they're making part of the decisions and
they will happily stick their thumb,
(it's a Danish saying),
sticking their thumbprint on things.
So when you lower the barrier to entry,
you realise that all you're going to do
is waste everyone’s time somewhat
because everyone has a favourite colour
and no amount of argument can solve it.
Another favourite of mine is called
The Group Project.
In a group project, a bunch of enthusiastic
people go together and go,
"If only we all got together.
If only we all tried to do something together,
we could make something awesome.
I've got a list of ideas I didn't find interesting
enough to do on my own but maybe some of
you guys will really like them."
The reality is collaboration requires leading
by example and by example, I don't mean
being someone with lots of ideas.
I mean someone who actually enacts on their ideas
and actually tries to get stuff done.
If you’re really enthusiastic about a project,
if you've seen around here,
people will come up and help out.
On the other hand, if you stand on stage and
go, "I've got the best idea in the world,"
people will sort of troll you from the back rows.
Really, people have this idea that ideas are gold.
Ideas are perfect.
Ideas will save you from every type of hard
work in the world.
Ideas are multipliers for effort.
Even the worst idea in the world can still
make money if you put enough time into it.
But really, if ideas are all you have,
you're an idea guy.
[ (Laughter) ]
Now, if you have a group project,
and all the people in there have ideas,
now a forum I’m on calls this Goon Projects.
What happens is people go,
"I like video games.
I'm really good at playing video games.
I have this awesome idea for video games.
I just need someone to write the game,
draw the art and build the game,
but I have ideas.
I can totally contribute."
It's a bit like somebody going up to you
and going,
"I've got this great idea for a book.
All I need is a writer and you'll get a share
of the royalties."
[ (Laughter) ]
You can tell these ones because all of
the discussion revolves around almost one
of two things.
The name and the logo.
[ (Laughter) ]
Most recently, there's been attempts to
build darknets or distributed social networking.
There's a Reddit project set up called
DarkNet Plan.
They've finally banned threads about
the name and the logo because that's all
that was getting discussed.
People who come up to you and go,
"I really like your project.
I really want to contribute.
I've got an idea, I'll set up a Wiki,
I'll set up the press CAM."
They're not going to help anything.
I'm sorry.
Another classic idea is Waterfall.
I assume some of you have heard of the
waterfall development process?
Hands up of you who have read Royce's
original paper on Waterfall?
Well, that one person over there will know
where I’m going with this.
Waterfall is a straw man argument.
On the first page of the paper, he went,
"Here is a system that doesn't work."
But it turns out when you put a really nice
picture on the front page of your paper,
that's as much as people will read.
He then went on and elaborated how you need
feedback through the various parts,
and how things have to, you know,
react to change.
And it's one of the most terrible things
that we do in software engineering at the moment.
Project management is almost like an attempt
to control reality rather than measure it
or even have any idea of feedback.
I'm sure many of you have experienced
milestones upon high handed down.
I have a number of times and I’m very bitter
about it.
But really, there's this mentality with Waterfall
that this time we'll do it perfectly.
This time everything will go right.
We don't need to have any slack.
Nothing will go wrong.
[ tef, you missed the bit explaining ]
[ what Waterfall is. ]
Waterfall, have you ever seen a cartoon
about birds in a tree?
The birds at the bottom of the tree get
covered in shit and when they look up,
all they see is arseholes.
That's basically what Waterfall is.
It's the idea...
[ (Laughter) ]
It's the idea that you get all of the
design, all of the slack, all of the
anticipation of things that will go wrong
months and years down the line in three months.
And then if they happen further down the line,
that's their problem.
So you'll get designs that don't work,
constraints that don't work and it's your
fault and you have to clean up after the mess.
This often ends up in crunch time.
It turns out we don't need to do risk management.
We don't need to worry about slack
because we'll just make the programmers
work for 80 hours a week.
That's all they're good for.
Does everybody understand Waterfall now?
[ (Laughter) ]
But really, it's not just people, practices,
methodologies, companies.
We also don't know how to find good
programmers and reward good programmers.
Now, how many of you have heard of
brainteasers in interview questions?
Do you know what you should do in an
interview when somebody comes up to you
and says, "Why are manhole covers round?"
Leave.
Now, how many of you heard of the Wason
Selection Task?
The Wason Selection Task is you get four
cards on a table.
Two are face up, two are face down.
One is red, one is black and there's a
patterned back and a plain back one.
And you ask people, "How many cards do
I have to turn over to check every card is red?"
And when you ask it like this, people often
say "Three," because they're not checking
for contrapositives.
Now, I don't really want to go into this
complete cog psi thing, but it turns out
that when you ask instead, and let me
rephrase the question.
We have four people.
Two are over age; you haven't checked the
age at all.
One is drunk, one isn't.
How many people do you have to check
to see that you're not breaking the law?
When you phrase these questions in a social
context, everybody gets it right.
When you ask it in an abstract context,
no one gets it right.
Domain experience is absolutely vital for
problem solving.
Really, when somebody is asking you a
brainteaser question, what they're trying
to do is prepare you for terrible management.
They're trying to set...
I've heard people excuse this and say,
"Well, I know we're not hiring for a quiz
show host but the management like to
ask really arbitrary and stupid questions
all the time, so that's what we do in the
interview..."
[ (Laughter) ]
"... to filter out the sane ones."
And some other people go,
"I heard Facebook does it, Google does it,
Microsoft does it."
That's bullshit.
You read it in a tech journalism article,
the same article that's been going around
for years.
All that happens is the company that's in
the light at the moment,
they do a search and replace with Google,
and put in 'Facebook'.
But I don't really want to argue about tech
journalism.
That's entirely another talk, but frankly...
[ Can we have one tomorrow? ]
[ (Laughter) ]
But frankly, if you find a company asking
brainteasers, it's a really good sign that the
job is terrible and you should leave,
for your own sanity.
I've made this mistake countless times and
I don't want to see anyone else do this.
Really, we like to call ourselves a science,
computer science but we don't really test
our assumptions or our code, or our methodologies.
Or really anything that we do.
We have rituals, cargo culting.
We have things called best practices that
kind of amount to superstition.
We'll still get people going,
"Oh, I don't like garbage collection because
my lecturer who works on punch cards
thinks it's evil."
[ (Laughter) ]
We go around teaching people to create from
the top down, writing every program as
if it will be perfect once, and four years of
university, I was never asked to maintain
a program, fix a program, document
a program, test a program and it's very
rare that these things happen in practice.
But then unfortunately, if you actually
get a job programming, that's all you
will ever be doing.
For some reason, we have this idea,
almost like pyramid builders, that we're
building this gigantic obelisk that will
stand for thousands and thousands of years.
I apologise to the embedded programmers
in the audience because those things are
kind of true.
[ (Laughter) ]
But for the rest of you who are writing
web apps or skins around databases,
as I like to call them...
[ (Laughter) ]
... almost all of the work you are doing is
talking to other programmers, finding out
what's going on.
Reading code, not writing it.
Now, I don't mean to go off and like have a go
at prototyping or experimental coding.
Experimental coding is fantastic.
It helps you go off and understand a problem,
fix it in your own head.
But when I’ve written prototypes, almost
everything I’ve learnt has been from pushing
it into production and then fixing all of
the really stupid ideas I came up with in the
first week.
But to move on again, I’ve talked about a number
of bad things in programming but I haven't
mentioned the next one.
Teaching.
Well, I kind of have, but hey.
Really, there are two driving factors in how
we teach programming.
One of which is nostalgia and the other of
which is how the teacher learns best.
Do what I do, feel like I did and you will
be as successful as I have been.
But there isn't any appreciation of learning
preferences.
Now, I don't know if any of you have ever
had dyslexic problems or gone to learning support
but there's this idea called the VARK test.
Visual, Audio, Reading and Kinaesthetic.
If I ask you for directions, some people will
tell me, some people will draw me a map.
Some people will walk me there,
and some people will write down detailed
lists of expressions.
Not everybody learns in the same way.
Not everybody teaches in the same way,
but for some reason we think that the only
way to teach is how they learn...
Any of you who have been to university,
you must have seen a university lecturer,
the kind that will read his printed notes out.
And they're not just doing it in the hope that
everybody leaves and they can go back to the
staffroom and drink tea.
They're doing that because that's how they learnt.
Really, what we want to do is encourage
people to learn rather than dictating their
learning course to them.
A vital skill in programming in the real world
is googling, looking things up on your own.
Being thrown into the deep end.
But we don't really encourage that.
We kind of go, "Here are your learning outcomes.
Tick the boxes and you're done."
In fact, when I was at university, I had to sit
in a tutorial class and the tutor finally gave up
trying to explain anything that was going on
and for the last tutorial lesson, all we did
was chant.
He told us to chant, 'Public, Static, Void, Main.'
He had given up absolute hope of trying to
get us to understand, try to be engaged,
try to learn or try even being enthusiastic.
The only thing that would save his face was
everyone getting at least one mark in the exam.
You can see the difference between adult
education and child education.
Adult education, if people don't like it,
they leave.
In child education, if people don't like it, we
send the police around.
Really, there's a sort of lack of respect
for learners.
This whole sort of 'I know best.'
Personally, I’ve learnt the most that I have
about programming from sitting down with
somebody else who asks the most amazing questions
and I have to think about what I’m doing.
I haven't learn anything from being on my own
or just assuming that I know everything from
the beginning.
So really, if somebody asked me,
"I want to learn how to program,"
my first question, and it should be a question
that you ask rather than telling them
straight off, is
"What do you want to create?"
"What do you want to build?"
So just on a bit of random unsolicited advice.
If you do want to learn programming, find the
languages and the tools that your friends use
because otherwise you're going to be screwed
when you need help.
Find something that's easy to install.
Find something that doesn't require going
through a 300 page manual on how to open a
certain dialog box and navigate through the menus.
It's just not fun.
Don't worry about object orientation,
functional programming and all of the crazy
things that some of your friends with weird
hair are talking about.
Really learning to program should be about play.
It should be getting things up and running
in an afternoon and seeing what happens.
It should really just be about poking things.
And hopefully not crashing your computer.
Learning programming shouldn't be the
means to an end.
It should be something you're doing in
order to do something actually fun.
Now, I’ve touched on the idea of learning
through play but what I like to suggest is
people, they get a sandbox environment.
They find, like has anybody ever used Logo
or a Turtle Graphics?
Keep your hand up if that was the first
language you ever started.
Yeah. That’s why you're stuck with it.
[ (Laughter) ]
That's why you've never escaped programming.
It was so much fun in the beginning and
you've been trying to find and recapture
that ever since.
[ (Laughter) ]
I know I have.
Now, I am recommending all of these things
and I talked about how nostalgia and learning
styles kind of dictated how people teach.
And I am totally guilty of this,
because my first language was Logo too.
Logo was introduced by Seymour Papert
in a book called,
well, he wrote about it in a book called
Mindstorms.
If you're wondering, the Lego set is named
after the book, not the other way around.
One of the biggest ideas that Mindstorms
elaborates is this idea of the math world,
this idea of an environment in which the
person at the front of the computer can
dictate the terms, dictate the rules,
dictate how things happen.
A beautiful story was someone who was
having trouble writing English,
having trouble getting all the verbs to match,
the tenses to match, was asked to write
a poetry generator.
And as they sat, trying to encode the rules
of grammar, a very simplistic grammar.
I'm not suggesting anybody try to encode
the rules of English grammar in programming.
I don't want anybody else to go mad.
But as they sat and did this, they suddenly
clicked because they suddenly found a way
to formalise, to sort of internalise the rules
of the thing they were doing.
It was no longer a black box,
a thing that mysterious things happened
and stuff came out the other end.
They could actually see the effects of the
changes they made.
And it helped them learn.
Piaget and Constructivist Learning.
I don't know if you want to google this later.
It's totally awesome.
There is a similar idea that's been espoused in
maths education.
Now, a lot of maths education is basically
treated as a death march through formula.
They call it problem solving but really what
they mean is find that bit of the book
where we told you how to solve this problem
exactly and then write it down on the piece
of paper.
Instead, they argue that you should teach
maths by asking people,
"How do we measure the..."
If you have a box and you want to know
the volume, you ask the children,
"How do we measure the volume?"
And they'll come up with ideas on their own,
as if by magic.
It's almost as if they're like enthusiastic
before school crushes it from them.
But really, the moral is here that learning
is fun.
Learning is absolutely fun but only when
you get to be creative about it.
Only when you get to set your own terms,
dictate your own rules and get to explore
without just having to go through a check box
of learning outcomes.
The other biggest influence in how I learned
programming.
Now, some of you have never heard of
View Source.
It's a beautiful thing.
I learnt to program on the web early
and I would find something interesting,
I would right click it and go, 'View source'.
And at that time, JavaScript minimisers
weren't popular so you would actually see code
and sometimes people would write comments
explaining what they would do.
You had a working program and then you
could tweak it and change it, and play with it
and find something new.
There wasn't this (I'm going to repeat myself)
a black box.
Suddenly I was free to explore and engage
with the environment.
I miss that.
Now, I don't mean to go back to internet
bloggers but another internet blogger
recently wrote an article called,
'Why are you learning programming for fun?
Don't you realise programming is serious business?
How dare the Mayor of New York go out and
learn programming.
There's so many things to learn and so many
things to do.'
It's like maybe it was fun for them.
Maybe they're enjoying themselves and
maybe that's actually how you got into it
in the first place, you hypocritical bastard.
[ (Applause) ]
That's Jeff Atwood.
I have many other opinions about Jeff Atwood.
None of them are flattering.
[ (Laughter) ]
[ How many of them are fit for public consumption? ]
In summary, he is a terrible person.
Okay, I’ll tell you a little story about Jeff Atwood.
[ (Laughter) ]
Jeff Atwood wrote on his blog, saying,
'I'm writing a website and the business
use case is filtering HTML and I must understand
this in order to run a successful website.
There are libraries written by people who
understand HTML and parsing, and all of
the other bits and bobs, but if I used a
library for my code, I wouldn't be doing my
core business practice of rewriting strings.'
So he published his algorithm and people broke it.
He published it again and people broke it,
and then after a month of everybody telling
him to do it the way that all of the
libraries already do, he kind of grudgingly
took their advice.
And now what he says is,
'Now I’ve gone through this learning experience,
none of you have to do it.
You can all use my library.
You don't have to go and do this in the
first place.'
With no hint of irony.
He is a terrible programmer.
But really, if you're going to tell people
off for learning and playing, and exploring,
you're a bad person and I hate you.
[ (Laughter) ]
Now, we kind of touched on misogyny
before this, it's just kind of a jokey title.
Now, some people say you have to learn C.
C is a real language.
It's used everywhere.
[ Real men use Fortran. ]
[ (Laughter) ]
Real men eat quiche.
Now, the thing is about C is it's actually
quite hard.
It's actually quite old.
There's a lot of things that you need to do
to get it up and running.
I've seen so many embedded programmers going,
"Oh my god, why do I have to include files?"
"What the fuck is this all about?"
Really, when you're trying to learn to program,
you want to get something up and running
not in an afternoon, not in a hour,
you want something up and running now.
C is not the language to do this.
Now, once you've become comfortable with
the Shell, become comfortable with an editor,
become comfortable with the idea that you
run, it crashes, you go and try and fix
the problems.
You cry a bit.
Once you've come to terms with how terrible
programming is, C is a perfectly acceptable
second language.
[ (Laughter) ]
But frankly, forcing it down beginner's throats
is just going to scare people off from the outset.
Although admittedly, I’m pretty sure that's
what this talk is doing for them.
C is character building.
[ (Laughter) ]
Now, other people will tell you that you
need to use what's used in the industry.
Now, I’m not saying that you need to go out
and use these Scratch or various other things
in their bag; they're actually quite fun.
But some people will say,
"Oh, you must learn Java because you want a
job in programming."
You don't want a job in programming.
[ (Laughter) ]
Now, the thing is about object orientation,
is we only developed it in about, well,
actually it had been developed in 1964 but
we've only come to terms with how useful
it is in certain places after we've actually
written large enough programmes to benefit
from them.
Now, I mentioned before about chanting
'Public, Static, Void, Main.'
This is what happens when you try and teach
object orientation first.
You spend the first hour explaining everything
that they have to ignore in order to get
the thing working.
Now, I don't know about you but teaching
people the first lesson of,
'Ignore this, ignore this. Don't ask questions
about this. This is too hard.'
It doesn't sound like a really good way to
encourage people to be exploratory and creative.
Again, it's a better second language,
not a first but maybe third, fourth, fifth.
Somewhere down the line.
Now, a lot of people when they're learning,
they look for ways to avoid learning.
Some of you hang around on forums on the
internet where people are asking questions,
you'll go, 'I want to know if this will work,
this three line program and I’m too afraid
to run it and see what happens so I’m looking
for some reassurance.'
This is a direct effect of this over complication
of learning.
Really, people learn with a view of trying
to avoid as much work as possible,
trying to cut their losses because some things
that you want to learn are just really, really,
really hard and it will take many, many years
of your life.
So I don't think we should be teaching complicated
languages.
I don't think we should be teaching languages
that demand that you ignore things because
all it will do is encourage people to ignore
things in the future.
And write comments on random people's blogs
going, 'Please can you send me the code.'
Now, another thing about learning programming
is some people are like,
"Programming is mathematics so you must
understand group theory, algebraic geometry
and differential geometry."
Now, don't get me wrong.
Maths is important to programming.
Maths is very important to programming
because there are things like floating points,
also known as the incredibly misleading numbers
that never really work the way that you want
them to.
The thing is not many programmes actually
demand that much mathematics beyond counting.
If you can use a spreadsheet, you already know
pretty much every single piece of mathematics
you will ever need to know in programming
in the real world.
Programming is part mathematical but it's
not going to be like cryptology or differential
geometry.
But there’s the same sort of reasoning behind it.
There's the same sort of working things through.
What I’m really trying to say here is not that
programmers should be mathematicians but
programmers are mathematicians and if you
disagree with me, there's a big, big paper
called The Curry-Howard Isomorphism,
and it says that it proofs the programmes,
but you can look that up when you go home.
But ultimately, programming is not just one thing.
It's an interdisciplinary thing.
You need to be able to write in your native
language.
You need to be able to have critical reasoning.
You need to have engineering discipline,
and you need to have that whole sort of
mathematical reasoning as well.
But the most overlooked skill in programming
is understanding the domain of the problem
that you're actually solving in the first place.
Now, as I slowly get to the end of my talk,
I thought I’d share some tips on how to be
a successful programmer.
But as I said in the beginning, I am a
terrible programmer.
I burn out in jobs.
I go mad.
I drink too much, etc.
But other people seem to get along really well
in programming and I’ve sat and watched them
so I thought I’d share some of the ways in
which they do this.
Don't write documentation.
Documentation means you're replaceable.
[ (Laughter) ]
If you fix a bug, make sure it fixes only
that case that they've talked about so that
somebody else can reopen the bug later.
[ (Laughter) ]
The standard library is evil.
Don't use things other people understand.
The best code is the one that you've
written yourself.
Go crazy with advanced features.
Object orientation is not crazy enough.
The type signature of your function should
be at least 16 pages long.
I had a boss who was a PhD.
I shouldn’t be mentioning about this because
it's being recorded but...
the thing is whenever he wrote a program,
it wasn't to solve the problem,
it was to demonstrate how smarter he was
than everyone else in the room.
Every single feature was in a different file.
And it was fine for him.
He could keep all of this complexity in his head.
I'm really terrible.
I'm really stupid.
I can't keep any complexity in my head whatsoever.
And I constantly struggled to do any of the
things that he was doing.
Eventually I caught up and I realised that
the entire program was stupid from the outset.
But that’s another story entirely.
But really here, you want to use abstraction,
modules, especially if you have to use all the
modules together in some weird, awkward
incantation to actually get them to work.
That works wonders.
At a previous company, we had a term called
Andre Bugs.
Now, I’m not going to name the company.
I might if you goad me.
What we did was we did flight prices and we
had to get child prices for flights.
So what he did was he hard coded the percentage
of an adult flight that would be for the child
price.
So somebody would open a bug, saying,
'This flight is wrong.'
So he'd change the percentage, close the bug.
[ (Laughter) ]
And then two days later, someone else
would open a new bug, saying
"This different airline, from a different person
this is also wrong.'
So he'd change the percentage and you can
close it.
And what management saw was all of these
bugs being filed and closed within five minutes.
He is the most productive programmer they
have ever seen.
[ (Laughter) ]
Don't forget the useful things like
non-deterministic tests: tests that never pass
unless you kind of stand on one leg and
sort of sacrifice a chicken.
Remember, if it takes at least a week to get
all the stuff installed on your machine,
that's perfect because no one ever can keep
up to what you're doing.
But ultimately, being a successful programmer
is being a solipsist.
Pretending there are no other people in your team
and you are the only hero that can save the world.
But ultimately, if you sabotage your company
you will be rewarded.
The only time I was actually praised at this job
was when I stopped working for two weeks
and I decided to play something called the
CC game.
Every time you get an email, you reply to it
and add someone else in the company.
[ (Laughter) ]
If you can, copy and paste emails from someone
else into the new email but make sure it's
in a Word document.
[ (Laughter) ]
Using the company's formatting.
They love that.
If you’re wondering when you win,
it's when the CTO is finally on the end of
the email chain and he calls a meeting.
And the person who actually raised the bug
gives up, throws his hands up in disgust
and refuses to talk to anybody anymore.
But ultimately, you need to create work
for yourself that only you can do and that's
how you will be successful.
On the other hand, if you want to be a good
programmer, the best way to be a good
programmer is try to get fired as soon as possible.
You need to stop trying to write code,
and you need to try to read code.
Now, can you imagine if you were trying to
talk to an author who writes books
and you went to their house and it was barren.
And the only books on the shelf were the ones
that they had written, because that was all
the experience that they needed.
I have been to a sci-fi author's flat and it
was scary.
It is the most books I have ever seen in my life.
I feared for my life because they would just
fall over if you breathed in the wrong place.
But frankly, we sit and pride ourselves on
all the things that we've created rather than
all the things that we've learned from.
There's another sort of adage to that in
that often I’ve been going through CVs and
people write, 'I have 10 years' experience
of C++.'
And you don't see what they've read,
what they've done or the other,
and pretty much all that means is,
'I've done one year ten times.'
Now, sorry, my notes are wrong.
I'm going to have to improvise here.
Now, sometimes people complain that it's
really hard to estimate about work and work
out what actually needs to be done but
I’m not sure if that's because we're constantly
reinventing new stuff or we kind of refuse to
read about all the people who have done it before.
I'm still on the fence about that one.
But really, what you really want to do is write
code as if you're going to get it wrong,
as if all of the assumptions you hold dear
will be absolutely stupid.
Write code as if you can delete it tomorrow and
replace it because almost certainly,
you will have to.
This is a lot easier if you don't spend all
your time writing lots of code.
Empathy is fantastic in programming.
We need a hell of a lot more empathy.
There’s this horrible trend where if you ask
a programmer a hard question, they'll go,
"Well, we'll put a checkbox in the programme
and leave it to the user."
Also known as,
"We told them to go fuck themselves."
[ (Laughter) ]
But really, you don't want to try and write
correct code.
You just want to write code that's less
painful when you’re wrong.
And you will be!
Really, the moral is you want to write code
that's easy to replace, not easy to extend.
Anyway, as I slowly wrap up and await the
inevitable trolling questions,
[ (Laughter) ]
... I hope...
I have a final warning.
Although I’ve talked about many of the
problems in the software industry, programmers,
I’m going to repeat that 'programmers'
because it deserves extra bitterness,
management companies, methodologies,
tools, practices.
The software industry is terrible
but pretty much every other industry is too.
Even if you are trained, you will not be able
to escape other people.
Thank you.
[ (Applause) ]
So who wants to go now?
Any questions?
[ I know that was kind of shrouded in humour ]
[ a little bit but I guess there was kind of ]
[ a serious point there. ]
[ Do you find that the kind of points you were ]
[ making, the negative side to software ]
[ development apply to younger programmers than ]
[ they do to a people who are a bit more seasoned ]
[ in the field? ]
Actually, I find the inverse.
When we try to do hiring at this company,
we hired, we tried to interview a lecturer
of C++ who didn't understand the difference
between the stack and the heap.
I can explain that reference, but if you
understand C++, that's like
'What the fuck are you doing?'
But frankly, we found that the less qualified,
the less trained they were, the less we had
to unlearn from them.
The less of the assumptions we had to take away.
They were actually more willing, more humble
and just more open to actually trying to learn
new things.
On the other hand, when you get a prize winning
graduate in Scotland (no names; I actually can't
remember his name so I can't shame him)
who doesn't know any sort of, even the most
trivial thing about the language they were
at their final year project in, really okay...
I am a dropout and I have an absolute bias
towards these things but frankly, I found
the less educated people are about programming,
the more open they are to actually learning
about it in the first place.
Next.
Do you want to pass the mic down?
That would be awesome.
[ You spoke about education... ]
Speak into the mic.
[ You spoke about education in universities or ]
[ schools, whatever. ]
[ But I’ve found there is also an issue with ]
[ education in the workplace. ]
[ I'm struggling with actually new hires or ]
[ relatively new hires who literally say things ]
[ like when asked if you've read about this, they ]
[ say, "No but I think", and quite often, ]
[ what they think, someone else already thought ]
[ about and they didn't come to the same conclusions. ]
[ So it's a struggle for me. ]
I'm not sure what the question was,
but I’ll just improvise an answer.
[ (Laughter) ]
[ Maybe I’m just channelling my frustration. ]
It's okay.
That's what I’ve been doing for half an hour.
I think everybody else is entitled to it.
[ (Laughter) ]
There's often talk about a skills gap
in employment and normally what that means
is we all want to pay for people who know
what they’re doing.
But there's another side to the coin.
We want people who know exactly what they’re
doing from the outset.
There is a complete abandonment of apprenticeship
and mentoring.
So, so much of what I’ve learnt about programming
has been done from writing code that other people
use and they know where I live,
and I live in fear still to this day.
But we kind of almost expect everybody to know
things absolutely from the outset.
So either you need to aim higher or aim lower.
You need to either pay more for the people
who you actually think will know these things
or you need to be willing to spend time to invest
in the people and get them to learn.
But when you do invest in these people,
they're really easily exploitable and they’ll
happily work for long hours.
So it kind of works out in your benefit anyway.
Is there another question from the audience?
If you want, raise your hands.
I promise not to be too mean,
or have I stunned you all into silence?
Excellent.
Oh, one more.
[ Given what you've said, this is kind of a ]
[ hard question to answer, I guess. ]
I love hard questions.
[ Where would you say the solution is then to ]
[ these kind of problems? ]
[ I know, it is a big question. ]
[ But let me put it this way, there's this thing, ]
[ what's it called? ]
[ The C thing where they're trying to get kids ]
[ to learn programming in school. ]
[ Do you think that's a solution? ]
[ Do you think teaching kids how to manage ]
[ managers is a better solution, you know? ]
It depends.
To give you a simple answer to a hard question,
something I called other people out on for
earlier, with no shame.
Now, the thing is it's a really hard problem
but that's because it's lots of different
interlinked problems.
Really, if you give me a more specific example,
like 'I'm young, I’m going to a company.
I want to learn things off my own back...'
Honestly, I’m not sure exactly what the
solution is, but one of the things I think would
be better is kind of breaking the whole
(for lack of a better word)
patriarchy in programming.
There is so many angry young white men in
programming.
Hi!
Who basically go around assuming that they
know everything.
There is a complete lack of diversity.
So I think if we get more interesting people
with different backgrounds or otherwise,
we can start to get along and start to learn
from each other a little bit more.
But frankly, what we are right now is entirely
a monoculture.
And we all go around repeating the same old
myths, the same old lies and patting ourselves
on the back for it.
Again, it's a really good question and
I’m sorry I don't have an absolute answer to
how everything is terrible and how can I fix it?
But it depends on who you are.
The old clichÈ of think global, act local.
If you're at a company and it's bad,
talk to your managers.
If they're terrible, leave.
That's very easy for me to say,
but there are many, many things you can do to
fix your environment but I can't really give you
anything other than platitudes in order to do it.
Although if you want platitudes, I would have
more but I’ve kind of run out.
Is there any other questions that are hopefully
easy and single, that I can answer in a
very trite and simplistic way?
There's a man at the back.
Actually, let's take a question from the front.
We'll just go closest first.
Hello.
[ Do you think that university is a good way ]
[ to train programmers then or do you think people ]
[ should learn straight out of school? ]
Ooh, another hard question.
Fuck.
Right, one of the things I tried to talk about is
how programming shouldn’t be a means to an end.
We shouldn’t be teaching programming.
There is this whole talk of algorithmic literacy.
The idea that programming will become as
important as reading and writing to other people.
And so I don't think we should be teaching
programming in the sense of it stands alone,
as this magical tool that has no means,
almost like a completely theoretical subject.
Almost like pure mathematics.
But as you can see with mathematics,
it's been branched out to physics, chemistry,
sometimes biology.
If you're pushing it, statistics and if you're
really pushing it, economics.
But I think programming should actually be
taught fairly early on, just because it's a
fantastic tool.
The computer is a gigantic lever of which
you can move the world.
When I was a kid, I was constantly...
The first time I ever saw satellite pictures
of my house on the internet, I was amazed
and I'm still constantly amazed at the internet.
Like watching pictures live from space over
an internet link on my mobile phone.
But really, that only happened because no one
thought it was interesting enough to put on TV.
But I’d say the way in which we're approaching
teaching programming is wrong because we're
teaching it as a solitary skill, something that
only stands on its own rather than
programming is something that can be so
much more useful in other fields,
to actually achieve really interesting and
useful and fun things.
Now, you can see this in bits like the demoscene,
the music hackers, the bioinformaticians
where they're going off and writing very, very
simple programmes and they all feel really bad
about it for some reason.
'Oh, my codes are terrible.'
'I don’t know what I’m doing.'
Are you solving a problem?
Yeah, it's really awesome.
'Yeah, you're fine.'
Instead, we celebrate all the people who seem to
just write programmes for their own sake,
programmes that are just complex messes
or otherwise.
I'm not actually sure if that answered your
question.
I kind of went off on one.
[ (Laughter) ]
Does that answer your question?
[ Vaguely. ]
[ (Laughter) ]
I guess that'll have to do.
And there was a question at the back.
Do you want to...
Thank you for passing the mic back.
[ Hi. So I completely agree with your point that ]
[ it's great when you have a student who knows ]
[ what they want to create and then you help them ]
[ find the tools to do that. ]
[ And I wanted to make a course like that when I ]
[ was at university, for the students. ]
[ So I tried to make a course and I was like, ]
[ 'Okay' so I’d ask someone on the course, ]
[ 'What do you want to make?' ]
[ And they were all like, 'Huh?' ]
[ Yeah, 'I don't know. You tell me what to do.' ]
[ And I mean, there are some students who ]
[ really took that, but most of the students were ]
[ like, 'No, I’m too used to this.' ]
[ You know, maybe they're just too used to being ]
[ just fed it. ]
Basically, education got to them before you
could help them to learn.
[ (Laughter/Applause) ]
I don't mean to be bitter about this.
My mum was a teacher and she taught me
to ask questions, stand up, challenge things,
try and learn things and basically taught me
how to get into the most trouble I ever
could in my life.
It's the most awesome thing I ever learnt.
Now, I talked earlier about how we want to
encourage people to go off and learn,
but that isn't to say that we shouldn’t provide
some support and guidance.
Really, there will still be times for a set
project, and set things like that, just to get
them started, just to get them...
Well, the first one is always free, as they say.
There is still, you can still provide people
a framework for learning without restricting them.
You can still encourage people to go off
on their own and not dictate their actions.
But you can give them a gentle nudge in
the direction if they're not really sure what
they want to do.
Especially if they're kind of waiting for
the learning outcomes and what they need
to learn for the exam.
Admittedly, if you want to sit and work
on course materials afterwards, I’m probably
quite happy to sit and argue with you
about everything.
But again, to go back to learning preferences,
you need to sort of attack learning from
all sides.
You need to realise that not everybody learns
in the same way.
Not everybody is enthusiastic in the same way
and not everybody really wants the same outcomes
from the course.
And you can't always ask them, because they
don't always know.
It is a bit of a very hard thing to put upon
a teacher, to sort of go,
'Well, you had to sort of encourage them to
do it without telling them what to do,
except of course, when you had to tell them
what to do.'
I'm sorry to put that kind of cognitive dissonance
on you but frankly, if you’re teaching,
you already probably have quite a lot of it
already.
Either that or you're going to curl up into
a ball and cry after I said that.
One or the other.
Oh, we have a question down the front.
Can we pass the mic down?
[ I imagine quite a lot of us learnt to program ]
[ originally on 8 Bit computers which came, ]
[ you switched it on and immediately you could ]
[ start programming. ]
[ These days, kids have got consoles and the like. ]
[ They may have PCs but I don't think you can ]
[ get quite basic immediately, from DOS anymore, ]
[ for instance. ]
[ Do you think we've actually made things harder ]
[ for kids to learn off their own backs? ]
That's a very good question, although I’m going
to do a call back to what I said earlier about
nostalgia.
It's a very easy thing to go,
'The way in which I learned is a good thing
to do and the fun that I had as a kid is the
best one.'
But computers have moved on considerably
since the 8 Bit and new opportunities have
advanced.
Frankly, when people ask me,
"What language should I learn?"
I tell them JavaScript, because they already
have something that runs it and the best thing
is that they can stick it on a webpage and
share it with their friends and show off
instantaneously.
When I was a kid writing an 8 Bit program,
I had to drag them round to my house or copy
it onto a floppy and hope that it didn't break
along the way, but now I can kind of write
a little tiny program and share it with people
all around the world and see what I’m doing.
So instead of trying to look back to how
things worked and how they were awesome,
I think we should try and look to how we can
take advantage of the new technologies and
bits and pieces.
Almost all of those kids may not have access to
a BBC Model M but they do have a phone in
their pocket with a web browser that runs
JavaScript and can do amazing things.
So I’m not going to say it's got worse,
but I will say it's got different.
The goalposts have moved and kind of looking
back with a sort of heady nostalgia,
admittedly I did that earlier with Logo
but actually, on Logo I did write a Logo
interpreter in JavaScript and put it online
and every so often, I banded it two years
ago and every so often I go back and look
through the gallery and see what people
have been creating.
I am somewhere between shocked, horrified
and absolutely surprised.
Sometimes people draw swastikas.
Sometimes people draw giant cocks.
Other times people have found out how to
draw houses or spell out their name,
and various other bits and pieces but as
I look through all of these crap drawings,
I know they’ve been having fun and they’ve
been playing, and they've been enjoying.
And maybe I’ve sucked them into the mistakes
that I have made.
So I guess to answer your question,
although I’m pretty sure I’ve answered it
and I’m probably repeating myself now,
we need to take advantage of the new technologies
rather than just simply looking back to the past.
We can still get the instant on environment.
We still can do these things.
There's things like Squeak.
There's things like Scratch,
there's things like Alice.
There are lots of environments for people
to play and explore that are actually
very accessible and we shouldn’t be trying
to go,
"Well, the only way in which you can learn is
on an embedded computer,"
because when you put it like that,
it does really sound like "Go fuck yourself."
I hope that answers your question without
being completed insulted.
[ No, no. I completely got that. ]
[ JavaScript. You're right. ]
Okay, is there any more questions?
Oh, we've got a question down the front.
Could we pass down the mic and hopefully,
it will be turned on.
Hello.
[ Hello. ]
You’re standing a foot from me,
almost a metre to...
[ I'll stand up face to face if you like. ]
Hello there.
Let's not get the mics too close together.
[ Picking up on your theme of embracing the new, ]
[ why do we need to teach people to program ]
[ at all? ]
[ Why don't we just give them a Stack Exchange login? ]
Because that's teaching them to google for
answers to industry questions rather than
teaching them to program.
Stack Exchange is the most awesome thing in
the world because people no longer have to go
to ExpertsExchange.com to find out why their
undocumented Java library which their boss has
forced upon them isn't working.
Stack Exchange, have you ever;
has anybody ever heard of the term
'The XY Problem'?
The XY problem is this.
How do I get the last three characters of
a file name?
What are you actually trying to do?
I'm trying to get the extension.
Extensions aren't always three characters.
You actually want this sort of thing.
The XY problem is basically that people ask
questions in terms of the solution they understand
rather than the problem and people will ask
questions on Stack Exchange in terms of,
'I've come up against a brick wall along this
really stupid way in which I’ve been solving
the problem.'
'What's the immediate answer I can get to keep
going for the next five minutes until something
else breaks?'
There isn't an encouragement on stack overflow
to actually challenge the person's question
as being valid.
Challenge their actual methodology, their
assumptions as being valid.
There is just a sort of instant reward for
doing this.
If you meet somebody with a high stack overflow
reputation, that means they are probably an
excellent copywriter rather than a programmer.
The entire reward system is about being first
to answer a question, copying and pasting
other people's answers and summarising them
rather than actually helping people understand
the problem in the first instance.
Now, I did mention I hate Jeff Atwood.
I hate him with a passion.
If he's ever watching this talk,
I really do hate you.
This is not a joke. [ (Laughter) ]
Stop writing.
I am never going to forgive you.
You're a terrible person.
But I don't think that giving them a series of
questions and answers by people who
don't know what they're doing is going to be
a good way to encourage them to learn on
their own, experiment on their own
and try out new things.
Don't get me wrong.
Giving them an account with Stack Overflow
can help them in certain ways but I don't think
it's going to encourage the right sort of
attitude, the right sort of, well,
for lack of a better, smaller word,
examining contrapositives.
Challenging their own assumptions, let alone
the assumptions of the rest of the world.
Is there any more questions?
Go on.
[ Who is Jeff Atwood? ]
Jeff Atwood writes a blog called Coding Horror,
where he basically either copy and pastes
from Wikipedia or books that other people
have written and in between, he tries to
solicit his own opinions which are always
terrible.
'Here, look.'
'I'll be writing a book about programming.
Here is a chair that I like.
Ooh, isn’t it cool'
And the only time people actually find his
comments insightful is almost always when
there's a sentence written at the top and
then 15 paragraphs copied and pasted from
Wikipedia.
Joel Spolsky is also a terrible person.
Basically, if you read the book,
Peopleware by Tom DeMarco, you can go back
and see that Joel Spolsky is not exactly full
of shit but basically an excellent photocopier
of other people’s actually intelligent advice.
Actually on Joel Spolsky, he recently wrote
a post a year ago, saying,
'Do you know what I hate?
People who write anecdotes dressed up
as information.'
'People like Malcolm Gladwell who feel the
need to tell a story rather than actually
help people out.'
Without any sort of irony, he also wrote
a book called Gooeys for Programmers
where he talks about,
'I worked in a bakery.'
'Writing a gooey program is very much like
working in a bakery.'
'Let me tell you about this.'
Fred Brookes is the same.
He's written two books, one of which is
So I wrote an operating system.
'Let me tell you about how everything you're
doing is like writing an operating system.'
'So I built a house' is his most recent one.
'Let me tell you about how programming
is like building a house.'
We have this terrible, terrible thing of
generalisation in programming where we find
something that works and we will just
happily mash it into everything that comes along.
It's the same problem I mentioned earlier
about how bringing political philosophies
into programming chat kind of destroys everything.
People will happily take one thing that works
in its domain, throw it away,
throw the domain away and then apply it
somewhere else.
[ It's because finding something that works is ]
[ so remarkable. ]
Well, somebody from the back has just said,
"Finding something that works that is considered
so remarkable."
Not unless you get it right the first time.
JWZ wrote a rant going, 'There is nothing worse
in life than getting it right the first time,
because no one will ever believe you.
And they will spend all of their time making
it wrong repeatedly, until they slowly
learn the things that you learned in order to
come to that decision.'
That just...
This sounds like a communication problem.
Really, we kind of treat programmers as if
they're like solipsists, as if they're individuals
working on their own programmes and never
having to share.
The first time people will ever have to look at
o