The idea of hereditary legislators is as inconsistent as that of hereditary judges, or hereditary juries; and as absurd as an hereditary mathematician, or an hereditary wise man; and as ridiculous as an hereditary poet laureate. Thomas Paine, The Rights of Man
There is nothing quite so destructive as the myth of the natural born programmer, the assumption that some magic genetic variation lets you write the most elegant web shops in lisp. In Is Math a Gift?, Dweck researches how this assumption undermines learning:
We had found in our past research that viewing intellectual ability as a gift led students to question that ability and lose motivation when they encountered setbacks. In contrast, viewing intellectual ability as a quality that could be developed led them to seek active and effective remedies in the face of difficulties
This petulant belief that programming ability is a gift, rather than a skill, often surfaces as a flimsy rationale for the gender imbalance in technology, but actually serves to reinforce the problem.
By the end of 8th grade, there is a considerable gap between females and males in their math grades— but only for those students who believed that intellectual skills are a gift. When we look at students who believed that intellectual ability could be expanded, the gap is almost gone. […] This suggests that girls who believe that intellectual abilities are just gifts do not fare well in math, but that those who think they are qualities that can be developed often do just fine.
In another study, Stereotype Threat and Women’s Math Performance, it shows that telling participants that men were better than women at Mathematics caused women to under-perform on the test—the stereotype creates the gender imbalance. Dweck’s work shows this has an effect when innate ability isn’t presented as a gender difference too:
For some students, the “innate ability” and “natural talent” of these mathematicians were highlighted. […] For the other students, the geometry lesson contained information about the same figures, but portrayed them as people who were deeply interested in and committed to math, and who worked hard and thought deeply to arrive at their contributions
After their lesson, students were confronted with a challenge: they were given a difficult math test [..]. When females had received the lesson that portrayed math as a gift and then experienced this difficulty, they did significantly more poorly than their male counterparts. […] However, when females got the lesson that conveyed the idea that math skills are developed, they equaled the males.
Dweck also shows us what happens if we assert that ability is learned through work, and not a gift: The gender gap vanishes
[Originally], both groups showed sharply declining grades in a math, but after the intervention the group that got the “growing ability” message showed a rapid recovery and earned significantly higher math grades than the control group.
What is most striking for our purpose, however, is what happened to the gender difference in math. In the control group, we observed the typical gender difference, with the girls doing substantially worse than the boys. In the experimental group, that difference almost disappeared. Both groups did well.
In similar studies, all of the learners improved, not just women. Is Math a Gift? demonstrates that belief in gift and natural born ability is toxic to all, and by eliminating it, we won’t alienate so many from technology.
Computer.
Computer ?
Computer :-(
Now you understand. Let's go to computer anonymous.
This Wednesday a friend lamented that they felt alienated from their programming community. They had the temerity to ask to be called a woman rather than a girl, or more accurately, asking to be called an adult rather than a child. Predictably, and despite being a polite request, this resulted in a shitstorm of abuse and cries of ‘Misandry!’ online. This was the final push they needed to abandon the toxic mailing lists and meetups. This left a void waiting to be filled, and so plans began to bubble up on Twitter:
‘now that I’ve alienated myself from the […] community, where do I go for my community love?’
‘lets make our own, it will be called “super code buddies”, we eat a burrito, then drink to forget’
‘a language-agnostic dorks meetup would be very relevant to my interests. Happy to help make it happen!’
This might be the group for you if you want to meet socially conscious nerds to talk about interesting things. This is not an entrepeneurial meetup, nor is it networking: It is a support group.
Imposters Welcome
This is a support group. No-one knows what they are doing.
If you’re worried about not being computer enough, come.
If your day job isn’t code, come.
If you think you’re an imposter, come.
This isn’t a group of experts, just people.
We are interested in the social and technical problems.
We want to include those alienated by the existing meetings and communities, which means keeping out the ones unwilling to act like decent human beings. To be explicit rather than implicit, we wrote a code of conduct.
Don’t harass people. Don’t make exclusionary jokes. Don’t even make them “ironically”.
We want to be inclusive; we don’t welcome homophobic, racist, transphobic, or sexist behavior, amongst others.
We think feminism is a good thing; we think brogramming is a bad thing.
Although we’re meeting in a pub, there is no expectation or pressure to drink alcohol. Don’t question anyone’s choice of drink.
Within a day, we had fifty people register an interest, and as of today, we’ve made over a hundred commits, and more than twenty pull requests, but there is still a lot of work to do. We’re working on how to reach people
outside the tech bubble, and refining the code of conduct.
If you’re about in East London on Thursday the 3rd of October, come and say hello. More remarkably, if you’re in Berlin, Portland (Maine), or San Francisco, there is a meeting happening soon. Austin and Minneapolis are next, and if you’d like to start a group nearer you, fork the GitHub repository and send us a pull request.
It hasn’t been a week yet, we’ve yet to have the first meeting, so who knows if it will work out. That isn’t going to stop us from trying.
Edit: Since writing this post last night, Boston, MA and Austin TX have been started.
There are lots of good reasons not to learn programming: It’s hard, and there are lots of other things to learn. There are lots of bad reasons too, often bemoaned by older, grumpier curmudgeons on the internet, angry that someone has a hobby and isn’t taking it as seriously as they do.
But if you aren’t dreaming of becoming a programmer — and therefore planning to embark on a lengthy course of study, whether self-directed or formal — I can’t endorse learning to code. Yes, it is a creative endeavor. At its base, it’s problem-solving, and the rewards for exposing holes in your thinking and discovering elegant solutions are awesome. I really think that some programs are beautiful. But I don’t think that most who “learn to code” will end up learning anything that sticks.
Although punctuated with well placed jabs at the industries espousing “Learn to Code in 20 minutes”, the moral is simple: Don’t bother trying. Jeff Atwood made similar screeches in Please Don’t Learn to Code
The whole “everyone should learn programming” meme has gotten so out of control that the mayor of New York City actually vowed to learn to code in 2012. A noble gesture to garner the NYC tech community vote, for sure, but if the mayor of New York City actually needs to sling JavaScript code to do his job, something is deeply, horribly, terribly wrong with politics in the state of New York.
After poking fun at a mayor’s hobby, he then neatly demolishes a couple of straw-men, drawn together with the same old assumptions that the only reasons to learn to program is to get a job, change the world, or to solve a problem. To Atwood, learning to code is as important as learning plumbing, but I can make similar comparisons too: Why bother learning mathematics? You’re not going to be an astrophysicist. Why bother learning to write? You’re not going to become a poet. Why even bother learning to play guitar, you’ll only be crushed by the music industry, and so on. I’ll stop before I get to yet another car analogy. Encouraging professionalism doesn’t have to come at the expense of learners or hobbyists.
Personally, I don’t advocate learning to program to create more fuel for startups to burn—I just I think it’s fun. I’m a fan of Seymour Papert, who wasn’t trying to create a workforce, but trying to give children a sandbox for their ideas. The computer is not just a machine to enable bureaucracy, but an opportunity for people to play and create. Who gives
a shit if they don’t learn the arcane corners of the ANSI C standard.
My advice is to ignore the monks in their monasteries, complaining that teaching the plebeians to read and write won’t give us better software. When you ask them how to learn, they will tell you to learn how they did, on awkward and old machinery, in what they describe as character building exercises, and yet at the same time they will dismiss you if you learn for the same reason they did: Curiosity.
Like before, it’s really a look at the social problems around programming, and the culture we’ve created, rather than algorithms and data structures. For those who’ve been programming for a while, I hope you’ll be entertained by war stories, and for those who are just starting out, I hope you’ll leave feeling a little bit better about your code.
Come here and work on hard problems, especially the ones on our doorstep
Almost one year ago I stood up in-front of a bunch of people and said “We learn to code badly”, and uneventfully went back to my day job.
More recently, by accident and mostly luck, I stumbled into an opportunity I wasn’t sure existed—Write code to help people learn through play. I’ll be working at Code Club: A worldwide network of coding clubs for children aged 9–11.
It isn’t going to be glamorous code filled with algorithmic delight. Not even close to code from the book, and I might have to commit horrors that would even make Notch wince. That’s ok—I’m not trying to solve technical problems, but social ones.
My goal is not to teach undergraduate computer science, but to help bring about algorithmic literacy. I believe the most basic computer interaction is in some way programming—providing a set of instructions for it to follow—but programming at its best is expressing new concepts and ideas that aren’t already there.
“Dude, Sucking at something is the first step to being sorta good at something”
Let’s face it: I’m not going to get it right first time. I’m not Jean Piaget or Seymour Papert, but hopefully I can inspire someone younger to play with code, and even perhaps fix my code too. I’m not expecting every child to turn into John Carmack, but to understand that they can use the computer as playground for their own ideas.
I was the special guest on the Amazeballs Podcast. If you want to hear me babble at @ntlk and @hyper_linda about things I care about (including programming), you might enjoy it. No promises.
Come here and work on hard problems… except the ones on our doorstep.
I’m quite lucky. In March I took the time to take a genuine break from my real life, and escape to San Francisco to celebrate my thirtieth orbit around the sun. It was my first time outside of Europe, as well as my first time on American soil.
What follows is a very personal recollection of my culture shock. I wrote it for a much smaller audience, but friends have encouraged me to be a little bit more public about my experience. It isn’t really so much about programming, but one idiot’s view from the epicentre of the startup bubble.
I normally shy away from writing about politics, as I’ve witnessed what normally happens when programmers engage in debate. Besides, if using a computer doesn’t qualify you to espouse about people, what does? After all, technology is social before it is technical.
Last night, someone told me “In California, there isn’t a conflict between being a Capitalist, and a Liberal”, with a wry grin on his face.
It is decidedly weird here. i’m staying in Castro, which is like travelling into the future. Not free from violence or persecution but a far safer and tolerant place than many I’ve encountered. Then off to downtown, stepping over the homeless, weaving between the street corner schizophrenics. After a while, you’ll encounter a faceless industrial building emblazoned with an all too familiar logo.
Inside, once you pass the checkpoint, free food, free beer on taps, somewhere between a coffeeshop and a hackerspace, a bunch of rich people on macbooks with the appropriate stickers. Then back outside to the street to watch people die on your way to a microbrewery. A long drawn out argument about scala as you avoid eye contact with the rest of the world.
The companies here are more than just playgrounds, they’re enclaves. Many people here don’t socialise outside of their work, and when they do, it’s ex-coworkers. As a first time visitor i’m surprised at how isolated many of the people here are. in return for building a social space, the companies enable workers to pour their life into their work, with little time outside of it, beyond sleeping.
I’ve been here for nineteen days now, and it’s still shocking: the disparity between rich and poor. Thing is, those in poorer situations flock here, because they can get healthcare, support, and help, but other times it just feels like a passive aggressive fuck-you-got-mine. if you don’t tip, it isn’t so much a snub, it’s saying “i don’t think you deserve healthcare”. Alternatively for those with healthcare provided, it locks them into their job.
The cost of living is always increasing, and the flashy money from silicon valley is accelerating the gentrification of SF. rent-control is a last ditch effort to prevent those who grew up here from being displaced, but in return prevents them from being able to move within the city.
The dissonance here is enabling: come here, earn money, live in our playground, and don’t mind the poor, they’re better off here than many places in America. At least it’s not so cold that people will die sleeping rough.
I’m not sure if sf is pushing me to radicalism or conformism. It’s a tempting bubble—a hedonistic lifestyle where you can relive your early twenties, assuming you can live with the implicit death penalty for the poor and disadvantaged.
Now I’m back safely in my Scottish rut, I can’t say I’ve escaped the gaping void between rich and poor. It just isn’t so obvious on my doorstep.
Richard Hamming gets to the heart on what differentiates a prolific scientist from an ordinary one.
“If you do not work on an important problem, it’s unlikely you’ll do important work. It’s perfectly obvious. ”
Another key idea is that of an attack. These problems are hard because they are not amenable to brute force. You need to find a trick to make the problem approachable.
By important I mean guaranteed a Nobel Prize and any sum of money you want to mention. We didn’t work on (1) time travel, (2) teleportation, and (3) antigravity. They are not important problems because we do not have an attack. It’s not the consequence that makes a problem important, it is that you have a reasonable attack. That is what makes a problem important.
Although watching this may induce an existential crisis in grad students, understanding the ideas presented here is the key to making a difference with the work you pursue.
Although many entries posted here are far from optimistic, and often glib criticism dressed up in technical jargon, they don’t always come from a position of arrogance. It is not that my code is devoid of mistakes, but understanding the mistakes of others has given me a perspective I wouldn’t be able to achieve in one lifetime of terrible code.
I’m yet to make mistakes worth talking about, but still I feel I should be a little more honest about the terrible code I’ve written.
My earliest adventures with BBC Basic, OPL16 and JavaScript were spent reimplementing primitives. Although I was flushed with pride the first time I derived a sort algorithm, in hindsight I don’t think an exponential runtime was worthy of such hubris.
I then moved on to writing terrible perl, often cgi-bin scripts. It wasn’t until I came back to perl years later that I truly understood why I kept seeing HASH0x1729 in my output. I still wrote code for my amusement rather than clarity, leading to such gems as:
my $spoon=fork();
Later, university drilled Java into me, and I was one of the lucky few not to ward off object orientation with judicious use of static. They did fail to shake out stupid variable names or tricks. I once used an XOR swap to wind up my tutor, and the punishment was explaining it to the rest of the class—he sat astonished as I spent the next hour explaining that one line of code. The moral: Giving me an audience didn’t make me any less of a smart-arse.
As I moved from one language to another, the hardest thing was not to pick up the new ideas but to abandon the old ones. My first Python program had all the hallmarks of a Java refugee. Not decomposing my program into objects but simply wrapping up global variables inside of them. My second python program wasn’t too friendly either.
def color(self):
raise Exception("american")
I’ve even had the honour of having my first piece of ruby mocked on twitter. The errant snippet below can be replaced by send():
response = obj.method(methodname).call(*args)
One of the kinder responses caught me in the act —"That looks like a python programmers first ruby program". No matter how old I get, my code is still embarrassing. Especially the production code i’ve committed (both in the criminal sense and the version control sense).
# ugh
task = task.task.task
This particular line was eventually refactored away after being written in haste in a life-or-death moment for a project, and rationalised as artefact of laziness or sleep deprivation. The admission of disgust in the comment may not have explained why the code looked bad, but my coworker knew I already felt bad writing it. I was saved by a public shaming by those three letters.
I don’t imagine this will ever change. The moment I stop being embarrassed by my code is likely the moment I stop learning new ideas. Or perhaps the moment I gain engineering discipline, but that’s a long way off.
The biggest change for me as I’ve grown as a programmer has not been how terrible my code looks, it’s knowing when i’m writing it. At least now I know when I’m up to no good, and can weigh up the tradeoffs between beautiful and working code.
On the left is a pristine network diagram. On the right is how most networks look in practice. This isn’t to bemoan the death of cable lacing, but an illustration of what Richard Cook calls ‘Systems as Imagined’ versus 'Systems as found’ (stolen from his excellent talk, How Complex Systems Fail).
With any complex system there is always a conflict between intent and implementation, and with protocols there is a always a mismatch between specification and reality. If you make a specification too small, implementation specific behaviour creeps in, and if you make it too long, no-one has a chance of implementing it correctly. A good specification has to strike a balance between prescriptive to descriptive, explaining how things should work, but begrudgingly admitting how existing implementations behave. HTTP is no exception.
From the outset, HTTP seems like a very simple protocol. You make a request, you get a response back. 'HTTP as Imagined’ is rather straight forward:
Although RFC 2616 officially defines HTTP, HTTP is also defined by how popular browsers and web servers behave. The RFC is over a decade old, so these behaviours are often discovered through spelunking source code, or nightmare debugging sessions. A robust implementation needs to handle the obscure edge cases of the standard, and the mind boggling way in which others have implemented HTTP. For example:
Headers can span multiple lines.
Line terminators are meant to be CRLF, but code should accept a solitary LF.
Blank lines can appear before the first line of a request.
Response start lines may only have a code, not a phrase.
Deflate, gzip are used interchangeably.
Get messages can have a body, but not every server knows this.
Some servers will let you get away with the full url in the request line.
You can’t accurately parse a http response without knowing the method used.
The length of a response body is indicated by a mixture of the response code, the Transfer-Encoding header, Content-Length header, Connection header (and the request method).
A simple request and response may not be so simple in the wild. 'HTTP as Found’ may require sick-bags.
GET http://www.example.org/ HTTP/1.1<LF>
Host:<LF>
www.example.org<CRLF>
Content-Length:0<CRLF> <LF>
If this looks bad for HTTP/1,1, at least it isn’t HTTP/0.9. This prehistoric version of HTTP is simpler to parse, in the sense that there are no headers or start line in the response, just the content. Despite being as old as the web, there are situations where a modern robust HTTP server will return such a decrepit response.
GET /a_very_long_url............................ HTTP/1.1<CRLF>
Host: www.example.org<CRLF> <CRLF>
hello
If you ask for an enormous URL, some servers will only process the first thousand characters of the request, without seeing the HTTP/1.1 at the end. In particular, NGINX will assume it is a HTTP/0.9 request, and then strip the header from the response. Robust browsers will fail to parse the response as HTTP/1 or above, assume it’s HTTP/0.9, and render the entirety of the response as HTML.
(If this disgusts you, don’t look at character set detection)
Thankfully, the newest draft of HTTP captures much the folk knowledge needed to write robust implementations. You may feel dirty, but at least your code works.
