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!
This reminds me of an experiment my music teacher did with my class in grade school. I'd completely forgot about it until just now, and thinking back, it may have been one of the things that influenced me to become a programmer.
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.
Not bad, except that these employees are superhuman in one crucial way: You only ever have to give them a procedure once, and they've got it for good, and you can then build on that procedure to define more complex ones.
Except if you give them a procedure that doesn't make sense (Like divide the restaurant by Zero) you either open the restaurant for international terrorists, the place blows up or they snap and go postal.
Nice to see a reference to "The Joys of the Craft" by Fred Brooks (from The Mythical Man-Month). He actually lists 5 really good reasons why programming is so much fun:
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/
For the average person, programming is simply sorcery.
"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.
However, in your example, most people have been on at least one side of that equation, if not (at least informally) both sides.
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.
Many professions have subtleties that the layperson may not grasp at first, but most people can understand the basics.
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.
The difference between my experience and some expressed in the article (and here in some of the comments) is interesting. I'm in my first programming job. I am the lead (and only) programmer and lead game design for a very small new games startup. I'm basically doing what I have been doing by myself in my bedroom for a while, and I dont have to deal with other people.
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.
Programming is very much like carpentry. You have your tools you're familiar with, shiny new tools you just bought and learning to use, and some tools you've heard about that might be better but meh, and you have a vision of what to build ... now start cutting some wood and see what happens.
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.
We can make or own tools, sure, but there are two ways, it seems, most of them are made:
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.
With open source projects there is often a page of feature requests that anyone can contribute to. [0, 1] The problem is that often these are buried deep in a website, and the user has to dig through to find it. The up-side to this is that project maintainers are not buried in a dearth of feature requests. Though for popular projects I don't think it would be hard to find someone to volunteer to sort through the requests acting as a filter or curator.
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.
This seems like a good application for a model like CrowdTilt, as long as you are able to design and estimate the cost accurately. https://www.crowdtilt.com/
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.
A coworker described programming as a one minute long repetitive kick in the balls followed by 59 minutes of enlightening lucid euphoric acid trip but most of that was wasted working out how to avoid being kicked in the balls again and that he didn't know if he was enjoying it or not yet (after 20 years of doing it).
I read "Programming Sucks" last night. While that essay stands well on its own (and is utterly hilarious, in a painful sort of way), it is, as Stokes mentions, a bit one-sided, and this is precisely the counterpoint it needed.
I agree that programming is amazing, but only when you're building something that you personally want and have the freedom to do it the way you want to.
Most "real-world" programming is actually pretty lousy.
Responding to the article's first two paragraphs: I'm about to state a controversial opinion, in the sense that I can't verify it formally. But through my work, volunteering and social interactions, I am slowly believing in it more and more (and I'd love to hear counter-arguments to it).
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.
So how do we programmers acquire the abstract reasoning skills that you say most people don't have? It came naturally to me; I started programming when I was 8 years old (in BASIC on an Apple II), and I don't think there was anything exceptional about my education up to that point.
Through practice and repetition, like every other skill.
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 think getting exposed to things early is a big part of it. Young minds are very malleable. Of course you're not able to understand things completely at a young age (or any age), but those things you can understand and continue to be exposed to become very ingrained in your mental processes and how you understand the world.
This is both a response to GuiA and dpeck. GuiA's comment was right on from my perspective. When I was about 10-11, my class was in our school's computer lab full of new Apple II machines. We were supposed to be writing an essay on the computer so we could print it and turn it in. Computers were so new to us and our teachers that we were still taught to double space after end punctuation.
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.
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.
Most of my coworkers don't claim to be brilliant programmers, but I would say they're pretty good.
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.
> Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms.
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 as a craft is awesome, it is fun and challenging. Programming as a business is usually a depressing "shitshow". This is the most important distinction for me personally.
>> Imagine joining an engineering team […] for a bridge in a major metropolitan area.
> 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.
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.
Don't sell yourself short. By following links from programmer-oriented websites and weblogs, I have seen home hobbyists constructing their own button-triggered pyrotechnics gloves, as one might use for an illusionist's stage flourish. And I have seen remarkable advances in robotic flight, transcranial magnetic sensing and stimulation, and bizarre couch, loveseat, and recliner modifications.
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.
I think the Lego analogy is correct only if you remind people of just how many Lego are needed to build even a decently sized application. Assuming one line of code equals 3 or 4 lego pieces eg. x = func(y), then a decently sized application would require 100,000 Lego pieces.
It's great that you can build tools to help you with programming, but until you make a tool that hits stupid clients in the face and electrocutes incompetent managers, programming will still suck.
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.