What Programming is Like
blog.samstokes.co.uk
blog.samstokes.co.uk
Imagine you have a set of mentally handicapped employees. They are capable of following instructions perfectly every time, but are completely unable to intuit how to do something without very explicit instructions. That is, they don't know how to scramble eggs without explicitly stating every single minute step (including how to get an egg from the carton (in different positions every time!), what to do if the carton is empty, how to order more cartons of eggs, how to identify spoiled eggs, etc).
Now imagine that you are using these employees to staff a restaurant. You have to write detailed, explicit instructions in a way which will give you a constantly working restaurant given that the customers, stock, and equipment will change parameters minute over minute, day after day.
Now, imagine expanding your restaurant into a chain. How will the programming have to change to work in a building with a different configuration? With different operational hours? With different recipies?
Now, imagine your boss wants to change the menu slightly EVERY BLOODY DAY!
That is what we do.
He was trying to teach us the idea of explaining yourself more clearly (he was one of those teachers that went off on tangents totally unrelated to music when he felt there was an important life-lesson other classes might not cover). He stood at the board and told us that he would draw whatever we said, and the goal was to have him write out a musical staff and certain notes on the chalkboard with no physical gestures, just talking. As if we were having a conversation over the phone. He went around the room giving every child a turn at a time.
So it starts off "Ok, draw 5 lines."
And he gets a piece of paper and drew 5 horizontal lines.
"No! No! On the board!", said the next one.
So he goes to the chalkboard and draws 5 lines in random places.
"No! No! make them horizontal!"
And he drew 5 horizontal lines that squiggled around and were of random lengths.
And this went on and on until you we ended up with something like "On the chalkboard draw 5 straight horizontal lines, about 1 inch apart, and all 2 feet long." And then we still had to figure out how to explain drawing in notes on the correct line, whether the circle was filled or un-filled (quarter note, half note, etc).
We never actually finished, most of the kids got too bored. But I thought that was such a fun lesson. Almost 15 years later I can still recall it as clearly as if it were last week. I've had a few intro programming or algorithms teachers explain a similar concept. A robot baking cakes is a common one, or that programmer joke ("buy butter and if they have eggs then buy a dozen."), but actually shouting commands someone as inept as a computer really made it sink in.
Of course page 5 was probably written by someone else, because it's probably a very basic instruction. But that just adds to our fun as programmers!
Oh, and instruction 2? It was the third instruction, and mentioned that you should switch books.
1. The sheer joy of making things.
2. The pleasure of making things that are useful to other people.
3. The fascination of fashioning complex puzzle-like objects of interlocking moving parts, and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning.
4. The joy of always learning, which springs from the nonrepeating nature of the task.
5. The delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of imagination.
All excellent points, and great reasons why I still love to code (I've been coding professionally for 25 years so far). I wrote a bit more in "Why I Love Coding": http://henrikwarne.com/2012/06/02/why-i-love-coding/
"How did this iPhone app get built?"
"Um, someone was on a computer, and typed things on a keyboard… uh…"
is not that different from
"How did this otherworldly vortex open and begin spewing demons?"
"Um, this guy was waving his arms, and then it just appeared…"
In the past, this was treated as the inscrutable dark art it is for most people, but now it's blasé.
"That's Peggy, she's HR… Tony, he raises the dead… that's Jim, sales…"
It's therefore unsurprising that the average person could not care less if a given program uses all the best wizarding standard practices, unless it has some horrible side effect--and even then, probably not.
"The wand has a low risk of incinerating the person who uses it."
"How low?"
"Probably 1 in 1000."
"We'll add a disclaimer. Ship it."
The average person has no desire to learn about it beyond the surface trappings. It's hard, you have to learn a lot, and it's boring reading spell books all the time. Sure, necromancers use a lot of garlic, but as to why…? Who cares? Get back in the black spire and finish the undead army already.
"Um, someone was on a computer, and typed things on a keyboard… uh…"
I'm not so sure.
"How did that child get taught?"
"Um, someone stood up in front of them, talked to them and got them to do exercises... uh..."
I think most professions have a dark art to them that the average layperson does not understand.
I mean, it's true that I have no clue how to run the machine that mounts a tire on an automobile wheel, but I've at least put a bicycle tire on a wheel so I have at least a little idea of what might make it complicated.
The idea that there is perhaps a larger gap between casual users of technology and the people implementing that technology has some merit to it.
I wonder if, in a sense, what defines "technology" is that size of that gap: it seems like there could be a scale along which we could measure how much we need a techne in order to comprehend the working of something. Although that really would probably be overstating it, I do think that some kinds of work require a lot more technical understanding to appreciate/do... but I could be wrong about that.
Your example is too simplistic. The answer to that question would include information about academic area, lectures, homework, exams, schedules, and what makes a good teacher and a bad teacher. The layperson could go into detail on any of those subjects, citing first-hand examples.
So, I think of programming like carpentry. Working on a game project I feel like a master carpenter, an artisan, who designs and builds. If I had been tasked with building a nice desk say, I am free to design it, choose my tools and materials and build it how I see fit. If the finished product is fit for purpose and built on time my boss will be happy.
Also, in a former life I used to be an architect (with real life buildings) the bridge metaphor in the article reminds me of that. Perhaps the phenomena described in it are simply inherent to any large project that requires multiple people to cooperate in order to design it.
Just like in carpentry you're busy thinking of several things at once: Where did I put my hammer? How will I clamp this to that? Wouldn't it be easier if I cut all these pieces together? I know I should glue this here but screws are good enough ... make a big mess then stand back and admire it all.
It's a practiced art of using tools to make something, it's just the end result appears on a computer screen.
It's not hard to learn either, just start simple. Put a word on the screen. Now draw circle on the screen. Now try to make the circle bounce. Now find shortest path between N number of cities in constant time.
1. Commercial companies make tools they need. 2. Private individuals make tools they think are interesting.
The problem with this approach? There's no democracy. There's no way to know, currently, what the community actually wants or needs tools-wise.
If I could donate a couple bucks to get some small tool I need made and put on Github with some basic standards (can download from maven central, for example), I most certainly would. There's just no obvious/easy way to do that right now.
What if you could put bounties on specific accepted feature requests, like a targeted, more user-friendly BitHub?[2] You could even offer small bounties for submitting a feature request that is accepted and implemented. I think that this would be reasonable because the "idea person" is adding some value to the product.
[0] http://dev.deluge-torrent.org/wiki/Development/PluginIdeas
[1] https://github.com/WhisperSystems/TextSecure/issues?labels=f...
It would have to operate as more of a bounty system, maybe let programmers/companies bid on the project first to determine the $ goal. There could even be "stretch goals" with additional features added, or at certain contribution levels you get to request a specific feature.
I am not sure how this could be turned into a "living project" in which people can continue contributing funds in order to have additional features added.
Most "real-world" programming is actually pretty lousy.
I think the reason why the average citizen has no idea of what programming entails, by contrast to a doctor or a lawyer or a fireman etc., is that programming mainly involves abstract reasoning to a level which most adult people simply can't grasp. Not because of their intellectual capacities, but because it's never been properly fostered or developed through their education.
A fireman puts out fires and assists in emergencies, a teacher teaches a classroom of students, a salesman tries to sell whatever he's selling - all those professions have a fairly obvious mapping to the outcomes they produce.
But programmers are much harder to intuit: on one end of the chain you have guys wearing tee shirts and flip flops sitting in front of their computer all day wearing headphones; on the other end you get websites and iPhone apps and GPS software (and those are only the things with which the average citizen is familiar). Understanding the link between the workers and the outcomes they produce requires some familiarity with the symbolic manipulation that's involved. Given this, it's fairly understandable why if one weren't familiar with this process, it'd seem reasonable that a computer programmer could just as easily stop nuclear terrorists or put a curse on their enemies with 3 keystrokes.
Abstract and logical reasoning are crucially missing in the modern education we give to our kids (witness the way math is now taught in the US, in ways that make mathematics become some kind of weird automatisms, stripping them away from everything that makes mathematics, mathematics). Repeat this over years and years, permeate the culture with it, and you get citizens who not only don't get this entire world of symbolic reasoning, but also for whom bridging that gap has become near impossible.
I've actually gotten in great conversations with the non-scientific type at house parties, conveying basic computing and logical reasoning concepts. I once met a girl who was a textiles worker - we got in a great conversation about Jacquard looms, which she had studied in college - and from there I was able to get her to play with the ideas that lead to computation and all that fun stuff.
What would be cool is a TV show which would do to computing what Cosmos did/does to science (I have non-scientific friends who deeply resonated with the new Cosmos and loved it, and the ideas it presented, pushing them to seek more). I wonder who we should pick for our Carl Sagan/Neil deGrasse Tyson.
BASIC certainly didn't come "naturally" to you - I doubt you were born with an innate notion of for loops, variables and methods. Rather, you played with it, put it together, you enjoyed it so you kept at it, and you became better over the months and years.
It wouldn't have been any different if the skill had been playing an instrument, drawing, writing short stories, etc. - especially when you're 8.
There's nothing special about the skills involved with programming themselves - it's just that they're hard to develop outside of mathematics/programming, and schools aren't that preoccupied with conveying them, so in the end very few people get to develop them from a young age (and those who do tend to all fall in similar buckets: upper middle class with enough money to own a computer, initiated by a programmer parent or relative, etc).
I noticed a classmate messing around in a totally different program, and asked what he was doing. He said, "Come here, check this out." He hit enter, and on the screen appeared the prompt, "What is your name?" He said, "Go ahead. Answer it." I typed in my name and hit enter. Almost immediately the computer responded with another question, but this time it addressed me by my name. My first thought was that, somehow, this machine consciously knew it was communicating with me.
I had to know how this kid made the computer act like that. He showed me the BASIC code he used to store my input in variables and reference it later. I understood what he taught right away, but it certainly didn't come naturally to me. I was fascinated by programming, and wanted to know what was possible with all of the stuff I hadn't learned yet. I was lucky to have been exposed to it so early. If we had been doing what we were supposed to, I wouldn't have had that opportunity.
dpeck, you mentioned that young minds are very malleable. I completely agree. I inferred (possibly inaccurately) from that statement that older minds are not as malleable. I would word it differently (and probably flawed). Minds that have not yet submitted to the authority of the status quo and thus accepted the limitations therein are still open to and actively seek discoveries which may influence their perspective. Many adults, hackers in particular, continue to explore even when they're explicitly told not to.
So, I would argue that all minds are very malleable. Some who desire control aggressively act to corral many minds into spaces that restrict curiosity and exploration. Until a mind has been corralled into one of those spaces, it remains very malleable. I believe that early exposure is certainly a great benefit, but there are many adults who could become great programmers who have not yet started.
Having a perspective that is likely foreign to HN, I can offer some insight from a beginner's point of view. I am fortunate that the projects I have been interested in until now have been profitable enough to support my family. While many of those projects required a strong understanding of what's going on behind the scenes of a program, I didn't really have to code very much. I did learn whatever programming ability I needed in order to make my programs meet their objectives without error.
During tough financial times and in between projects that interested me I'd curiously browse job listings for programmers. From a beginner's perspective, even a beginner who's willing to learn, they're daunting as hell; BS required, MS preferred, 10+ years experience in programming, 5+ years experience in a language that was released 3 years ago, etc.
All you seem to hear about are these self-proclaimed prodigies who taught themselves to code just after kindergarten.[1] Educational resources are taught by the types of programmers those jobs seem to be targeting. So programmers at your instructor's level will be your direct competition for employment. If you're an expert at anything, then you realize how much you still have to learn and the beginners are so much farther behind that. So a programmer with 10 years of experience who's still improving seems tough to compete with when you're getting started.
I understand that it's relatively simple for a beginner to become a good programmer in just a year or so. But from a beginner's perspective, jumping into it doesn't look as easy as it actually is.
I apologize for the long response. Thank you for your time.
[1] I'm not implying that everyone who learned to code young thinks they're a prodigy. I learned young, and I admit I'm still a novice.
All the attempts to go beyond that, to understand, to build, that fosters abstract reasoning.
That is why teaching programming is so important. Not to teach people a skill they may apply later on, but to create insight and understanding.
Of course, Feynman was an amazing "explainer" of complex things. I can't think of a modern analog. I'm hoping other commenters will chime in and prove me wrong.
I am on the things sucks side. IT seems to be in it's dark age
And it's negative that teams don't scale ;)
And the single one genius (that he proclaimes to be 10 times more productive) leads to a lot of trouble
Everyone thinks he is the one
I'd like to think I'm productive but it's for a simple, stupid reason:
I like to use libraries to write as little code as possible. I re-architect my code when it gets too complex and I test my code locally. I only re-invent the wheel when it's absolutely necessary and even then, I try to make it a small, re-useable package that only requires one or two lines of code to use.
Management and QA don't bother me. My integration phase lasts about an hour, compared to weeks for others.
That's what a real "10x" programmer is: someone who follows practices, cares about re-use and doesn't need to re-invent the wheel. If a cowboy coder claims to be a 10x programmer, he's probably the reason everyone else is only a 1x programmer.
"Google I/O 2009 - The Myth of the Genius Programmer": http://m.youtube.com/watch?v=0SARbwvhupQ
There are quite a couple of possible views in IT, which makes it hard for us
This is true of poetry as well. The pattern with which you arrange words in sentences, and sentences in paragraphs, can summon up an infinite number of visuals in someone's head. Words are brilliant in that they are literally the bridge between two people's minds.
The poet is the programmer of the imagination. There is value in both the words themselves and images that the poet/programmer elicits.
> Programming is like building structures out of Lego, but I never run out of Lego bricks
Nice two articles. One says programming sucks, reply says programming is amazing.
I would say programming is like building stuff out of Lego bricks. If you are building bridge (or anything people depend on) and have some sort of engineering self integrity, than it pretty sucks.
Just curious what the HN pulse is on this topic:
Does anyone think text-based programming will eventually fade out as sub-optimal, or is text the epitome of efficacy?
(let's ignore the likelihood that after the singularity all good programs will be written by AI)
It's as close as I can get in the real world to being a wizard. I will never be able to shoot fireballs from my hands or cause a couch to fly across the room with my mind. But with programming you can cause things to happen with only thoughts and words.
A programmer's gift is taking an impossible dream and systematically disassembling it until it is a giant pile of tiny possibilities.
But first, let's define the requirements. Does the couch need to fly across the room more than once? This room specifically, or any room the couch happens to be in? Does the couch need to be intact after it lands? How much payload weight should the couch be able to carry? Does the payload need to be intact after the couch lands? To what extent will the couch be expected to change its course mid-flight? Should the couch be upholstered in top-grain leather, suede, natural fiber cloth, synthetic cloth, or plastic? When you say "cause a couch to fly across the room with your mind", do you mean that your mind should be invested into the couch in some way, or that your mind would be causing the flight? Is the "or" you use to join the flying-couch requirement with the hand-fireball requirement exclusive or inclusive?
This is why people don't understand programmers. They say "why all these questions? I just want to be like the Chesterfield-flinging version of Magneto, from X-Men!" And then we just nod, cross off the potential requirement about uploading a human brain into a couch, and try to guess what else they really wanted, but cannot adequately explain.