

When does learning (to code) stop being so hard? - tomasien
http://tommy.authpad.com/when-does-learning-stop-being-so-hard

======
mwexler
I do find, however, that we create increasingly complex "frameworks" in the
aim of flexibility. We then say how "simple" they are after we learn all the
complexity, and use "design patterns" and other heuristics to try to hide just
how verbose and complex the frameworks are. Modern GUIs and Web Frameworks
(and not just the Java ones that folks like to take potshots at) are great
examples of this behavior.

I worry that the moment we come up with a simple approach to something (like
HTML), we continually add features in the name of "flexibility" until we have
an unwieldy mess requiring HTML, CSS, Javascript, a framework, and various
middleware pieces to make a site. We make a new library to abstract away the
complexity, but the cycle repeats and that library is too complex, so a new
library is created on top of it to simplify.

I've been programming for years, and I still find pieces hard. And it's almost
always the dressing: the fundamental algorithm and approach can be solved, and
you think you are done... but having to deal with all the "frameworks" just to
make a site or an app becomes an exercise in pain. And those were supposed to
be the easy parts, right?

I have to admit, I do long for the days of Pilot where I could tell Turtle to
just turn left and go, and it would just do it. No windows, no nested frames,
no viewports, just describing what I wanted done and the machine does it.

(Yes, I know that modern apps, the machine-learning bayesian-based twitter
sentiment analyzer that mashes weather forecasts, stock movements and movie
ratings, parallelized and built with enterprise-grade user rights management
is a far way from drawing a rotating box... but for sake of argument, wouldn't
it be nice to just say "do it" every once in a while?)

~~~
creamyhorror
This reasonates with me. I enjoy the process of programming, even though my
exposure to it has been relatively limited (a bit of dabbling in school, and
an introductory class in college). But this year when I decided to really
plunge into the technical side of things with some friends, I found that
learning modern web technologies and actually building a Rails site was quite
challenging, because it involved a host of things that all needed to be in
place.

I went through HTML+CSS, jQuery, a bit of AngularJS, customising a few
existing javascript packages we were using, then moved on to the backend:
Linux, git, Rails, and a whole bunch of Rails gems which I had to read the
documentation for and do a good bit of Googling on. There's been a lot of
learning Rails and library APIs, finding workarounds for CSS quirks, googling
combinations of terms to find out how to achieve something, and asking my
experienced partner for help: most of this doesn't quite feel like core
"programming". I'm happy when I don't have to wrestle with a totally unhelpful
Rails error message for which Google has barely any results for (which I think
turned out to be due to some inscrutable setting), or try to evaluate the
architectural choices for modeling a set of multi-polymorphic relationships
(where the blogposts present models with different capabilities and I don't
know enough to tell what will really be useful in future).

