
Is learning to program inherently hard? - gnosis
http://computinged.wordpress.com/2010/04/14/is-learning-to-program-inherently-hard/
======
51Cards
Is learning to ride a unicycle hard? It is if you don't have inherently good
balance. Is linguistics hard? It is if you don't have a good associative
memory. Is math hard? Is carving a wooden bowl on a lathe hard? Is pro-Hockey
hard? Is sculpture hard? Metal working? Philosophy? Music?

The percentages of people with specific inherent skill sets will vary widely
in society, so 'hard' is best defined as 'requiring a skill a smaller
percentage of the population possess'. Good programming does require specific
skills, but I don't see it as being any more difficult than other specialized
tasks.

I don't find programming hard at all... perhaps that is because I started very
young, perhaps it is just a 'natural' ability to understand and evaluate
systems. To me it's second nature. However when I watch an artist form a
mental image then extract it from a block of stone, or I watch my math PhD
friend throw around set theory and abstract dimensions like cake recipes... I
am fascinated.... and lost.

Hard is relative.

~~~
jseliger
_Is learning to ride a unicycle hard?_

I think the difference here is that riding a unicycle is a fundamentally
bounded problem: you balance, you move your feet, you do a couple of other
things. By contrast, programming is effectively unlimited in its potential
problem domain.

 _Philosophy? Music?_

These are both hard to do really well, but they have a much greater margin for
error and often aren't provably correct or incorrect. When I write an academic
paper, if I have a typo on the fourth page, the entire rest of the paper won't
catastrophically fail. When I write a program, however. . .

 _Hard is relative._

Very true! But some fields still, at least to my mind, feel harder than
others. One (limited) way you could look at "hard" is in the context of
universities: I've seen dropout graphs for various majors. It's not at all
unusual for someone to go from electrical engineering to com, or CS to
English, but I've yet to hear any English majors say, "English was too hard
for me, so I switched to Chemical Engineering."

~~~
mootothemax
_When I write a program, however. . ._

It might not catastrophically fail, but it might mean anything from not
compiling through to not outputting a newline or create a possible security
issue via a buffer overflow.

Like the majority of things in life, it comes down to shades of grey, and
that's why it's tricky at times ;)

------
kenjackson
Programming is hard, period. Knuth has noted that its so difficult for him
that when he is programming he can't teach courses, and he's among the best
programmers in history.

Jon Skeet wrote a blog on the topic:
[http://msmvps.com/blogs/jon_skeet/archive/2009/01/29/program...](http://msmvps.com/blogs/jon_skeet/archive/2009/01/29/programming-
is-hard.aspx)

Jon Skeet is right. Programming is hard, except the most trivial tasks. And
anything that is not trivial is probably broken. But we're OK with things
being a little broken, and we've made users bend to our will sufficiently now
that we have pushed much of the cognitive load to the users.

~~~
gnosis
_"Programming is hard, period. Knuth has noted that its so difficult for him
that when he is programming he can't teach courses, and he's among the best
programmers in history."_

This reminds me of something I've read about writing:

"A writer is someone for whom writing is more difficult than it is for other
people." -- Thomas Mann

I wonder if this also applies to programming.

That is, perhaps the reason programming for Knuth is so hard is that he has
such high standards and that he's working on such difficult problems.

------
joe_the_user
I would note that the author jumps between "teaching programming is hard",
"programming is hard" and "learning programming is hard". None of these are
equivalent statements about a field in general (even if they're all true
here).

Still, it seems like in fact _saying things about_ "programming" might also
being inherently hard!

I mean, we can say that the halting problem is inherently but the halting
problem doesn't reflect the day-to-day practices of the working programmer.
Yet how do we characterize what does? The boundary between programming and
using computers is fuzzy and given Church-Turing, just about defined activity
can be encompassed in using a computer (a lot of machinists have become
"programmers" of numerically controlled machines but this use is more similar
to artists using Photoshop than software engineers using c++). One might argue
that the advance of computer technology will create more and more professions
which involve the high-level use of computers but won't be "programming as
such" (spread-sheet use, UI design, etc).

By that token, if "real programming" is what's left when you've codified the
other occupations, one could argue that it is inherently hard. But we're still
a bit at the level of tautology.

