
Why Learning to Code Is So Damn Hard - vike27
http://www.vikingcodeschool.com/posts/why-learning-to-code-is-so-damn-hard
======
bad_user
Here's where I disagree with other people - software development is special in
that it requires focus, relentlessness, intelligence, creativity and I also
find it interesting that many software developers tend to suffer conditions
from the autistic spectrum. To me that's a clear sign that software
development requires the mind to be hardwired in a certain way.

And the thing is - I never needed handholding, which is why I have mixed
feelings about such educational efforts. For me that desert of despair was fun
and nothing could have stopped me. For me entering a couple of lines of code
that made the computer do something was like a game and felt like magic, with
each piece of knowledge learned increasing my skill, in a sort of real-life
RPG game. This started before high-school, I remember begging my parents for a
PC and I started reading books on hardware and one on BASIC before having that
PC, so that's how desperate I was.

And my story is very similar to others. It's undeniable that some people have
an inclination towards software development, like a deep internal urge that
must be satisfied, much like a drug addiction. This is why you'll find many
developers saying that even if they wouldn't need to work, they'd do it for
free.

To me educational efforts for adults are misplaced. If you want more people to
become software developers, you need to show them the magic while they are
young. As for most adults, I believe that the ship has sailed already.

~~~
pm90
I don't really agree with the notion that software development is something
that others cannot learn if they try to do it; that seems like a very harsh
perspective which, from my anecdotal experience, is far from the truth. Any
skill can be learned if you have the discipline to put in regular effort:
that's just the way the human mind works. I do agree that for a lot of people,
Software Engineering is _easier_ because they have a certain kind of brain,
just like Mathematics or Physics or Music is easier or "makes sense" for some
people more than others.

If anything, we need to promote education among adults, give them the choice
to possibly check out any vocation that they would want to try. Liberate them
from the notion that they are "stuck" doing what they chose to do earlier in
their life. I'm not saying that its easy; you have to start small and take
baby steps. And its not something that can be done in a day or a week or a
month. But if modern society has provided us one great benefit, it is of
making knowledge accessible very inexpensively.

~~~
bad_user
What you're saying is true and I used to be optimistic about it like you,
however I stopped believing that it is feasible for most adults after failing
to teach family members the basics or junior colleagues to become better.

Maybe I've been a bad teacher, however the thing I noticed is this - yes, if
you put enough effort, Ok, we can probably do anything, like learning to play
the violin or do programming, except that's easier said than done. The effort
required is actually enormous. Put in that equation real-world concerns, like
a social life, a day job, raising children and so on and it becomes next to
impossible.

For a child it is easier - he has the time available and that desert of
despair mentioned can be actually fun. Because to a child, making the computer
do stuff can feel like magic, whereas to an adult it feels like a chore to get
somewhere, a chore that eats all of the available time.

Knowledge is accessible and that's great. The noise is also great though and
one still has to filter, analyze, learn and work. The Internet is indeed
disruptive, like you get access to books or to online courses from reputable
universities without being there and without paying a single dime. But I still
see this as helping children in impoverished nations, rather than adults in
first world countries.

Note that I'm not discarding the possibility of adults actually making it over
the learning curve. I'm sure there are people out there that have succeeded.
But those are super-humans and I think they represent the exception.

There's also another thing that's starting to piss me off. Some of the
problems we end up working on are extremely difficult, yet because we are
idealists, we go around telling everybody that everybody can do it, probably
out of sheer enthusiasm for the things we do, because we believe the world
would be better and maybe because we want to share with others our passion.
But you know what, some of the stuff we do can be really challenging,
objectively speaking not everybody can do it and going around and saying that
opens us up for abuse. And then we start complaining about agism or about
companies fixing salaries and entering no poaching agreements. How stupid can
we get? Oh, so you want more or better software developers? Capitalism works
both ways, demand and supply is a bitch, so fucking pay up.

~~~
ivanhoe
Actually you can't ever learn to play a violin properly unless you have an ear
for music. There is a threshold of minimal talent that you can't jump over
just by practicing, you either can hear it or not. While there is no such
obvious threshold for e.g. math or programming (for a person with an average
IQ), I think we could talk about a kind of a threshold defined by the
concentration and willingness to invest time and effort into the learning
process. Theoretically anyone should be able to do it, but in reality not
everyone is mentally capable of that, simple as that. Just like running a
marathon or something, most of us will never be able to do it, although in
theory it's simple: you just need to follow the proper training for long
enough. Losing weight is also dead simple, just as quitting smoking or getting
off drugs, but many can't do it. Learning is no different, it takes certain
minimal level of power of will to be able to make it.

~~~
DanBC
> Losing weight is also dead simple, just as quitting smoking or getting off
> drugs, but many can't do it. Learning is no different, it takes certain
> minimal level of power of will to be able to make it.

You say that losing weight is dead simple, and that you need minimal level of
will power to achieve it, but then you say that many people can't achieve it.

Can you see there's some disonance there?

~~~
beobab
But "simple" doesn't necessarily mean "easy". The simplest way to get a
boulder up a hill is to push it with enough force.

------
rcthompson
When I was in college, one CS professor explained the difficulty of coding to
me in terms of discreteness vs continuity. In the real world, things are
continuous. If you accidentally build your structure with 9 supports instead
of 10, then you only lose 10% of the strength of the structure, more or less.
The strength varies continuously with the amount of support. But if you're
writing a 10-line program and you forget one of the lines (or even one
character), the program isn't 10% wrong, it's 100% wrong. (For example,
instead of compiling and running correctly, it doesn't compile at all.
Completely different results.)

Of course this logic doesn't hold up all the time. Sometimes you can remove a
critical support and collapse a structure, and sometimes removing a line of
code has little to no effect, but the point is that in programming, a small
change can have an unboundedly large effect, which is the definition of
discontinuity.

(I believe it was this professor, who was my teacher for discrete math:
[http://www.cs.virginia.edu/~jck/](http://www.cs.virginia.edu/~jck/) )

~~~
superobserver
> But if you're writing a 10-line program and you forget one of the lines (or
> even one character), the program isn't 10% wrong, it's 100% wrong. (For
> example, instead of compiling and running correctly, it doesn't compile at
> all. Completely different results.)

This is where the beauty/simplicity of some programming languages, namely,
intepreted languages (e.g., Python), comes in: if a bad line of code never
gets executed, then the program itself will run fine. In other words, if the
line is never called in the program, then you'll not know that the
functionality that that line presented was bad. In this case, the analogy
breaks down a bit - and also shows why certain languages are easier to learn
than others (e.g., Python vs. C++).

~~~
nsomaru
I'd rather know when something is incorrect, rather than pushing to production
and finding out later because someone else took that code path.

~~~
DougWebb
If you rely on your compiler to tell you that your code is correct, there are
whole classes of bugs that are waiting to surprise you in production.

I think that many years of developing large applications in Perl were really
good for me. Perl is compiled when you run it, so you get the basic-syntax
check that you get with other languages. But it's also very lenient, so you
learn through experience to get your logic right, test return values, and do
all of the things that help make sure that a program which executes is
executing _correctly_.

~~~
brianwawok
There is a difference from RELY on compile to catch 100% of bugs, vs having an
awesome type system that can take whole CLASSES of bugs and make them
impossible to get past a compile.

Is a statically typed language more likely than a dynamic language to work
correctly in production, if both have 0 tests? Yes.

Is either ideal? No.

Can both be improved by adding a few tests? Yes.

~~~
pdonis
_> Is a statically typed language more likely than a dynamic language to work
correctly in production, if both have 0 tests? Yes._

I'm not sure I agree. "Work correctly" does not just mean "compile correctly".
I would want to see a lot of evidence to back up any assertion that programs
written in statically typed languages are less likely to contain logic errors
that compile and run just fine but don't do what the programmer (or his
client) actually wanted.

I agree that neither is ideal and that adding testing can improve any code.

~~~
dragonwriter
> I would want to see a lot of evidence to back up any assertion that programs
> written in statically typed languages are less likely to contain logic
> errors that compile and run just fine but don't do what the programmer (or
> his client) actually wanted.