Maybe I tried to bite off far more than I could chew, I don't know. I guess
the trouble is that so much of web development relies on the use of
prepackaged tools that the ramp-up learning curve is significantly more
challenging than merely learning a single language's vocabulary. As a relative
beginner (albeit with prior exposure to programming concepts), it look longer
than I expected to get to my current point. Web development isn't just
programming, it involves learning a new environment, a whole set of concepts
and issues, and a toolbox that just grows and grows and grows...I've started
storing my knowledge in a Freemind mindmap just to keep track of it all. I
even save my IRC chatlogs whenever I manage to get advice. (If I had a more
experienced partner to pair-program with, things would probably go a lot
faster, but I'm mostly on my own.)

Now I'm looking at websocket libraries and other nodeJS frameworks like
DerbyJS and Meteor for new functionality, and it's analysis paralysis all over
again. It never ends for a beginner...I miss programming simple stuff.

~~~
bbwharris
> It never ends for a beginner...I miss programming simple stuff.

It never ends for a programmer. Constant learning and reinventing is what
defines us. It gets easier to pick up new stuff, but you never end the process
of picking up new stuff.

------
dasil003
I started programming pretty young. AppleSoft BASIC at age 9 or 10. Initially
just transcribing programs from hobbyist magazines, but then writing my own
programs and branching out into lower and higher-level languages (assembly and
HyperTalk). While it definitely had a magnetic attraction to me, I found it
difficult to learn (my first internet connection was a few years away, the web
even further) and I was always learning by rote.

I still remember a distinct moment when I was 20 or so that everything
magically clicked into place in my mind. Suddenly I grokked the nature of
abstraction and what it meant to translate a mental model into a computer
program irrespective of the underlying language. Trying to put it into words
always sounds trite, and it's not as if I was magically a better
programmer—more like the beginning of a journey, but it was a clear point
where I feel like I crossed the steep part of the learning curve, and it was
all downhill (at least on the first derivative) from there. I'm not sure if
anyone else has ever experienced it this way, I suspect this type of
(seemingly) grand epiphany is more likely to happen when you're younger and
the brain is more plastic, or maybe I just took too much LSD. In any case, I'm
convinced programming belongs to a class of skills (perhaps music is another)
that require some higher level foundational concepts that do not occur
naturally in most common human experience.

~~~
Derbasti
I had a similar reaction after working through SICP. Suddenly, I gained a new
understanding of programming. I knew it would take a lot of time and practice
to actually make use of that knowledge.

But funny enough, I find your description extremely accurate: I suddenly
grokked the nature of abstraction, a beginning of a journey.

~~~
dasil003
I also was reading SICP for my Scheme class at (or near) that time as well.
Fascinating. I'm really sad MIT discontinued its use for the introductory
course.

~~~
Derbasti
Actually, I preferred the video lectures to the book. Still, if I charted all
my learning of programming stuff over all time, the time during which I
watched SICP will without a doubt be a huge spike in the first derivative.

------
unoti
My dance instructor says that learning to dance goes in three phases that
spell MAP: Memorize, Automate, Personalize. First you just memorize the steps
and walk through them. Then you get to where you can do the steps without
thinking about them. Then you get to where you're able to add some personal
flair.

For me when learning a new programming language, I find that I move through
three important phases. First I'm copying what other people are doing and
consulting books and manuals constantly for everything I do. After a while I'm
consulting other things I've done myself and imitating those. Then finally I
get to where I'm not consulting anything and the code is just flowing, often
with my own interesting twists.

Incidentally, feeling like it's too hard for you and that you're not smart
enough just goes with the territory. Also try to ignore the temptation to feel
like it is all very easy for everyone else. I find that the feeling of failure
is often its worst right before I make a breakthrough. After about the fifth
time of thinking this is too hard for me, I can't do it, then doing it, I
realized this is a pattern for me and learned to ignore the feeling of it
being too hard.

------
CodeCube
As others have said, there will come a time which is probably unique for
everyone, where things will "click". But a friend of mine had some good
insight the other day. We were talking about complexity in software and why at
times things seem so difficult. He said it's like when you start working out.
You can only lift so much weight until your muscles give out. But eventually
you keep working at it and increase the amount of weight you are lifting ...
so although it will become way easier to lift the amount of weight you were
lifting when you started, you will continue working just as hard to lift your
current limit. And that's why software will always seem hard, because we build
upon our past knowledge and learn to tackle more and more difficult things.

------
steve918
In about 10 years <http://norvig.com/21-days.html>

------
orangethirty
For me was when I stopped learning inflexible languages. LISP was an eye
opener in regard to how flexibility in a language will make things a breeze. I
can do anything with it, no need to hammer my ideas into a language. To this
day, the only language I _enjoy_ writing is LISP. Its just fun.

~~~
Derbasti
I so wish I could use some LISP at work!

~~~
orangethirty
We are building a search engine with it (nuuton.com). Shoot me an email. I'm
looking for feedback from experienced lispers. :)

~~~
Derbasti
Ah, well, I wish I was experienced in LISP ;-)

------
tomasien
In case anyone wants details on what I'm doing:

I started by learning Javascript and found I could understand the concepts and
syntax/logic easily enough to have intelligent conversations about strategy
with my cofounders, even enough to help with brain locks they had, but found
it a little hard to solve my own problems.

After learning Python for a couple of weeks, I found that problem disappeared.
With Python, I can just THINK and then write what I'm thinking, which is a
huge upgrade for a newbie like me.

I'm going to stick with learning design (including JQuery stuff, which I
didn't mention but I have already learned and actually implemented to some
extent) and Python to attempt to limit the scope of my learning in order to
progress faster toward some degree of mastery.