------
inovica
As a 'business' guy, I taught myself to program so that I could communicate
effectively with my team. It was damned hard - partly because I was doing it
on an evening and (if I'm honest) I wasn't that interested in it... at first.
The more I learned though, the more that I understood that its about solving
problems and as soon as my brain understood that it was a challenge it became
more fun. I will admit that I am still not a very good programmer. I'm slow,
but I treat it as a hobby now and whilst its probably amusing for the people
on my team I enjoy the feeling I get when I create something.

To any of the non-programmers on who read HN a lot, I'd recommend doing what I
did

~~~
klbarry
I've thought about this for a while. Where did you start, and what languages
are best for this kind of toe-dipping? Also, what kind of time investment did
you have to put in?

~~~
inovica
Well, I've been in business a while, so the first language I learned was
called Cold Fusion (I think now owned by Adobe). I then tried learning PHP,
but there was some kind of mental barrier there unfortunately for me, though I
think I'd be OK with it these days. I then moved to Python which I've found to
be a great language. There are a lot of free online books out there. In terms
of investment in time, I just started off doing an hour a day. As I did not
have anything specific to do, with any timeframe, this worked well for me and
did not impact on the day-to-day activities. I will say though that you need
to set yourself a challenge fairly quickly as this is the only real way to
solidify the theory in your mind. The first one for me was a small crawler to
screen scrape some data from a site, put it into a database and search it. One
of my team could have done it much quicker of course, but the sense of
achievement when it (finally!) worked was great. Hope this helps

------
another_ali

      learning to program is deceptively hard.
    
      First you think it hard, 
      then you think its not, 
      then you think its hard, 
      then you think its not,
       ...

------
araneae
I think what makes programming particularly hard is that there is such a large
space of possibilities. There's pretty good research out there that people
flounder when there are too many choices. When I was first starting out I
remember being paralyzed by that; I could think of several ways to write this
one algorithm, and how did I choose? What helped was learning about efficiency
in programming, simply because learning "best" practices was a way to limit
the space of possibilities.

There are, of course, parallel examples of open problems- writing a novel is
much the same way, I think. And I think most would agree that writing a novel
is also hard. And doing original research also falls under this umbrella.

------
erikstarck
Hard? It's easy to write one line of code that works. Anyone can do that. It's
easy to write two lines of codes that works. Anyone can do that. Now you just
continue. See, not too hard!

No, of course the complexity grows for each new instruction - and that's why
it's hard. Software engineering is about managing this complexity. Programming
is the easy part.

------
pangram
Programming is probably as challenging as any other intellectually demanding
task, but it does have one advantage to other skills: it can be done fairly
cheaply. It doesn't require any sort of capital investment other than a cheap
netbook (or someone could probably even learn on machines in the library),
there are tons of high quality tools and tutorials out there that are
completely free, and there is a large community of people that are very
accessible and actually like helping other people.

------
hasenj
I think he got it spot on with the mental model stuff. People fail at
programming because they've learned to always use plug-and-play formulas
instead of properly understanding what's going on. This approach fails
absolutely with programming. There are no shortcuts.

~~~
kiba
I don't fully understand what's going on. However, as long as someone design
the black box carefully, I can figure out what it can't and can do.

~~~
hnal943
Thanks to the law of leaky abstractions, that will always bite you in the end
(provided your are doing something complicated enough).

[http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...](http://www.joelonsoftware.com/articles/LeakyAbstractions.html)

------
jleyank
I found programming WAY easier than learning the guitar. 'Course I was 13 at
the time, and the latter involved "practice". Practice was boring, yet
learning things like ASCII, how to toggle a PDP-8, Hammurabi, ... Those
weren't "practice".

As everybody knows, doing what you like to do is easy. Doing other stuff is
not.

~~~
jedsmith
> Practice was boring, yet learning things like ASCII, how to toggle a PDP-8,
> Hammurabi, ... Those weren't "practice".

I get better at programming as I do it more. I think you're correct that
individual knowledge points aren't "practice" per se, but practice definitely
factors into skill over time. Just like I imagine it does with the guitar.

~~~
jdminhbg
I think the essential difference is that practicing the guitar involves doing
the same thing over and over until you get it right/fast, whereas practicing
programming involves doing different things.

~~~
jleyank
I would think to a guitarist, what we do when programming is "all the same".
Just like we think guitar practice is all the same. No, the guitarist would
say, there's real differences between flamenco, jazz, prog rock, ...

If you support the 10K hours argument, some things are willingly done and
others less so. I make coin with programming, yet people pay to see
guitarists.

~~~
Tycho
Guitarists definitely do engage in some 'mindless' practice where they're
essentially just building dexterity/muscle-memory by playing the same thing
over and over. I don't think there's anything like that in programming...
unless you count trying to get used to emacs key bindings.

But obviously some guitar practice is more involved. It's something I think
about a lot actually, as when I need a break from programming first thing I do
is pick up my guitar. My musical goal is to be able to improvise on the guitar
using jazz theory. To do that you need to internalize abstractions like
scales/modes and chord progressions. You need to be able to transpose the same
abstraction/pattern to different notes (on the most basic level this would
just mean sliding further up the neck and using the same shape for fingering),
and you need to be able to 'search' your options (some chords can substitute
for other chords, which might then allow a whole new path of music) on the
fly.

In programming you don't need to wrangle all these abstractions in a strictly
timed performance, and there's no physical component to the challenge. But
still, I often think about the similarities. I guess playing jazz guitar,
while complex, can still be kept within a manageable scope of permutations and
ultimately 'mastered'. But with programming you can't tame the complexity, you
just get good at dodging it.

------
Eliezer
Learned to program when I was around five or six years old, by picking up a
book of prewritten programs in BASIC for a Sinclair ZX80 (or ZX81? not sure),
figuring out how they worked and writing my own.

I am not sure what the term "inherently hard" is supposed to mean in this
context.

~~~
devilant
Come on. I think the context is pretty clear. If a group of novelists are
discussing how writing is inherently hard, would you let them know you don't
understand how they can say writing is hard? After all, you learned how to
write when you were five or six by picking up "See Spot Run" and then
stringing together some nouns and verbs of your own...

~~~
Jach
If something is "inherently hard", not just "hard", it seems that it should be
hard for _everyone_ , which is clearly not the case with programming for some
geniuses out there. There are people who don't blink an eye at mastering any
data structure or algorithm, don't sweat when it comes to actually coding, and
they're human just like you. Plus what if programming became really simple for
some AI to do? You ask it "Make me a triple-A style video game I might enjoy"
and it does so after a short while. I believe Eliezer is pointing out that
programming being inherently hard is a mind-projection fallacy.

------
cletus
Programming is like most things in life: hard if you have no affinity for it,
much easier (but not necessarily easy) if you do.

I see programming to have a lot of parallels with being a combination mechanic
and automotive engineer.

A mechanic fixes cars, diagnoses problems, tunes a car and so on. It's really
a lot like (code) reading, testing, debugging and maintenance--all key
programming skills.

An automotive engineer will actually a design a car, design and various
components, model how it should work and so on. This is really program design
and _programming_ specifically.

The thing about programming is that involve perhaps the most tractable medium
humans have ever used. It takes a long time to design and build a car. It
still takes a long time to make significant changes to that car. Now compare
that to software, which is easily changeable with a feedback loop that can be
measured in as little as a few seconds (edit code, save, reload page in
browser).

Of course some software has a longer feedback loop but at worst it tends to be
in hours, possibly days. It's a different order of magnitude.

Cars can be adjusted within fairly tight limits (meaning you can make the
engine more efficient or make the brakes work better or not at all but you
can't easily make that car float or fly).

Is programming harder than being a mechanic and/or automotive engineer?
Empirically I can't answer that question. I would be useless as a mechanic.
Could I learn? Possibly. Would I be as good as those with a natural affinity?
Absolutely not.

One thing I'll add is that the barrier to entry for programming is probably
higher but this might simply be an issue of complexity.

Consider a car from 40-50 years ago. It wasn't that complicated. Now? Cars
have _dozens_ of computing units in them and qualified mechanics have to use
computer systems to interface with them. So perhaps modern software is more
like a modern car than a car from the 70s.

Now consider another discipline like medicine. Is medicine hard? It certainly
requires a lot of knowledge. Part of many medical disciplines it appears
involve a significant amount of rote learning. Bone names, nerves, diseases
and so on.

Some have an affinity for rote learning and some don't. I know I don't.

The other part of medicine is the mental attitude required. Not everyone is
psychologically capable of dealing with a patient who is dying or has the
mental endurance to perform a 12 hour heart transplant. It's very _exact_.

But is it harder?

My own theory is that some people can become programmers and others can't.
Some of the ones who can't sadly are employed as programmers.

Programming requires an extremely high level of abstract thought. I remember
demonstrating to my sister how I used Splashtop on my iPad to connect to my PC
at home to start it doing something. To her, it was for all intents and
purposes magic (to paraphrase one of Arthur C. Clarke's laws).

To me--and anyone reading this--there's nothing magical about it. It's simply
a system of concepts built on top of other concepts.

This also changes my thinking. I see (human) language much like a network
protocol. Letters are merely agreed-upon symbols that, when combined, form
sounds (most) humans are capable of making. Combine those sounds (or groups of
letters) into words and you have a another layer of agreed-upon concepts (or
definitions).

Network protocols work much the same way. Ultimately there is a physical layer
where certain voltage differences equate to 1s and 0s. Once you have the
concepts of transmitting bits, you arrange them into bytes. Certain bytes or
byte sequences resolve to characters. Combine those characters and you have a
message.

It's systems built on systems. Do non-programmers see language that way?
Unless they're linguists, probably not.

So I guess my point is that programming (or anything for that matter) may
simply look hard because the foundation in concepts simply isn't there.
Whether or not someone can learn those concepts and whether or not that makes
programming qualitatively hard is another matter.

~~~
Vivtek
_I would be useless as a mechanic._

90% of being a good mechanic, just as 90% of being a good programmer or a good
doctor, is debugging. If you're a good debugger, you can damn well do
_anything_.

~~~
chopsueyar
As a mechanic, you also need good grip strength and not be afraid to bloody
your knuckles.

~~~
Vivtek
That's the 10%.

------
stevenbedrick
I've said it before, and I'll say it again. In my experience, the problems
that students have ultimately fall into one of two categories:

1\. Learning to think algorithmically; 2\. Abstraction.

What do I mean by these? By "thinking algorithmically," I really mean "taking
a large problem and breaking it up into an ordered series of steps or sub-
problems." This is surprisingly hard for a lot of people, in part because the
correct "size" of steps or sub-problem can change from problem to problem and
from language to language. This can absolutely be taught, though. Some
students have an easier time of this than others, but eventually (in my
experience) they all get there in the end, and develop an intuitive sense of
how to do it... at which point 99% of people immediately "forget" what it was
like to _not_ be able to do it, and become incapable of recognizing and
dealing with students who haven't gotten there yet. :-) Most programmers
(myself included, at least until my dozenth or so student, at which point I
figured out what was going on) fall into this category: thinking in this
manner is so deeply imprinted into our cognitive processes that we typically
have a very difficult time visualizing what it's like to not be there. We're
sort of like fish and water, if you know what I mean.

The second problem is much more difficult to address. Abstraction is one of
those things that, I'm convinced, some (most) people can "get" and others
simply can't. For example, I've had students who seemed to understand arrays
perfectly, including the idea of using an integer subscript to refer to the
value at an array index such that if you showed them the following code:

<pre>

myList = ['monkeys', 'elephants', 'giraffes'] print myList[1]

</pre>

they'd easily tell you that it would print 'elephants' (yes, they can usually
get their heads around zero-indexing without issues). If, however, you showed
them this code:

<pre>

myList = ['monkeys', 'elephants', 'giraffes'] idx = 1 print myList[idx]

</pre>

a lot of them would be more than a little bit lost. Even worse would be if you
showed them this code:

<pre>

for i in [0, 1, 2] print myList[i]

</pre>

They'd be _really_ lost, then. Even if you walk through it line by line, with
lots of extraneous print statements, there is a certain sub-type of (otherwise
perfectly capable) student that just isn't gonna get it. I'm convinced that
this problem--- lack of abstraction ability--- is also why so many students
have problems with loops. Dealing with loop counter variables (and the things
that you usually want to do with them--- array indexing, printing, doing math,
etc.) is very hard if your brain isn't able to think in this abstract manner.

It's worse in Java than it is in Python, just 'cause there's so much more code
involved (meaning that it's harder to pinpoint exactly where the confusion is
coming from), but the problem totally persists even in sane teaching
languages. I've talked to a lot of other CS educators who've noticed the same
thing- no matter how you approach it, this level of abstraction is just beyond
some students' reach. It gets worse once you try and teach them about
object/class distinctions, and so on. It's not that they're stupid- my
students are usually MDs working on their masters' degrees. It's just that
some people's brains don't work that way. And it's not that they can't do
other computer stuff- some of these students have gone on to become pretty
good at SQL and even relational data modeling, which you'd think would use
some of the same cognitive patterns, but apparently is different enough that
it's doable.

I don't know if the problem would be better or worse teaching with a purely
functional language; my gut says "worse," but I haven't tried it so I don't
know, and the fact that many students with this problem go on to handle
declarative languages pretty well gives me pause.

~~~
tkahn6
You can simulate <pre>

    
    
       by
         indenting
           four spaces in

~~~
Tycho

        always
            wondered
                how that worked

~~~
LiveTheDream
<http://news.ycombinator.com/formatdoc>

------
steve918
It’s a lot like Chess or Poker, you can teach anyone the basic rules in a few
minutes and they will be able to have some level of success, but it can take
you a lifetime to master

------
jimmyjazz14
Learning the language of programming is easy (like learning the chords on a
guitar) but combining the elements of programming into a working solution to a
problem is an entirely different thing. Like any other skill the amount of
labor required to go from novice to master grow exponentially over the course
of learning.

------
LiveTheDream
"The contraints imposed in building large software systems are the limitations
of our own minds. In that sense computer science is like an abtract form of
engineering; it's the kind of engineering where you ignore the constraints
that are imposed by reality." - Harold Abelson in SICP lectures

------
tsotha
I've always thought it was pretty easy. But you can't judge that kind of stuff
in a vacuum - maybe if the people around me were demonstrably better
programmers I would have a hard time trying to close the gap.

------
Dn_Ab
I think programming is a vague term. If programming just means rigorously
encoding an imprecise set of instructions then while not easy I cannot say it
is especially difficult.

But if your programming involves complex mathematics,physics, linguistics,
biological, intricate interactions with the world, heck even philosophical
concepts then programming is in the cartesian product of the domain and field
and is as hard as the toughest problem you are attacking, judged with respect,
also to the source field. The true difficulty is in balancing multiple species
of abstraction, domain knowledge, device knowledge and encoding instruction in
a way that satisfies all of these.

So there is the base difficulty of abstracting and then converting mental
concepts to a set of computations compounded with the difficulty of getting
the abstractions of your domain knowledge to transfer to a set of mental
concepts that are transferable to a set of computations. heh. If the field you
are dealing with is easy And Or you are continually dealing with the same
problem more or less (just different facets) such that you had internalized
most of the process to automated subthought (mastery) then yes it will appear
easy.

Programming then, would only be bounded by its own internal difficulty, which
gets easier the more you explore it and learn widely applicable abstractions.
Once you mix in the difficulty of the field the same applies till you have
reduced the interactions of field+programming to mastered concepts. If the
field has a high minimum then this reduction may still always remain extremely
difficult. So if one finds programming easy it could also be a sign that you
are not challenging yourself enough, not pushing your boundaries sufficiently.

My theory is that those of the greatest skill have burning curiosity and will
to improve, respond positively to challenge, and have great ability to focus -
together this allows them to hold on to and continually attack a problem to a
greater depth than most. You need only pick 3, maybe only 2. If there is any
inherent genetic advantage held by some - greater ability to focus, efficient
use of nutrients, quicker and more enduring synaptic connections, whatever -
for the rest of us, I feel the brain is marvellously malleable and can be
tuned down another set of dimensions. The space of intelligence is gigantic
and non euclidean and likely with no concept of a global maximum. If the
person is so determined they will work around their deficiencies and or train
their mental processes stronger so that any "lack" of inherent skill does not
get in the way of what they wish to do. This is what I believe I do and did. I
do be slow as molasses.

~~~
Dn_Ab
I am new here and so do not understand the intricacies of this community. Is
there anything particularly offensive or especially stupid about my comment? I
tried to be careful but perhaps I failed and so would appreciate any insight
for further edification.

~~~
gruseom
Don't worry about it. Your comment was fine. People sometimes downvote for
idiosyncratic reasons but someone else usually comes along and neutralizes
that (as I just did). The main thing is to keep the discussion on-topic and
not go meta.

You make an excellent point: the difficulty of programming is not only that of
instructing the computer but also that of the problem the program is to solve.
I agree.

(As an aside, the main problem with your comment is that it was rambling. This
obscures your otherwise valuable insights. I recommend a course of obsessive-
compulsive editing :))

~~~
Dn_Ab
Thanks, that was helpful. I'll have to take on that course as I do need to
work on communicating clearly. The unedited stream of thought thing does a
good job of hiding what I am trying to say. counter-productive.