As certain assertions related to logic can be encoded into static types
(especially in a language with a type system more like Haskell's than, say,
Go's), while static typing can't eliminate _all_ logic errors, it can reduce
the probability of logic errors escaping detection in the absence of testing,
since compiling a statically typed program is, in effect, a form of testing
(limited to those assertions about behavior which can be encoded into the type
system.)

~~~
pdonis
_> compiling a statically typed program is, in effect, a form of testing
(limited to those assertions about behavior which can be encoded into the type
system.)_

Fair point. (Especially if, as you say, you are using a language with a type
system like Haskell's, which to me is more like a program analysis engine than
just a type system.)

------
codingdave
Many of the coders I know (which is mostly folk in their 40s) never learned
from scratch. More often, we started in support roles, and slowly worked into
the code. First, learning to read it to help troubleshoot issue, then making
basic changes, and slowly picking up more and more of a specific codebase.
Once the basics were understood, we'd start making basic apps on our own,
often while still supporting more complex apps. After a year or two, we'd be
competent enough to do things from scratch, and then we'd move into a full-
time coding role.

I know that few people learn like this these days. I've heard extreme negative
criticism when I tell people that a few years of 2nd/3rd tier support on a
large codebase is actually a good start to a coding career.

But I also never experienced the troubles described in this article. There
were hard times, which would have been eased with today's online content. But
it wasn't hard because of a downturn in confidence, and resulting "despair"
that is described - it was a slow, but steady increase in confidence and
abilities.

So are people better off today? Maybe. They certainly are coding at younger
ages... but I have no complaints about my path. I still was fully competent in
my early 20s, did a startup at 26, etc.

So there are many paths to developing your career. I'd recommend people keep
an open mind to all options, and do what works for them personally.

~~~
Stratoscope
My first job was Night Operator at Transdata, a dial-up timesharing company in
Phoenix, for the summer of 1969, earning $2/hour.

The fun part was that they turned off the timesharing service at night - but
they didn't want to power down the Sigma 5 for fear that it might not start
back up in the morning. There were occasional overnight batch jobs to run, but
mostly I didn't have much to do.

I already knew BASIC, having punched programs on paper tape in high school to
run on Transdata's service (which was how we got acquainted). I found a copy
of the Algol-60 report at the office and thought it looked interesting, so I
read it, tried out a bunch of programs, and learned Algol.

Then I found an assembly language and opcode reference for the Sigma 5, which
was fascinating. There were plenty of blank cards to punch, so I learned
machine language too.

I could have just sat back and done the night operator job and not much else,
but man, there were such _interesting_ things to fill in the rest of that
time. And it's stayed interesting ever since.

Of course that was an unusual situation, and I suppose not one you could
repeat now. After all, how often do you get a chance to have a whole computer
all to yourself?

~~~
ingler
I was 8 years old in 1970. My dad was working for NCR in Waltham, Mass. He'd
bring home a honkin' huge teletype and an acoustic coupler on the weekends. I
taught myself BASIC and got hooked on Hamurabi [0], my first computer game
vice.

How much paper did all of us go through back then?

[0]
[http://en.wikipedia.org/wiki/Hamurabi](http://en.wikipedia.org/wiki/Hamurabi)

~~~
Stratoscope
A _lot_ of paper!

Do you remember the first time you saw one of those newfangled "glass
teletypes"? A terminal that printed out your typing and the mainframe's reply
on a CRT instead of paper?

Was your first thought anything like mine: "How do I look back at what I was
working on a few minutes ago? There's no roll of paper piled up behind the
machine! How do I see my printouts?"

~~~
todd8
Yes, I used a video display terminal for the first time in a computer lab full
of strange gear at MIT 40 years ago. The computer had to have its initial boot
loader loaded from a strip of perforated paper tape. The terminal had
characters "drawn" by the crt tube's electron beam. If there were a lot of
characters on the screen the first few lines would start to fade before the
e-beam was able to back to the top of the screen. By keeping the overhead room
lights off, we could see almost a full 24 lines of 40 character. It seemed so
advanced compared to the punch cards that I'd used for years before. Those
were the days!

------
ibebrett
This may be thinking back on things with rose tinted glasses, but I learned to
code in qbasic when I was 12 or so at a Boys and Girls club after school and
fell in love. It was entirely effortless and fun to me. I think the difference
is at that point I wasn't trying to program to enter some lucrative career and
be a startup guy (where are these "coders" going to be once the market dies
down and a new industry is hot? probably trying to do that). For me it was
something I loved immediately, and while obviously there are really hard
problems, the coding part was effortless

~~~
parenthetically
I first learned on a variant of BASIC myself when I was in elementary school,
and it was effortless then -- but that's a profoundly different thing from
learning the professional tools/design patterns/development styles to get
hired in a specific domain. As somebody who picked it up again after a long
break, the whole point was not 'getting hired in some hot new lucrative
industry,' but 'god, please let somebody hire me to do this thing that is so
much more mentally satisfying than the last few things I've done for a
living.'

From that perspective, I absolutely understand the urgency here, and
appreciate how this article talks about how the moment when the tutorials
break off is when the real learning begins.

~~~
svachalek
At the time "design patterns" were somewhere in the distant future,
development style was something you had rather than something you learned, and
the list of professional tools was really short. I'm sure this is part of what
made it incredibly fun.

I think today's students would also have a lot more fun if they ignored all
the opinionated garbage about which flavor-of-the-month checkboxes they need
on their resume. Figure out what you like and get really good at it. Many top
employers are looking for passion, pragmatism, and adaptability rather than
specific tools and libraries.

------
greggman
I was never told learning to code was hard. I never found it hard. I found it
fun. I was introduced in 8th grade by a friend who brought a listing to school
of a small program he wrote in BASIC and it took off from there. I didn't have
all the resources of the internet to help (this was 1980)

Like the article mentions there's just a ton to learn. 6 months of Code
Academy will help you learn basic stuff, variables, loops, conditionals, maybe
even objects and classes but only experience will help you with databases,
files, sorting, patterns, threads, memory issues, debugging, big O thinking,
cache coherence, performance, etc, etc and all the other stuff.

That comes from doing and doing over years and years.

Maybe it's something about certain people? I watched a guy with almost zero
programming experience go through some tutorials online and then apply for a
software engineering position at google. From everything he said he seemed
confident he was going to get the job and was going to be very depressed if he
didn't. All I could think was "REALLY? You really think 3 months of study
makes you a programmer ready for Google?". I didn't say anything. Who am I to
step on his dreams. Maybe he'd some how fake his way in.

He didn't

But it made me wonder why did he believe that that was all he needed in the
first place? I think that's actually the more interesting discussion. There's
a ton to learn in programming. You can learn some basic stuff quickly and
maybe make some lights light up on your arduino art project but why would
anyone think 2 to 6 months of study would make them ready for a programming
job? Is that a new thing? Where did it come from?

~~~
hibikir
That's because you, like all of us that learned in the 80s, were very, very
lucky. We started in a world where writing good, production code and learning
the very simple basics of programming were the same thing. I started with a ZX
Spectrum. You could use simple machine code, or simple basic. Libraries? What
are those? The one barrier to get good was when you ran out of memory, and had
to switch to machine code and learn memory saving techniques, but by then, you
were as ready as anyone.

I compare it to wha we do today: My code uses libraries, that use libraries,
that use libraries. Languages are huge in comparison. Sure, it's easier to do
what we used to do 20 years ago, but nobody expects from us what we did then:
Even someone that is just learning wants to do more. This is what builds the
despair phase of the article.

It's a well known issue that both affects how we train new people and how we
even manage large pieces of software today, so it's well talked about. For
instance, the first talk of JSRemoteConf last night was all about this issue.
Hopefully they make the recordings openly available soon.

~~~
jussij
I think a lot of that _despair_ is industry self-inflicted.

I've been in the software industry for a long time and I can't remember a time
when the industry created as many new buzz words as quickly as it does today.

Take something as simple as ASP.Net for example.

In just a few years it has gone through these iterations:

* Classic * WebForms * MVC * MVVM * Razor

Each name change represent nothing much more than a new software design
patterns, yet because they have a _buzz word_ attached they become new skill
set.

Look at something as simple as IOC, which again is just a new software design
pattern.

Now ever IOC containers has become a _buzz word_ and shows up as a skill
requirement on the job description.

So here are just a few new IOC container _buzz words_ that you might need to
get on your resume:

* Autofac * CastleWindsor * EntityFramework * LinFu * Ninject * PicoContainer.NET * Puzzle.NFactory * S2Container.NET * Spring.NET * StructureMap * Unity

With so many _buzz words_ things appear complex and overwhelming, but the
reality is if you've seen one IOC container you've seen them all and if you
haven't seen any, chances are if you are good with software design patterns it
won't matter.

~~~
chipsy
I definitely get the sense that industry has only accelerated its churn rate
over time. Just looking at what's happening to Javascript in the past year or
two gives me butterflies in my stomach: There is attractive stuff and
necessary stuff, and it's only getting harder to tell the two apart.

While I wouldn't say that everything about old-school coding is great, it
encouraged a first-principles engineering process - checklists, printouts,
technical docs, etc. - that is eschewed today in favor of looking up some
framework and fumbling your way through to half-understand what's going on and
leaning on the toolchain(which you also don't understand) to give you some
reassurance that it isn't completely broken. This is discouraging for
_everyone_, not just learners.

------
jeremysmyth
Having taught many non-programmers to start their programming journey, this
article rings very true.

The "cliff of confusion" he describes is a function of the Dunning-Kruger
effect
([http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)),
which indicates that you don't know how bad you are at something until you get
better at it. As an educator, the challenge is to make that cliff as unscary
as possible and chart a path through the "desert of despair" so that you're
not pushing too much at one time.

On the other hand, as a self-learner it's really really hard to get past the
point where you've learned enough to know how much you have yet to learn, or
in terms of the article, when you look over the cliff and see how HUGE your
journey is becoming.

To a large extent, the article is an advertisement (in more ways than one) for
guided learning, expressed in a pretty clear way.

~~~
bnb
The Dunning-Kruger effect pretty much sums up myself. I feel like I have a
firm grasp on the structure and syntax of JS, but now I'm questioning whether
I really do. I always feel awful, as I can't really implement anything, and am
always frustrated when I can't get off the ground starting a project.

I just don't know how to actually _do things_ with code. So, in essence, I
think I know the language, and in a sense I do insofar as I know how to write
an if else statement, a while statement, declare a variable, etc., but I
_don't_ actually know the language, because I can't do anything with what
little I do know.

Do you have any advice?

~~~
steveax
Here's a few...

Build something, anything. Then set it aside for a while, come back to it and
improve it. Reading code you wrote a couple of months ago will highlight very
quickly the parts that are clear and concise and those that are not.

Pick an open source project that is interesting to you and improve the
documentation. Writing clear documentation requires a depth of knowledge that
surpasses just employing it.

Give a presentation on and/or tutor someone on a topic. Like writing docs,
this requires being able to think clearly about the topic.

------
_greim_
This seems like a symptom of learning to code for the sake of _being able to
code_ , versus learning to code because you _enjoy coding_. It's just as much
work in an absolute sense, but the process in the latter case seems more
effortless and fun.

There's a similar thing in the music world. Some people want to be good at
guitar, others like playing guitar. The former get bogged down in despair, the
latter fiddle around on their instruments every night without even thinking.
Guess which ones end up getting good?

[edit] cholmon makes a good point; the enjoyment is more in creating things
than in simply writing code.

~~~
lojack
Shortly after I began driving my uncle taught me drive stick. We went out a
few times, I'd practice in the parking lot, and I was eventually able to get
it in gear and drive on the streets. I was horrible at driving stick, stalling
at intersections, but I was good enough at it to get by. It wasn't until I
actually bought a car that had a manual transmission that I got good at
driving stick. I was terrible because I was trying to learn to use the tool
(stick shift) for the sake of learning.

I learned to program in a completely utilitarian way. I had a problem that I
needed to solve, I knew others had used programming to solve similar problems,
so I learned only what I needed to know to solve the problem at hand. After
using it this one time I began to notice all sorts of other problems around me
that could be solved using programming. I developed my passion for coding
because I understood it was a tool that could make my life easier.

~~~
beachstartup
this is exactly why most programming tutorials are terrible. they show you how
to do calculator exercises and spend hours and hours on data types and syntax.
it's like driving around in circles in the parking lot over and over again.

after struggling for years to 'get it' in my friends cars, i learned how to
drive a stick in a single afternoon after saying 'fuck it' and buying a car
with a manual transmission.

------
spain
I feel like I'm in the "Desert of Despair" and I'm not quite sure where to go.
So far I'm self-taught in C, C++, Python, Lisp (a few of them) and some shell
stuff. I have the basic syntax nailed in all of those. I don't know any of
them well enough to be able to write simple programs without constantly
looking up StackOverflow articles or reading references. I haven't even
touched GUI programming.

It doesn't help that I always try and obsessively look for the "best" or
"proper" way to do something. I know this is a good virtue to have but I also
feel like it also gets in the way of getting things done.

It's such a weird place. On one hand I feel like I know a lot more than before
but if any of my friends ever mention how "good" I am at coding I am quick to
correct them by saying I'm really not. I could really do with some sense of
direction, but I suppose that's on my shoulders since nobody else can decide
for me what sort of developer I ought to be. I'm not sure what to focus on.

I initially got interested in coding just because of how interesting and fun
it was in itself. I want to continue to pursue it because I feel like it's the
first thing I'm _really_ good at. I always got mediocre grades in school, I
didn't learn any instruments or have any hobbies, then I started learning how
to code and it just clicked with me and for the first time in my life I had an
idea of what I might do for a living.

Sorry if that strayed a little too far from discussing the article, I wanted
to try and write my thoughts down.

~~~
gambiter
Personally, I think this is the phase where what you need most is practice.
There are practical things you need to learn that you just can't learn without
running into them during a project.

Just keep practicing. Varied things. Challenging things.

You'll get there!

------
kcole16
For me, by far the hardest part was finding the time. Learning to code on
nights and weekends, when you've spent your most productive and focused hours
at your job, is a nightmare. It wasn't until I was actually hired as a dev
that I started to hit a steep learning curve, and I attribute much of that to
spending 50 of my best hours/week coding, rather than maybe 20 of my worst.

~~~
puranjay
I have the same issue. I've set aside 10pm-2am every weekday to learn how to
code, plus entire Saturdays and Sunday mornings. I can, at most, manage 20-25
hours, usually when I'm already bogged down.

I've been toying with the idea of quitting everything and going all-in for 3-6
months.

Would that be 100% retarded or just about 70% retarded?

I can live with 70%.

~~~
sleazebreeze
I had the option to quit to work on learning to code for 3-6 months and I
chose to bite the bullet and stay employed. I woke up at 4am to get in a few
hours of coding before work and kept my working hours to a minimum so I could
have a few hours after work to code. Weekends were 12+ hours of coding both
days. It doesn't leave a lot of room for social life or other activities, but
the job search was a lot less stressful knowing I still had a paycheck coming
in instead of burning through my savings. YMMV!

------
shittyanalogy
Motivation.

If you don't have the motivation you'll never be able to do it. If you can't
sit in front of a computer for 8 hours a day reading documentation and hunting
for syntax errors you're not going to be able to do it. If re-writing
algorithms doesn't give you an intrinsic satisfaction, you're not going to be
able to do it. No amount of everybody can code tutorials is going to help.
They should all be, "how to find the motivation to keep coding" tutorials.

Unrelated, but related to the article, the word sociopath get's misused a lot
and this article is no exception.
[http://www.thefreedictionary.com/sociopath](http://www.thefreedictionary.com/sociopath)

~~~
inDigiNeous
Motivation can work for a while, but ultimately how I see it comes down to
discipline.

Motivation will fail you when you are left with those last 10% of a project
that feel like the first 90%, but now with uninteresting tasks like tweaking
the hell out of a UI, fixing all those bugs resulting from code optimization
in obscure cases, implementing database integrations to assure backwards
compatibility with earlier versions or some such shit that is impossibly
uninteresting but required to finish the project.

Then in play comes discipline, and that is something you have to learn
systematically, and when you don't feel motivated at all to continue through
and just wish to quit it all.

But you are correct, you have to get satisfaction from the process. Maybe the
motivation is to see the end result. But still, there is that phase where all
hope seems to be lost, inspiration and motivation are nowhere to seen and all
that remains is just grind and decide to follow through.

------
threatofrain
I have a feeling a lot of why people fail with these online resources is
motivation, and I think it's why Khan Academy, while it is a forward-looking
treasure of education, has failed to achieve revolution despite dramatically
improving the access of education.

A lot of people need external mechanisms to keep themselves motivated, such as
parental pressure, peer pressure, shame, and so on. As soon as people leave
college, most people never learn a tall order of knowledge ever again, and
most people let their existing knowledge rapidly decay. And then they're going
to tell you a story about how everything they learned in college is useless,
and how jobs want something entirely different.

Whatever human nature is going on inside of them that explains the outwardly
visible behavior is part of the cliff people are walking toward.

------
adregan
As a self taught developer, I'm so thankful I first thought I wanted to be a
designer. HTML and CSS made sense to me (the backend, even frontend js, forget
it. I'd try to hack around it) and I sought deeper knowledge on the subject.
Build systems and preprocessors were a gateway to command line tools and good
organization skills.

Once I was thrown into full stack development, I at least had something to
lean on while the backend programming caught up with the frontend. Then I
started applying the things I learned programming backend applications to
frontend applications (where do I keep all this state?). I think I spent a lot
of time in the desert of despair wrt. certain types of programming but was
never entirely there.

I think it's important to have something to feel confident in while you
struggle.

~~~
emhart
I am part way through your trajectory. I was a designer first, fell in love
with html/css, eventually gave in and learned js, started to really enjoy that
and have now been edging my way to the back end for a while. Now I'm job
hunting at the same time and definitely feeling that desert of despair. Was
glad to see your post, gives me some hope!

------
zaphar
I think one effective way to navigate the "Desert of Despair" is to join
another project first. That gives you the focus you need and set of practices
and libraries/language/frameworks to learn deeply. And as you learn how senior
people in the project make their decisions and hear stories about the history
of the project you gain context and valuable information for the next stage.

Much of what I've learned I learned by working with or lurking in the
communities of open source projects.

~~~
chii
basically, joining a project with senior programmers is akin to an
apprenticeship for other crafts. If you have the opportunity, because you
chanced upon somebody willing to do it with you (especially if for free), then
take it.

But most people won't get that opportunity, or isn't smart enough to go look
for it.

------
erikb
I feel I hit the job ready part and started to work as a software engineer and
I think I'm about as productive as I cost the company. Actually I feel a
little better than that and my colleagues a little worse than that, but I
guess that's how everybody in the middle feels.

The thing is, after that job ready upwards slope there is the next downswing.
You're able to get something done, but what you envision is not what the
company needs. You also realise that to be productive you need a lot of skills
you never learned in school time at all, e.g. packaging, shipping code to
customers, versioning, and actually create a tool that another person can,
reading code of other people, and finally using the tools your coworkers build
which are only marginally more productive than doing it manually or writing
your own tools, and only after learning the arcane ways in that they are
designed (much like the tools of your design, and quite different from the
billion dollar applications you are used to in daily life). Also you will
really become slower, because all the meetings and compromises drain your
energy more than the coding, but there is no way around it if you work in a
team. Is there another high coming after that? From looking at my coworkers it
seems this down swing will last.

tl;dr the job ready high is not the end.

~~~
zaphar
Yes there is another upswing after that. But be aware some of the on the job
skills are not unique to Software Dev.

* How to run a meeting.

* How to allocate Make time.

* How to collaborate with other people.

* How to understand business needs.

All of these are skills you need in any white collar job. Learning them is a
part of any job you might do.

Even the software specific ones like:

* Packaging

* Shipping

* Versioning

* Tooling

Are all going to be job specific. You'll find some of them to totally non
portable and some of them will transfer just fine.

The good news is that by now you'll have begun to hit a groove when it comes
to knowledge acquisition and learning this stuff will get easier.

The next high is when you start to recognize Process Patterns in the jobs you
take on and how to best handle them. Or even which ones to avoid like the
plague either by effecting change in the company or changing employers.

------
bigger_cheese
There is a difference between knowing how to write code and being a "software
developer". I think a lot of people confuse the two. I am an Engineer (not the
software kind) I write code almost every day in my job but I do not identify
myself as a programmer. For me code is a tool to be used to solve a problem,
like Calculus or Linear Algebra.

When I was at Uni we were required to take two subjects through the computer
science faculty, "Intro to algorithms and data structures" and "Fundamentals
of Software Engineering". The first subject was hugely interesting and I "Got
it" right away. It was basically teaching you how to represent a problem
computationally, we learnt about Binary and floating point representaion, what
a stack was that sort of thing. This is heap sort, this is bubble sort, this
is O(N) this is O(Log N) it clicked for me.

The second subject not so much. It was all about Unit tests, object oriented
programming, the waterfall model. We had to write an essay about Ariane V
failure. The lecturer was really big on a guy called Bertrand Meyer and his
ideas about design by contract. The subject was really hard to engage with and
almost caused me to lose interest completely. It was probably a good subject
to learn if you were planning a career in software development but for a first
year engineer not so much.

As cruel as it sounds I think the best way to teach someone to code is to
explain algorithms and data to them. "Here's a Ruby tutorial try to follow
along and you to can be a programmer" is dishonest and in my opinion not
learning the fundamentals up front is what causes that "chasm of dispair" the
article aludes to.

------
mamcx
Great post.

Something to add: This cycle not happened only _once_ in a programmer life.

IS RECURSIVE!

Every time you start with a new language or tool or job, the cycle start
_again_.

But is added ANOTHER step: Overconfidence and blind arrogant OR indifference.

This is revealed when somebody dismiss the new language/tool/programing job
and because is more-or-less similar to previous knowledge and could learn the
basics of it in days/hours then think it nailed again. Is possible to be in
this new honey-moon for a while (or forever somethings), but could eventually
and suddenly hit hard that you are NOT A MASTER OF 2 SKILLS, you are a (maybe)
a MASTER of 1 and a noob of 2.

The arrogant & indifferent mind also is revealed in the condesending thinking
towards who are outside the "guild" or "below" us. Is very easy to believe you
are in the laters steps, when is really not.

The key point in this article is the problem of "you don't know what you don't
know". For years I imagine I was a decent developer (and could have said
similar things as others in this threads) but is only in the last 2 years
where I realize how misplaced my understanding was. I was in the "The Cliff of
Confusion" and very happy about it ;)

~~~
danellis
> Something to add: This cycle not happened only once in a programmer life. IS
> RECURSIVE!

I was going to say that this was nothing like my experience of learning to
program, but it does quite accurately represent the process of adding new
skills these days.

------
stegosaurus
This article is a really odd read for me.

What sticks out is the idea of learning to code with the idea of becoming 'Job
Ready'. As others have said, seemingly treating the process as a means to an
end rather than a journey in and of itself.

No one learns to walk in order to hike up mountains. We start out with a fuzzy
basic idea that it'd be cool if we could just move across the floor a bit and
get closer to somewhere. And oh, isn't it fun to watch the world fly by!

Programming has always been that way for me. Making a computer print Hello
World on the screen, and then draw a circle, and maybe calculate some primes,
and so on... the entire process is learning. You're always learning. In those
early days I had no magazines, no Internet, no peers to compare myself to... I
just sat at a screen and tinkered, cobbling together bits from various scripts
and tinkering.

Mastering it - now that's a different kettle of fish entirely.

Maybe it's some sort of capitalistic artifact, the drive to push faster and
harder and more efficiently. Not being able to sit back and just, be, without
constant comparison or anxiety.

------
parenthetically
Really good discussion of what falls apart when these "anyone can learn to
code!" tutorials leave you high and dry, and how to get past that next huge
hurdle of self-sufficiency.

~~~
puranjay
As someone who is currently learning how to code, the author gets it mostly
right.

For me, the hardest parts of programming as a beginner - understanding OOP,
data structures, etc. - didn't really 'click' until I stopped reading
tutorials about them and start writing my own programs. The idea of 'objects'
and 'instance variables' was mind boggingly confusing at first, but once I
stopped worrying about how to make sense of them, the concepts somehow just
fell into place.

I've also been trying to learn French simultaneously. The process was somewhat
similar - taking a few Duolingo lessons and thinking that 'hey, I can do
this!'. Then I read some actual French prose and everything seemed impossibly
difficult. Things didn't 'click' until I started living and breathing French.

It's the same thing with coding.

~~~
danieldk
_start writing my own programs_

Indeed, you can only get good at programming by doing it.

As someone who learnt programming in the 90ies, one of the difficult things
nowadays seems to be that there are so many languages, libraries, frameworks,
hypes, etc. Of course, if you know your CS and have experience, most of it are
variations on common themes. However, I can imagine that it can be very
difficult to focus on one thing and learning it well. There must be many copy
& paste programmers out there who never learn anything in depth.

At the beginning of the nineties things were much simpler. If you had a home
PC (obviously without internet), you could get started with QBasic, or shell
out some money for a compiler and get Turbo Pascal or Turbo C++.

I did quite a bit of Turbo Pascal programming at some point and it was all
very understandable. A simple language, a small standard library that's
probably all that you'll have, good documentation, and an IDE (which had a
very nice debugger and profiler). And you just crafted tools with that.

~~~
puranjay
I actually learned HTML, CSS and JS way back when I was in 6th grade. This was
pre dot-com time and there were only a handful of resources. You could
understand HTML and CSS in a day because there were so few HTML tags and
requirements. 'Frameworks' was something that didn't even exist.

I somehow stopped my learning process before I hit 8th grade (around the same
time I discovered that the opposite sex exists). When I picked it up again
recently, the sheer number and complexity of frameworks and languages itself
was daunting.

I can't imagine how hard it must be for someone who hasn't had a lick of
coding experience. I could at least build a good looking website in HTML, CSS
and simple JS before I started learning how to code.

It's damn tough and it has given me newfound respect for top coders. I work in
marketing in my day job, and honestly, you could teach someone to replace me
within a few weeks

------
pjbrunet
It's only hard once you realize the commitment required, partly due to the
pace of innovation, the depth and breadth of information available and the
fact you're competing with the entire world, not just people in your
city/state, and there's nobody regulating the influx of competition. A
significant chunk of your life will be spent looking at a screen and there's a
chance you could end up with a crippling case of carpal tunnel. It's a
sacrifice and most people won't make it. In the same amount of time you RTFM,
you could have learned to be a brain surgeon, a rocket scientist and a lawyer.
And once you have it all figured out, half of everything you learned gets
flushed down the toilet because there's some new platform. If you think it's
hard and you're not enjoying yourself, don't even bother, there's easier ways
to make money.

~~~
ForHackernews
C'mon, all of those things you listed (brain surgeon, rocket scientist,
lawyer) are WAY harder and more expensive/time-intensive to get into than
software engineering.

If you feel like your knowledge is getting flushed away with a new platform,
then you've been learning the wrong things.

~~~
inDigiNeous
Really? How is being a brain surgeon more difficult than being a computer
surgeon ? Understanding how a CPU completely works, on the assembler and even
on hardware level is FRIGGING HARD. Computers are very complex and huge beasts
of logic to really understand, and the best programmers have to understand a
huge amount of technical skills and systems in order to get the wanted
results.

I have no idea how much stuff a brain surgeon has to learn, but having the
idea that there are people who are brain surgeons, it cannot be so much harder
than being a really competent programmer.

Think John Carmack for example. That guy is a friggin beast in learning new
systems and producing working code. That is really, really hard to do. It
requires immensive amount of thinking and applying, and sitting in front of
computers while balancing your body and health at the same time so you dont
kill yourself in the process or go mentally insane and just give up.

Oh yeah, but Carmack is a rocket scientist too .. so, maybe not the best
example.

But putting those jobs above really competent programmers is just stupid, if
you want to be best in what you do, in any life path you are taking, it will
take all of your effort, and then some more. So why compare. It's all about
doing what you love.

~~~
pflats
>Really? How is being a brain surgeon more difficult than being a computer
surgeon ? Understanding how a CPU completely works...

Well, we know how everything about how a CPU works. We don't know everything
about how a brain works.

~~~
geebee
Are there really no longer any open and relevant research issues around this
topic? Is humanity's understanding of CPUs, how they work, how they should
work, is it all wrapped up and complete?

Not really my field, so I truly don't know. But I'd be a little suspicious of
someone who claims there's nothing new to learn here.

~~~
4ydx
I don't think he means innovation which seems to be what you are implying. If
you take a current working computer system, there are no "mysteries" in the
existing hardware where the hardware designer just threw up their hands and
decided to hope it would work. Sure when you throw in environmental factors
there is certainly unpredictability in terms of hardware failure, but actually
understanding what the system is doing? We know what it does. With something
like the human body, it doesn't seem that we can be nearly as confident.

~~~
geebee
Sure, but I think that definition makes the difference in complexity a bit of
a contrivance. You're deliberately excluding the things that make CPUs
complicated and interesting, and then concluding that they aren't as
complicated and interesting as something else.

The other thing is that while the brain is highly complex, that doesn't mean
that people who work in it have managed to master something more complex than
CPUs (or house wiring, for that matter). They may simply not really understand
what they're doing to the same extent.

To me, the thesis in the original post is this "[if] there are people who are
brain surgeons, it cannot be so much harder than being a really competent
programmer."

I tend to agree, because I think that some types of programming push people's
mental ability and sheer stubbornness past the point of human ability. In
short, it will take all you have, and there will still be things you just
can't understand or do.

If you define the task as "the things that we understand and can do", then by
definition is is not equal in complexity to the brain, but like I said, I
think the statement is a contrivance.

~~~
inDigiNeous
This, exactly. CPUs and their insides, the hardware, understanding that, and
then understanding the whole software stack that runs on that hardware, I mean
_really_ understanding, by definition that if one bit was off in the RAM you
could completely trace it all the way from the application level to the
hardware level.

Almost nobody can do that. The hardware alone is so complex, these modern CPUs
have many BILLIONS of transistors packed so tight that it is impossible for us
to even fix them. So we just have a vague understanding of what is going on
when we program, but really, we have no clear picture. But the best
programmers out there, they have this map of the computer in their heads and
the systems, and the better you are, the better the map in your head is.

Think NASA level programmers. They truly have to know how the system works,
and yet, they cannot most probably understand the whole stack even, down to
the transistor level operation, and then below that even in some really
extreme cases where the systems overheat and there is magnetic bit flipping
happening and other obscure stuff.

Immense amounts of work equals to amount of commitment required, which equals
hard. To be a really competent programmer that knows how to truly take
advantage of the machine is really rare, and even then it is down to some very
specific domain, like graphics programming, systems programming and so on. So
it is very hard to achieve, and very rare.

------
jussij
Why _programming is hard_ is why _everything is hard_.

You’re not going to get good at anything unless you work hard at it.

All these _hand holding sites_ are worthless because all the stuff on them is
so easy. But they are popular because people are always looking for the easy
option.

Want to be a good programmer. Buy a _well-recommended_ book and spend 3 hours
a day, 7 days a week trying to write code. Start with _hello world_ and then
build from there.

After three 3 months of that _hard grind_ you'll either have some idea on how
to write code or you will find you don't have the aptitude to be a programmer.

The bad news is even if you do find you can write code, the _hard grind_ has
just started.

You'll have to repeat the process for other programming topics like data
structures, programming patterns, testing strategies, understanding database
design etc etc.

Move forward five years and you're well on the way to being a well rounded
developer.

------
jbergens
I think one big problem is the expectations. People think that they can learn
a lot of programming in 3 months or 1 year or something. I think it takes a
lot of time, unless you happen to be "hardwired" for it. As someone wrote
there are a lot of developers coming out from an education which still has a
lot to learn. That means you might need 3 years of education and 1-2 years of
practical work experience to actually learn. Or you could start when you're 8
and do it by yourself for over 10 years. When you are 20 you probably knows a
lot about programming or you will have stopped already. Try to explain to
people wanting to learn how to code that it might take 3-5 years, then they
can choose if this is something they want. Or sell simple 1 year courses but
explain that they will only learn a small subset then.

------
sklarsa
From my experience as someone who is primarily self-taught, I think that
having a more experienced programmer who can act as a mentor is vital to one's
own growth as a developer. My first experiences programming in a professional
capacity consisted of writing VBA macros to either automate tasks like moving
or reformatting data, or in one instance, run an iterative algorithm that
could not be expressed simply with excel formulas. Looking back, I was stuck
at that level for several years, until I was given some new assignments that
were signficantly harder than my previous ones, and I had no idea where to
begin. I discussed some of my current assignments with a colleague who had
some programming experience, and he gave me a few basic lessons (in VBA) about
object-oriented programming and communicating with SQL databases using the
OLEDB library. Based on this knowledge, I set out to build some advanced,
database-enabled spreadsheets, relying heavily on Google, Stack Overflow, and
various blogs whenever I hit a snag. As I was progressing, I would bounce
architecture ideas off my mentor and he would give me some topics to research
in more depth. I would then go back to my online resources to figure out how
to apply these new concepts to help solve my problem. As time went on and I
became more confident in my skills, with the advice of my mentor, I moved from
Access to SQL Server and from VBA to C# and the .NET Framework, eventually
reaching a point where I became a self-sufficient programmer developing full
scale applications used across my firm.

For a motivated student, I think this method of teaching can yield tremendous
results. With the vast amount of detailed information out there from tons of
easily accessible sources, having a more experienced mentor create a path for
the novice to follow but also letting the student figure out the
implementation details on his/her own can be very rewarding. It allows the
student to develop strong problem-solving skills within a smaller context (so
the student doesn't get overwhelmed with indecision) yet also provides a
support system when the student truly is stuck on a problem. I'm not
suggesting that this is the BEST or ONLY way programming should be taught, but
for someone like me, who learns best by doing, it can be a great way to get
started in the field.

------
ivanhoe
For me it was never hard because I started as a kid, on my own, so I was
exploring this new world at my own pace and terms, and it was amazing and fun.
That's how kids learn. Learning the grown up way is on the other hand harder
and takes time. For coding you actually need to master 2 separate, non-trivial
skills: first to learn how to think/solve problems in a certain way, and
second to learn the particular language. I think the main problem is that
people don't give themselves enough time for the first, and concentrate only
on the second.

------
DanielKehoe
I've had the pleasure of co-teaching Rails classes with Erik Trautman (OP) and
he's a smart, dedicated guy. He's written a thoughtful article but underplays
a key point. Learning to code would not be "so damn hard" if there were better
learning resources. There's too much "learn to code" crap for beginners (as
Erik points out), and not enough resources for advanced education (the
"resource density" in the "Desert of Despair," as he points out). Learning to
code would be easier if someone produced better advanced tutorials, books, and
courses. I've been doing this for two years with the RailsApps tutorials [1].
And my "fluffy cat" book, "Learn Ruby on Rails," [2] provides guidance for
writing apps from scratch without tutorials. Erik's article would be totally
irrelevant if authors and teachers delivered better educational content.
Erik's trying to do it with Viking Code School, and I've been trying to do it
with my own writing, too. It's educators and authors that have to get smarter
and work harder, not learners.

[1] [https://tutorials.railsapps.org/](https://tutorials.railsapps.org/) [2]
"Learn Ruby on Rails" on Amazon:
[http://www.amazon.com/dp/B00QK2T1SY](http://www.amazon.com/dp/B00QK2T1SY)

~~~
rimantas
No. No amount of resource will help with the kind of mental gymanstics
required for programming (manipulating abstractions). Resources will help once
you have that ability, but I am not sure how trainable it is itself.

------
jared314
I always thought the "Desert of Despair" was the point at which you should
find a mentor with professional experience, instead of waiting for the
"Upswing of Awesome".

~~~
drcomputer
The upswing of awesome sounds like a great way to prepare yourself to build
things that are 90% correct with a 10% catastrophic failure rate.

I really try to keep a more emotionally neutral stance on all of my code and
my abilities. If I want to indulge in arrogance I philosophize.

In the end, it's the same thing over and over again. Symbols swapping with
others symbols denoting some kind of esoterically tangible, but ultimately
fleeting, meaning.

It'd be nice to not feel perpetually stuck in the desert of despair though. I
used to think being there meant I was learning stuff, because I had
intuitively learned from repeat failure that after failure comes success.
Turns out you can think about yourself plodding along at a steady pace, with
no comparison to anyone else, as long as you stop assuming that there exists a
clear, coherent, ordered organization to knowledge.

There exists such a thing in school, or at least the commentary on a
topological sorting would have you believe. Technology doesn't always develop
and get released in school though. Sometimes it develops in webs that are can
not be causally described, because thought and skill do not necessarily travel
in measurable directions, nor is their instantiation completely
definable/observable.

People apply too many theoretical concepts to describe, dictate, and organize
reality without understanding the effect on perception.

~~~
sturakov
You've made an interesting comment. I've felt the same way about some of the
things you've mentioned, such as

"In the end, it's the same thing over and over again. Symbols swapping with
others symbols denoting some kind of esoterically tangible, but ultimately
fleeting, meaning."

I feel that way about all the different languages, new ones or old. Just
different symbols that distill down to machine instructions.

My question to you, how do you approach learning? Learning new things and
marking your progress? What gives you the satisfaction that you've made
progress in "learning" a given topic?

~~~
drcomputer
> My question to you, how do you approach learning? Learning new things and
> marking your progress? What gives you the satisfaction that you've made
> progress in "learning" a given topic?

I don't know. Right now I am learning how to not know when I am learning,
because I have determined that measuring learning in any form can often be a
barrier that actually prevents me from learning.

~~~
sturakov
Interesting.

------
analog31
I learned to program in BASIC, in 1981. I think that while learning to program
has become more _accessible_ thanks to the Web, it has also probably gotten
harder do to the exponential increase in complexity of the systems that we
program. There is also much more to software development than just
programming.

In my day (taking the liberty of revisionist exaggeration), one could write
cool and useful programs with a simple language and text based i/o.
Programming and software development were nearly the same thing, and were
exactly the same if you were an amateur like me.

Today, languages are necessarily more complex in order to interface with ...
enormous systems and libraries of exponentially increasing complexity. At
least, that's what it seems like from where I sit. And software development
goes way beyond programming. Once you learn to program, there's a whole
'nother stage of learning how to use big code libraries, frameworks, IDE's,
and so forth. I'm not sure anybody has figured out how to teach someone else
to approach a big code library.

Maybe there should be a set of lessons in Code Academy, whose point is to
learn how to get stuff done using the documentation and related lore
(StackOverflow, etc.) for a complex library like MatPlotLib. I did something
similar when I agreed to teach a review session for a math course that I had
never taken. I had no choice but to show how to approach a textbook as a
resource for solving problems. Maybe my students got more out of that, than
they would have from just memorizing formulas.

For kids, a way around this problem might be to strip away the complexity by
teaching programming on a platform that just doesn't have all of that stuff,
e.g., Arduino.

------
rebootthesystem
Learning to code isn't hard at all. Learning to solve problems computationally
is a different matter. There are tomes of knowledge one must acquire that is
usually application specific and in potentially narrow fields. For example, if
you want to write a RTOS you need to study and learn OS theory. Want to work
on GPS code? Well, there's some math you need to understand along with a pile
of other stuff. Want to work on search? Better have a very good handle of a
range of algorithms and know how to implement them efficiently. Automation?
Hmmm, you can't set an output and expect the machine to respond when there's
physics involved. Aircraft control systems? ....

The point is that coding is easy just like understanding the basics of running
a milling machine is easy. Being a machinist is far more complex than knowing
how to turn the wheels. And machining highly accurate objects in exotic metals
is multiple levels above that. Learning "machining" is easy. Learning to be a
machinist is hard. Same for coding. Learning to code: easy. Becoming a
software engineer: Harder.

------
yodsanklai
I think "coding" professionally involves a lot more than being able to write
simple programs for fun on his own. That's why I don't really like the term
"coding".

I considered myself a good programmer, but during my first job as an intern, I
was confronted to million of lines of barely documented C++ code (a C compiler
for some obscure micro-controler). Most of my time was spent trying to
understand what this code was doing, and praying that I didn't break anything.
The days were long with no distraction and I had a lot of pressure from my
boss. It was horrible.

Second job (still as an intern) was the opposite. I was supposed to design a
prototype website for a bank. There were a lot of boring meetings and nothing
really interesting to do.

I didn't feel I could be successful or happy in such an environment (and I
ended up in academia). On the other hand, I had schoolmates that weren't
passionate about programming and that learned it much later than I did, and
did quite well (being persistent with good social skills).

I always wonder if I could have had a better experience in different
companies.

------
tsumnia
Currently I teach Java courses (up to Data Structures) and I give the warning
at the beginning of the semester. I don't use it as a scare tactic to be mean,
but to help instill the sense of difficulty in the course.

Programming is only hard because it is simultaneously a basic IT, foreign
language, applied mathematics and logic class wrapped into one! Also, since
its 100% cumulative, every class they miss can be a death sentence. How can
you understand Inheritance if you missed the lecture on Objects (or
Conditionals if you missed Variables)? I've specifically told my students not
to use an IDE for the first month so they get an understanding of how command
line operates.

I think another issue is simply underestimating the time it takes to complete
a simple assignment like implementing the distance formula. Taking an
algorithm you understand and translating it correctly can be an exponential
problem.

I try to model my courses very similar to the MOOCs I've used for practice
(edX, Codecademy, and Udacity) - I am a developer turned instructor, so I use
these courses as guidelines as what to do. Also, I look at something like
MIT's edX courses and think "if this is what they teach, why shouldn't try to
model that?"

The one thing I like about the courses are that they each uses a constant
engagement tactic to ensure the user did learn what they heard. 5-7 minute
video, then immediately a quiz or 'lecture exercise' designed to make sure you
get the material (not just repeat a definition).

Again looking at MIT's edX 6.00x course, you are given "Problem Sets"
(homework) that is given a week to be completed. Each part builds to a grand
finale. For example, the distance formula mentioned above is then used in my
course to implement a crude version of collision detection
(www.youtube.com/watch?v=W84QzXUxcL0). I use collision detection because one
of the key demographics of CS courses are nerdy gamers (not an insult, I love
Binding of Isaac, but that's one of the people that go into CS).

One of the other things I try to do is follow the structure of my martial arts
classes. In aikido, we start each class with "tai sabaki" (basic body
movements). Since these are the core fundamentals of the art, practice makes
permanent. I want to start adding basic keyboarding exercises of basic syntax
to get them in the habit writing the words that look like english, but aren't.

~~~
tsumnia
That sort of deviated into more of a 'this is what I do', but the ultimate
goal was to try to ease the difficulty of the courses as best you can. If
they're slackers, let them fail, but if they have a want to learn and it is
just confusing, figure out how to get them to learn.

Developers are problem solvers, the student doesn't get the material, figure
out how to solve the problem.

------
GrinningFool
Warning, unpopular opinion based on experience lies ahead.

The ability to program (and can we please stop calling it 'coding' as a career
path? Writing code is the smallest part of programming) is something that
either comes naturally to you or it doesn't.

If it does, you wonder why everyone says it's hard - to you, it's almost
literally how you think. The pieces just fall into place.

If it doesn't, it's always an uphill battle. You can acquire proficiency
through a lot of hard, painful work. Most people who fit this category can do
the job, but they do it through rote following of procedure as opposed to
exploration and intuition that comes from putting the pieces together without
consciously thinking about it.

This isn't a matter of intelligence. it's just a certain way of thinking that
some seem to have and some don't. Plenty of extremely smart people aren't
built for programming.

On the other hand, if we accepted this, then there wouldn't be much of a
business model left for the likes of vikingcodeschool.com ;)

~~~
inDigiNeous
Agree on this one. Certain kinds of people and thinkers tend to gravitate
towards programming. The aspect of getting satisfaction from seeing the
perfect alignment of code on the screen, and the satisfaction of re-factoring
code into clean, modular pieces, must somehow satisfy the programmer in order
to get a kick out if it.

So probably those who are naturally logical thinkers, even to a level that
normally would not be very useful, become useful in the computer space where
they can utilize their internal skills of putting things into neat ordered
rows of zeros and ones.

------
msc96
Personally I find the confidence vs competence graph to reflect my feelings
when learning things in general, although not necessarily for the same
reasons. There's always a period of eager discovery followed by the stark
realization of how far away mastery is and finally the gradual slow crawl
toward success.

------
chrstphrhrt
This seems true of any relationship with something outside yourself.

Perhaps the curve of familiarity with the other for any empiricist.

Look at a totally foreign thing. First comes cautiousness about whether it
exists, but then just by looking you get a vague notion that it's a coherent
thing. Then curiosity draws you closer to it and therefore you see the thing
in greater detail. Some of the newly visible bits mess with your idealised
picture of the thing from before. Only if you decide to persevere in
understanding this other do you start to integrate these discordant stimuli
into the currently running model of it. As the thing comes into clearer focus
you realise that the discoveries are slowly revealing negative entropy. It's
safe there. Following the trail inevitably results in reaching the end of it.

If only there were a standardised protocol for consuming the universe.

------
cubano
> Phase III: The Desert of Despair

I've been programming for 30+ years, and have yet to ever leave this phase.
;-)

------
SteB
Super interesting article. I used to be a big fan of Codecademy and other
online website to learn to code. The author is right, at some point you need
motivation, like in any new thing, and that's where I think most of them are
failing.

Without a real project or a constant progress that you can follow, you easily
end up abandoning that site.

I built CloudAcademy.com more than a year ago and even if we are focues on
Cloud Computing platforms like AWS, one the things we are trying to solve is
providing good, constant information to our students on their progresses.
That's the most important thing. In our case they really need those skills to
they have a very high motivation to complete the courses, but still, I see
this as a priority for an e-learning platform.

------
skylark
The ease with which you code is directly related to your general problem
solving ability. The better you are at solving problems, the more simple and
straightforward you'll find programming, because coding is simply an extension
of the thoughts which are already floating through your head.

This is why learning to program is so difficult for some people. If you have
poor problem solving ability, putting a second abstraction layer over it
(thoughts -> something the computer can understand) can be ridiculously
difficult. This is especially true for abstractions which don't map directly
to thoughts human beings typically have (recursion, pointers, etc.)

This is also why learning to program is so effortless and simple for others.

------
cossatot
In my experience, one thing that can make the path feel more progressive and
monotonic is having a set of problems that need to be solved, with a wide
range of difficulties. This provides consistent short-term gratification while
also providing long-term gratification and utility.

For me, as an earth scientist, there have always been small calculations or
simulations that are quite valuable, even though they are not overly difficult
or complex. This provided the motivation to learn basic Matlab. As my skills
and ambition grew, and I learned new languages and techniques, the class of
problems that I wanted to solve grew in scope and complexity. I also learned
to recognize new problems and their probable solutions as my tools developed.
Programming changed the way I look at the earth, and at statistics, personal
finance and a range of other things in which quantification is enlightening.

In contrast, I have had a hard time picking up new languages or programming
paradigms when I don't have an immediate need. I've spent time mucking around
on various 'learn to code' websites, and read and sometimes completed
tutorials on databases or Haskell or whatever, but it feels very different:
meandering, non-essential, hard to gauge in scope (how much do I need to know
to be useful, how deep is the water really), hard to link up to the rest of my
life. Programming for me is a powerful and enjoyable means to many ends, but
not something that I am inclined to do for its own sake.

I think if I had said, "I want to learn to program so I can build web apps"
without actually having a simple and truly useful web app that needed to be
built, I would very quickly move on. If I had said, "I want to learn to
program so I can find a new job that pays more money" I would stick with it
for a bit longer but it would be incredibly frustrating, because it doesn't
seem like there is a very straight path without formal guidance (such as going
to school of some sort).

I suspect many people feel the same, but I don't necessarily know how smaller,
less formal education systems can work on that. Students always need some
amount of self-motivation, and useful results are a long ways off in some
areas.

~~~
Betelgeuse90
What you said really resonated with me. Especially your professed sources of
motivation and how programming for its own sake was never enough.

------
Dove
Huh. This must be a generational thing. When I started learning to code 20
years ago, there wasn't any hand-holding. There were college courses and
textbooks and sometimes mentors and ultimately your own ability to work things
out from documentation and first principles. My projects grew in scope as I
got better at it, but I never thought it was anything but awesome.

Then again, I never set out to "be a developer". I was bitten by the coding
bug as a kid, and tripped over the discovery, as an adult, that it paid pretty
well.

------
austenallred
The hard thing about learning to program is that to create anything even
vaguely useful you have to learn a million things in parallel.

Say you wanted to build the simplest of Rails apps - you're simultaneously
learning not only what the terminal and a text editor is, but how unix
commands work, what an MVC framework is, probably a little of HTML and CSS,
database migrations (maybe some SQL), asset management/pipeline, some random
Rails-specific syntax, probably git, and if the creator of the tutorial is
feeling ambitious he/she may throw in some TDD and testing frameworks. And
that doesn't even begin to go into _Ruby_ \-- the entire _programming_ aspect
of programming.

So you're thrown out into the middle of the ocean, and blindly writing code
you don't understand (because there's no way any tutorial could fully explain
everything you're learning without being 2,000 pages long). You follow the
tutorial, you get your little app running, then you realize, "I have no
fucking idea what I just did." There's no way on earth you could do it again.

The other approach is to bring you from the bottom up, starting with
language/syntax Codecademy style. So you spend a month learning how to almost
be able to write a for loop in JavaScript, and then you realize you have no
idea why you would ever need to know what a for loop is, and even less of an
idea of why it's useful.

I got stuck bouncing back and forth between the two for years (literally),
wondering how the other programmers were possibly smart enough that they could
grasp meaning from random blobs of tutorial code, or how they possibly had the
patience to grind through enough JavaScript tutorials enough that they could
actually create something. I finally decided to throw away the crutches and
venture out on my own. I think that was the single biggest step in becoming a
(decent) programmer.

The timid, "I don't know how to program" side of me said, "Wait, I have no
idea how to do this yet. You need to read up on it." But I finally bit the
bullet and said, "You know what, I'm building this app right now. No, I don't
know how to do a lot of it, yes, my friends that are a lot smarter would
probably mock my code if they saw it, but I don't care. I'm building this." I
don't think you can ever truly learn to program without saying, "I don't care,
I'm building this." It took a long time and more Stack Overflow than anyone
should ever care to read, but things finally started clicking. I built a few
apps (Rails and iOS), went back to the tutorials, and said, "Are you kidding
me? _That 's_ what they were trying to teach me?"

There was no way I would have remembered that crap if there was someone
guiding me through or holding my hand. Sometimes you just have to start,
having no idea what you're doing, and figure it out as you go. That's a
foreign concept to people who aren't used to creating things, but I'm
convinced it's the only way to truly learn.

~~~
sleazebreeze
My first real, non-toy app was an Android card game. I knew the basics of Java
going into it, but nothing else. Following tutorials got me to where I had an
app that I could install and run on my device.

At that point, it was up to me to figure out what to do. I started with a
single screen that showed some text and added a few more screens that had the
same text. Then I added a button that triggered a change of that text. Then a
button that displayed an image. And so on until I had a real card game that
could even identify whether there were any legal moves available and if the
player was stuck.

Every step along the way was not easy and I got derailed a couple times,
nearly giving up. The hardest single feature to implement was dragging and
dropping a card. It took a lot of cribbed code from a few useful blog posts,
but the feeling when I actually got it working was indescribable. It was a
Saturday morning and I was running around my house, dragging and dropping
cards on my tablet like I was 8 years old and it was the greatest Christmas
gift ever. That was the moment when I realized I could actually finish this if
I was willing to put in the effort. The rest of that weekend was spent in
blissful coding and my commitment to becoming a developer has never wavered
since.

Now in my job, which I got an interview for because of the card game, I have
witnessed other people with less self-guided (contrasted with CS class
projects) experience than I started out with be unable to persist long enough
or self-teach hard enough to solve a problem by themselves without asking for
help to get over minor bumps. I won't ask for help from a more senior dev
unless I have exhausted my abilities to understand the problem space and can
enumerate the things I have tried. I refuse to be the person who simply
"doesn't know how".

Never ever give up.

------
blueside
For many years, I thought everything was very complex and would be difficult
to learn and perhaps I wasn't smart enough to gain a full cognition on the
subject matter

But I was able to take a big step back one day and realize everything isn't
always complex, a lot of the times it is just over complicated and over
engineered. Whether it's true or not, it has helped me immensely in my
approach to look at new code from a more advantageous angle and more
importantly, supply me with the confidence.

------
shanecleveland
"You can make that application work but what's happening beneath the surface?
Your code is duct tape and string and, worst of all, you don’t even know which
parts are terrible and which are actually just fine."

I commonly get to this point after just wanting to proof out a concept and get
something working. And then I realize I need to go back and do the unglamorous
work of getting it right. But I learn the most then, and helps enormously on
future projects.

------
snake_plissken
Also, for rookies and veterans alike, when you are learning something new
(especially tech stuff) and it's getting progressively more difficult,
remember to take it easy on yourself and to relax. Those stress induced
tension headaches from squinting, furrowing your brow and getting overwhelmed
from the unavoidable and apparent decrease in your progress are productivity
killers.

Relax, and remember that at some time, everyone is a neophyte.

------
ayushgta
This reminded me of another well written article from last year. Posting it
here for others who might have missed it:
[http://techcrunch.com/2014/05/24/dont-believe-anyone-who-
tel...](http://techcrunch.com/2014/05/24/dont-believe-anyone-who-tells-you-
learning-to-code-is-easy/) (Yes its from TechCrunch, but its actually good)

------
bnb
Hey there, really, really great article! It really spoke to me. I've got a
small question for you, though: I'm in the Cliff of Confusion, but I have a
serious problem. I can't even build a program. I know syntax, structure, etc.,
but I don't know how to pull all of it together to actually build something
that serves a purpose. Do you have any advice for me?

~~~
eriktrautman
This is actually a good time to check out a few tutorials to ease into
building mindset and patterns. They start to become a crutch eventually but
can be a great transition between syntax and building. I don't know your
stack, but if you're looking for Rails check out Daniel Kehoe's RailsApps,
Tuts Plus has some free stuff and, if you're looking to get deeper, the Hartl
Tutorial in Rails is the standard (though it's often too much for a beginner).
Google will know more than I for specific resources.

------
harpb
Learning to code is not hard if you define the code to a smaller step of
problem. Learning to code is impossible if you define it as "program for voice
recognizition in english and spanish'. If problem is defined as "print Hello
World' then you know how to code once you learn to solve that problem. Further
more, it is easier problem to solve.

~~~
MAGZine
breaking problems down into smaller and smaller pieces, I think, is a
challenging skill to master, and people struggle differently with it (from
"not at all," to "immensely.")

If you break a problem down far enough, eventually you end up with groups of
problems, each containing simple conditional statements, a few variables,
maybe a loop :-). That's the challenge new programmers face!

------
adamzerner
> Unfortunately, in later phases the density of resources drops off fast.
> Anyone who's made the jump from beginner to intermediate can attest that
> there is a BIG difference between the amount of resources available when you
> first start out versus when you're first looking for help building things on
> your own without too much hand-holding.

Scarcity = opportunity!

------
curyous
Learning to code is not hard. At all. Not relative to things that actually are
hard. Having trained as an electronic engineer, programming is by far one of
the easiest things I've ever done, by an order of magnitude. You can tell by
the number of teenagers that can code, how many teenagers can design a nuclear
submarine? That is much harder to learn.

~~~
kansface
Your comment is both unfairly dismissive and wrong.

| Learning to code is not hard. At all.

This assertion is empirically untrue in the market for programmers (if nothing
else). Why are programmers paid as skilled laborers? How many not hard (at
all), highly paid, and quite frankly cushy job exists? In the Bay, hiring is
the biggest problem.

| how many teenagers can design a nuclear submarine?

Why is designing a nuclear submarine the point of comparison? Is this some
sort of humble brag?

| That is much harder to learn.

No one claimed programming is the hardest job in the universe. It is perfectly
possible for harder jobs to exist and for programming to be hard.

------
FLUX-YOU
In my experience, this graph looks similar if you get hired at the first peak,
but the desert of despair doesn't dip as low as long as you have some form of
mentor or reviewer for your code. You can, of course, get hired to a bad job
and the desert will dip further down (and your risk of leaving the industry
increases).

------
noarchy
Even with years of experience in a given language under your belt, heading
into a new job and facing a new set of frameworks can lead to issues. It isn't
quite like starting from zero again, but you have re-learn how to do the most
trivial of things, as it may not even remotely resemble how you were used to
doing it.

------
aarant
Haven't read the article so it might be just random rant.

I find most articles confuse 'code' (producing code) and 'program' (making
programs).

I would argue the first one is relatively easy once you grasp concepts and
turing-cturing-completness.

The later however takes years if not decades.

------
vishalzone2002
This is probably true for a lot of other things. Learning an instrument,
learning karate, etc. basically its easy to get started than to keep going.

~~~
howardr
I can't remember the source, but I learned this in a management class in
college about 10 years ago. It was a general statement about learning
something new. You don't know what your don't know (so you are optimistic) ->
You realize you know nothing (so you are negative) -> Then you get better with
practice -> Mastery

------
dccoolgai
When someone asks me "How do I learn to code?" I always say "You don't. You
just code."

~~~
freehunter
And then they give up and do something else, with lower self esteem this time.

Seriously. "Just code" is the _worst advice_ that _everyone_ gives. It's
trite. You'd be better off saying nothing at all. Do you think you can sit
someone down with a C compiler and come back five years later to find they've
written the Linux kernel?

Don't say "just code". It's not helpful. It's disparaging. You don't tell a
child "just walk". You learn to code, you're not born with it.

~~~
dccoolgai
Of course one is not "born knowing how to code". Saying "Just code" does not
mean "sit down by yourself and try to figure out the C compiler." It means,
for most of the people I've met/worked with "Stop agonizing over what course
to take, what book to read, what you should build first - just build."
Implicit in that is that the person can ask me for help outside of some
master/grasshopper relationship.. no I'm a coder and so are you. Just show me
what you're working on and ask your buddy here for a hand if you need one.

I know a lot of people say something like "Just open up a git repo and start
making pull requests on the back end of your gulp process after you wget the
source from such-and-such repo"... Yeah, that annoys me too. I've had a lot of
success just sitting people down with Chrome and have them hit Ctrl+Shift+I
and show them a couple fun things with DOM maninpulation, etc. The point is,
the worst thing to do that I think claims the most victims on the path to
learning to code (I know I struggled with it for years) is just constantly
deliberating about what is the "best way to learn" when you should just be
playing, having fun and failing. That's the hump I try to nudge people over -
the idea that you need to have permission or a "master" to become a developer.

~~~
freehunter
I think we're way past the point where mindlessly playing around and idle
curiosity can reliably teach someone how to program. That might get them
interested in programming, but it's one thing to print something to a terminal
or change the text on an exiting page; it's quite something else to get a GUI
app going or deploy Rails to a server. And GUI/web is pretty bare-minimum when
it comes to keeping people interested in programming. Not a whole lot of
people want to write console applications anymore.

Here's the sticking points where beginners need your help, and might not even
have enough information to actually ask what they're looking for:

What framework do I use? I see people talking about AngularJS, so I'm going to
pick that one. Oh wow, it's harder than I thought bzzzt you just lost a future
programmer.

How do I deploy? DigitalOcean costs money, bzzzt there goes another. I paid
for DigitalOcean, but I ran into troubles installing pip, bzzt there goes
another.

How do I make a GUI? Tkinter, Wx, Qt, GTK, WPF, bzzzt there goes another.

And the worst of them all... "What language should I learn?"

Yeah, a lot of programmers might not want to hear this. But there are a lot of
languages. You can't blame a beginner for not being able to decide. And to be
honest, there isn't really a good choice here, which is why programmers get
into fights about languages and when that happens, bzzzt there goes another.
Javascript sucks, but people claim its essential. Beginners get turned off by
hearing "Javascript sucks but you have to learn it". The better option is to
just not learn programming. Or bringing political wars into it. "Don't learn
C# because M$". Beginners don't care about your politics, they want to learn.
Eventually people settle on Python, so the beginner starts learning Python,
then asks "what GUI framework" or "how do I deploy Django" and we start back
at the top of this list.

So, in the midst of all of this confusion happening for a beginner, they're
(understandably) lost and ask for a lighthouse to guide them on a path, any
path, as long as they don't have to make the choices themselves. So they ask
the question "how do I learn to program". And the response they get? "You
don't learn how to program, you just start programming."

Bzzt, you just lost the entire next generation.

~~~
svachalek
It's funny you use walking as an example. I never told my son to "just walk"
but I may as well have. No one taught him, he never asked how. It just never
occurred to him that there was any option but to keep trying until it works.
As far as I know everyone learns to walk this way.

In my generation and before it, most of us learned coding the same way. (And
self esteem for that matter.) Even if you do have the luxury of teachers and
classes and handholding and cheerleading, the real learning is not going to
happen until you sit down with a code editor and actually try to make
something real.

And if the first difficulty you hit causes you to turn around and run then
that's another win. It's a very fast way for you to learn this not a career or
hobby for you, because dealing with those decisions and difficulties is a
major part of the job. 30 years in I'm still dealing with stuff like that
every day.

~~~
freehunter
You taught your son to walk by walking. He learned to walk because everyone
around him was walking. That's undeniably the best way to learn: being in an
immersive environment. That's akin to going to hacker school.

What I'm saying is 'just write something' doesn't help people who would ask
the question 'how do I learn programming', It helps the people who ask 'how do
I get better at programming'. You get better at walking by walking more. You
get better at coding by coding more. You start walking by learning it from
someone else, or by using something to pull yourself up (like a chair or a
table leg). You learn programming by asking how and following their advice.

Your son didn't ask how to walk because he didn't know the question. Beginners
don't ask how to deploy because they don't know what deploy means. "Just code"
doesn't answer the problem of "how do I write a GUI app". It makes it seem
like it's so easy that you shouldn't have to ask. And since you don't know the
answer and no one will tell you, programming must be hard, or you must be
stupid. That's what a teacher or a mentor offers. Advice. Not glib remarks.

------
Animats
It's an ad. At the end: _Our core program is specifically designed to bridge
this whole process. ... Sign up below._ Worse, the training just creates
junior web developers. There's a glut of junior web developers.

The concept of Ruby on Rails was to make the whole process of web site
development a tutorial-level job from start to finish. How did that work out?

~~~
ItsMattyG
It's content marketing, a bit different from advertising. It only works if the
content is good (which it is in this case)

------
cturner
"... was convinced that the seemingly normal programmers I ran into were
actually sociopaths who had experienced, then repressed, the trauma of
learning to code."

It's true. The saddest part is that we forget who we were before we crossed
over, and lose the ability to sympathise with people who haven't been through
it.

~~~
zo1
I sympathize if I detect that they're genuine in their desire to learn and
improve themselves. As for the others, the ones that just want to "get by",
they don't get much of my sympathy. And that is _after_ I try my best to
inspire in them a sense of self-improvement when it comes to programming.
Alas, not everyone has that outlook on programming, but rather just see it as
a dumb-tool to muddle over some arbitrary problem someone dreamt up in some
ivory room, somewhere.

~~~
cturner
What I wrote reads that way and I can see my error. There are lots of
pretenders and I do not apologise for them. I intended to write that our
brains get rewired to make things that were once hard easy, that we do not
know what to explain.

My strategy for people who ask me to tutor them is this: work through the
first five chapters of /learn python the hard way/ by yourself, and I will
mentor you the rest. Those chapters are so easy, it is just a test of
motivation. I have only had one starter. Also, she finished.

------
xornor
Learning to code is not so hard, but learning to code well is extremely hard -
almost impossible. I have been doing software development years and years also
in some well known companies and I am not sure if I have yet met a good
developer.

------
peter303
I never found it that hard, either back in the 1970s or now.

------
z3t4
The more your learn, the more there is to learn!

------
callesgg
I have no memory of the basic concept of coding being hard to learn. I do
remember thinking it was cool that I could make stuff happen by itself.

------
rismay
vike22 Awesome! Keep it up!

------
dschiptsov
Because learning "to Code" is nonsense, and learning "to Program" is damn hard
because it is a whole new set of new mental habits, like an ability to zoom
thorough multiple levels of abstractions, without losing understanding. Think
of following of a flow of data from, say, linux TCP stack, to nginx, then via
fastcgi to some backend, then to, say, postgres, then back to code, then back
to client, remembering about memory allocations, data encoding, data-
structures build up, etc. Or, even better, think of how your code (interpreted
or compiled) would be executed, how syscalls would be made, would code block
during a syscall, is there another theread, what they are doing, is there are
locks, which kind, etc.

The idea that there is some Java which allows you not to think about all the
important details is just nonsense. You have to understand what are you doing
_and why_ , and this is so damn hard.

btw, Robert M. Pirsig has a whole book about why everything is so damn hard.

------
john_butts
Speaking as a rockstar bacon ninja Viking pirate robot code fu guru unicorn
damn hell aged and wise app developer, many of these problems could be
mitigated or eliminated in the web dev world if the web dev community could
just slow down a little and clean up their existing messes before inventing
twice as many new slightly shinier messes every funding cycle or so.

~~~
scep12
Re-inventing the wheel is often lucrative when the money's flowin' like it is
now.

------
paulhauggis
I was lucky because I started coding at 13 (Pascal and C). At that point in my
life, I could spend all of my free time developing something cool just for fun
(and learning a good foundation in the process).

By the time I got to college, new concepts took me a fraction of the time
because I already had that foundation.

Even now, I went from 10+ years of PHP development to building full Python
apps in a short amount of time. Aside from some newer features, it's mostly a
syntax change. The basics are the same in every language.

I don't think I could start from knowing nothing. I just don't have the time.

~~~
rimantas
I was also lucky that my "informatics" teacher took matters seriously and
taught me how to program without a computer. Yep, we had programming class in
school, but school did not have any computers. So she taught what basics
(variables, loops, control strucures, etc.) are on paper, using some pseudo-
programming language. Later, when I finaly got access to the computers
learning the first programming language (MSX Basic) was just a matter of
learning the syntax.

------
Eleutheria
No, it's not hard.

You can make practically any program with just four constructs: assign,
condition, loop and function.

The rest is just imagination.

~~~
rimantas
Yep, writing Harry Potter series is not hard, you can do that with a couple of
dozen of letters. The rest is just imagination.