~~~
KirinDave
I think your attitude is amazing, and I wish more people had it. Keep at it!

But here is a fair warning: this stuff is hard because it's genuinely tricky.
Computers are unforgiving in a way the human mind can never be. So be warned:
there are other walls like the one you just vaulted over, and the other side
of them is worth reaching. But, it will feel like what you just experienced
all over again.

One famous wall that my college used to weed out upper and lower division
students at UCSB was pointers. Recursion also really shocks some people. Some
people get really distracted by the high level modeling that gets used to
build systems. Some people have a really hard time learning how to incorporate
how the computer _actually works_ into their programming model.

I don't mean to discourage you! I mean to say that you are not alone. Many
people find this stuff hard and work diligently to learn it throughout their
careers. It's a fact often lost due to the culture of dominance and bravado
that the computer science world has grown.

~~~
tomasien
Thanks so much for the words! Everything along the way I struggle with how
exactly to implement it in my mental logic model and actually recall it when
needed, but once I can do that that individual element becomes much easier.
That's how I originally thought of "when will this get easy" until I realized
what I meant by easy: when will I just want to do this more than occasionally,
when will I ENJOY it.

That's when I realized the answer. It will never be "easy" in the sense that
learning these new elements will always be difficult in a way, but there will
come and already is starting to come a time when I can do it in a way that
fulfills me instantly when I'm doing it.

------
jorgeleo
Short version:

Things stop being hard when I know enough so immediate satisfaction is
possible. Then things seem easy.

+1 for self awareness progress.

~~~
tomasien
NAILED the tl/dr

~~~
jorgeleo
Thank you. I think those are very good and important first steps.

Keep in mind:

1\. We are not scientist. We do not use the scientific method to discover what
is already out there. Our creations didn't exist before we write them

2\. We are not engineers. Our creations are not bound by what science
discovers. In some rare cases they might be a requirement, but never a bind.
This is a curse and a blessing

3\. We are closer to a mathematician painter. Not because we use math (this is
irrelevant for this definition), but because we think in symbolic terms which
is the essence of mathematics (btw. this makes arguable that ip over
algorithms is like ip over colors)

4\. Society is being build on top of it... and "they" are not very aware of it
yet

~~~
Derbasti
This got me thinking (thank you for that): Are we not engineers since our
solution space is bounded by the architecture we run on (hardware and
software), which in turns has been constructed by engineers who were limited
by scientific discovery?

By the way, I totally agree with you, but by your definition the above seems
like a logical conclusion to me.

~~~
jorgeleo
Yes, this remind me what one of my teachers used to say: hardware is what you
kick when the software does not work.

I don't believe that our solution space is limited by the hardware we run it
on because our solution can be intended to run in different hardware, and when
its adecuate enought it should produce the same results.

Lets take math as an example.

Lets say the axiom a + b = b + a

We know that the expression is true in its essence, regardless the alphabet
that we used to expressed. One can argue that ths expression does not makes
sense to a chinesse personon because the chinesse alphabet does not have the
letters 'a' or 'b'.

But we know that if we use valid chinesse letters, then the concept is still
true.

You see? Is the concept that we express what remains valid, not the symbols
that we use to express them. And this allows us to talk about commuting
regardless of the language. The symbols are used to communicate an idea that
is beyond the meaning of the particular symbol

Same thing with software. Software development is not about the computer that
it runs on anymore than astronomy is not about a particular telescope. Thus we
need to separate the software solution from its implementation environment.
The software is not bound by the architecture, a particular implementation is
bounded by the hardware architecture and the ability to think out of the box
of the developer; but the software it self it isn't (which is why we can do
things like calculate the big O, which is hardware independent)

Like in math, a particular implementation is just one way to express that
software on that hardware using a particular programming language. For a
different hardware (chinesse) you will use a different implementation for the
same software concept.

I cannot address how or why is the logical conclusion for you, but I can tell
that it is not for me.

~~~
csense
The principle you're trying to articulate is the Church-Turing thesis [1]:
Every reasonable definition of computation can compute the same set of
functions. [2] [3]

[1] <http://en.wikipedia.org/wiki/Church-Turing_thesis>

