
What Programming is Like - samstokes
http://blog.samstokes.co.uk/blog/2014/05/01/what-programming-is-like/
======
falcolas
How I describe programming to non-programmers:

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.

~~~
mwcampbell
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.

~~~
falcolas
True, but procedures can be coded as "go to page 5, do instructions 2 to 55,
and move to instruction 3 on this page."

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!

~~~
angersock
And by page 5, we really mean the 6th page of the book.

Oh, and instruction 2? It was the third instruction, and mentioned that you
should switch books.

------
henrik_w
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/](http://henrikwarne.com/2012/06/02/why-i-love-coding/)

------
mratzloff
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.

~~~
untog
_" How did this iPhone app get built?"

"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.

~~~
scarecrowbob
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.

------
everyone
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.

~~~
snorkel
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.

------
josephschmoe
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.

~~~
garrettgrimsley
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.

[0] [http://dev.deluge-
torrent.org/wiki/Development/PluginIdeas](http://dev.deluge-
torrent.org/wiki/Development/PluginIdeas)

[1]
[https://github.com/WhisperSystems/TextSecure/issues?labels=f...](https://github.com/WhisperSystems/TextSecure/issues?labels=feature&page=1&state=open)

[2] [http://bithub.com/earnpoints](http://bithub.com/earnpoints)

------
bananas
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).

------
aaronem
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.

------
agscala
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.

------
GuiA
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.

~~~
mwcampbell
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.

~~~
dpeck
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.

~~~
scobar
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.

------
mqsiuser
Fred Brooks statements are like 40 years old and it's important what he said
:)

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

~~~
josephschmoe
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.

~~~
mqsiuser
So, just as a reference:

"Google I/O 2009 - The Myth of the Genius Programmer":
[http://m.youtube.com/watch?v=0SARbwvhupQ](http://m.youtube.com/watch?v=0SARbwvhupQ)

There are quite a couple of possible views in IT, which makes it hard for us

------
JacksonGariety
> 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.

------
JanneVee
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.

------
qwerta
>> 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.

------
elwell
> We can make more visual, interactive, intuitive tools for understanding the
> behaviour of programs

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)

------
ebbv
I always explain it to people like this:

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.

~~~
logfromblammo
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.

------
sixothree
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.

------
normloman
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.