[2] Quantum computing may change the O() of some functions. I.e. maybe some
O(n^2) problems become O(n) with a quantum computer, or NP problems become P;
I'm not familiar enough with quantum computation to know for sure which
classes are known to be reduced to smaller classes. But in principle you can
always simulate a quantum computer on a classical computer given enough time
-- of course, in practice "enough time" may be many orders of magnitude out of
the realm of possibility. So quantum computation isn't a "new" form of
computation as far as the Church-Turing thesis is concerned.

[3] There are purely theoretical machines called "oracle machines" -- exactly
like a regular computer/Turing machine, but equipped with a (theoretical)
hardware device called an "oracle" which is able to solve some problem that is
known to be impossible for Turing machines, like the halting problem [4]. An
oracle machine can be more powerful than a Turing machine, but its violation
of the Church-Turing hypothesis is sort of a technicality.

Saying "Build magic hardware that does something a Turing machine can't, and
attach it to a computer" is too vague about how the non-Turing computation is
to be achieved to really constitute a fair definition of non-Turing
computation.

[4] <http://en.wikipedia.org/wiki/Halting_problem>

~~~
jorgeleo
Cool! Thank you for the links, I didn't know that it had a name, mine were
just mere observation.

To me it stand to logic that different hardware has different capabilities,
and if an implementation can use these characteristics then the implementation
can have a different O. But my point still remains that as a theorical
concept, the O does not depends of the hardware in the sense that it is not a
necessary piece of information to make the calculation of O.

Also i would like to point that in my original definition the math paint has a
purpose of utility for society. To build magic hardware would be like telling
Picasso here is infinite canvas and infinite degree of colors, what can you do
with them? The magic is not in the resources or the tools, the magic is in
thinking independent of those tools, and then using the tools to implement. I
understand that people might come from the other end of the spectrum and think
that we need to begin with the tools, i just don't share that view, and it has
worked for me just fine.

------
tehwebguy
For me it was a long progression of specific moments.

I remember understanding the DOM for the first time, understanding server side
code for the first time, chaining methods, JOINs, scope, regexp, MVC, a lot of
individual things.

My most practical advice is that you ignore hot new frameworks and languages
for now and stick to what you know until you know it much better.

But, as soon as you feel comfortable with what you're doing you should take
the next step.

------
danielwozniak
Just keep coding and, as important, read other people's code. Keep doing it.
If your coding in python, read the standard library. That, my friend, is one
of the beautiful things about open source. One day the coding will be easy and
the problems your trying to solve will be hard. Thats a good day IMO.

~~~
tomasien
Absolutely! Great advice. I write code every day, but reading other people's
code and seeing how THEY solve the problems probably helps me more than
anything.

------
abhimir
Having gone from a non-technical co-founder in my last startup to a technical
co-founder in my current startup, I could identify with your post, so much so
that it was almost like I had written it myself. Also last few months I have
always been frustrated with the slow speed at which I write code as compared
to others. And that sometimes makes it hard to enjoy the process when the time
difference between when you think of a new feature and when you actually see
it working in front of you, is large. But now next time I am feeling
frustrated I will think of this blog, grit my teeth and just carry on.

------
throwit1979
Software development, particularly in imperative languages, is as intuitive as
it gets. Things like algorithmic complexity analysis, distributed and parallel
systems engineering, fault tolerance, cache invalidation and prediction, etc,
can become fairly complex. But building a hobbyist project as simplistic as it
sounds like the author is building? Easy and intuitive.

I'm really getting tired of this "programming is hard" meme. It's not.

~~~
nlh
I'm sorry for the ad hominim, but this view is extremely myopic.

Maybe programming is not hard -- for you. Maybe software development is "as
intuitive as it gets" -- for you. But that is an extreme generalization that's
simply not fair.

Programming is not trivial and something that everyone should by definition be
able to intuit. It requires a very specific and logical way of thinking. It
requires intellect. It requires practice. I'd venture to guess that a vast
majority of people out there couldn't "just figure it out".

Programming requires interest, practice, intellect and a very specific way of
thinking. It can be taught, it can be learned, and it can even be mastered
with enough effort (by some people). But let's not dismiss the hard work of
the OP and of the many people out there trying to learn (or, frankly, failing
to learn) by calling it intuitive and easy.

~~~
UnFleshedOne
Maybe "as intuitive as it gets" means "as intuitive as it can be"? There is
innate complexity there somewhere. Can't say if we've necessarily reached it
though.

------
RyanMcGreal
Interestingly, I've long thought that Python is like the piano of programming
languages. It takes almost no time to learn how to play Three Blind Mice, but
an expert user can also play Rachmaninov.

------
davidddavidson
You should fix the links on your blog. All of them except for the HN
discussion link have tommy.authpad.com prepended to them.

~~~
tomasien
FIXED thanks!

~~~
marme
also you are hotlinking some of your images from imgur, this is a big web
design no-no. You dont control the host of those images and at some point they
will expire leaving broken images on your page, this is best case scenario.
The worse case is if the host you are hotlinking finds out what you are doing
and changes all the images to some grouse pics to teach you a lesson. imgur is
good image host so they would not do that but the problem still is if imgur
goes down you can do nothing but twiddle your thumbs until they come back

~~~
tomasien
Oh I know! Thank you so much for that input. I was really hesitant about
posting that link because I don't actually use that site. I'm re-designing it
now for what I actually do consulting for (healthcare, hiring, and biz dev for
companies that build software and have trouble with sales)

That was just quick and dirty

------
doug1001
if it's done right, it's never easy. But it can be and indeed should be fun.

------
danso
How useful is it for adults to start off by making even simple games? Simple
games have no practical use beside the learning in itself. Even worse, making
a game requires spending attention on entirely orthogonal concepts (such as,
what text should greete the user?) when beginners need to focus on the pure
code concept.

If you're intending to be a tech startup, why don't you code something useful
for yourself, like something that turns an excel spreadsheet into HTML tabular
data.

~~~
csense
> Simple games have no practical use beside the learning in itself.

I disagree. Games are a great starting point. Creating your own world where
the user can immerse themselves and make a variety of choices is way more fun,
on a visceral level, than converting Fahrenheit to Celsius or using jQuery to
put a few special effects on your website.

That fun is part of a reward feedback psychological loop which helps get you
motivated, and the motivation helps you study harder and get past frustration.
So the positive effect on the learning process may be large enough to justify
such an "impractical" application.

> games have no practical use

Let's not forget that computer/video games are a large, visible and highly
successful part of the entertainment industry that essentially didn't exist
before the computer era. We could also say that art, music, movies and fiction
"have no practical use" -- but a large segment of humanity still finds them
compelling enough to spend enormous amounts of time, money and other resources
creating and consuming, and these things are widely considered to be a core
part of what makes us human.

> beginners need to focus on the pure code concept

Depends on the person. I would argue that many people learn better when they
can apply their learning to a non-trivial problem. This is why introductory
university science courses have labs. This is why classes at all levels have
large projects in addition to the tiny problems on homework and exams. In
fact, an _inability_ to apply your learning to a non-trivial project implies
that the learning process is incomplete.

> requires spending attention on entirely orthogonal concepts

Most projects in the modern world require interfacing multiple languages,
libraries and API's. Any web app, for example, will likely have -- at minimum!
-- parts in HTML, JS, CSS, database, backend language, and a template engine.
That's six orthogonal components.

If you're going to be dealing with multiple orthogonal concepts in the "real
world" of programming, the "academic world" of programming (whether a formal
college curriculum or just self-learning) would be remiss if it didn't give
you some preparation for that aspect through exposure to projects involving
integrating different technologies.

Even single-language projects involving only core libraries often require
putting together different API's (for example, many applications can be
roughly divided into dealing with files, dealing with a user interface, and
internal core functionality.) In fact, _not_ being able to modularize a large
problem into manageable pieces that mostly treat other pieces as black boxes
is a recipe for failure of any and all attempts at large projects.

~~~
danso
I don't disagree with just about any point you made...my point is that I don't
think simple games...and for that matter, any kind of web app, is a great way
to start learning to code because of what you said.

While you will have to learn multiple API's and libraries to do anything
money-generating, I think it's not an efficient route when first learning
programming...why not do a simple project that will be immediately useful to
you as soon you complete it?

