
Ask HN:  When does programming start to make sense? - amorphid
How long did it take before you could write code on your own?  Every time I try to learn programming, it feels painfully slow compared to other things I've picked up.  Maybe I'm the opposite of a natural.  I took C++ in college and studied Ruby &#38; PHP on my own.
======
10ren
Alan Turing said that programming would always be interesting because the
boring mechanical aspects could be automated (where "interesting" means "you
don't understand it" - or else you could automate it.) I daily run into issues
that I don't understand. That's what programming _is_ for me, I'm afraid;
rather like science. It's a sequence of monsters. The best we can do is to be
tackling new monsters, not the same ones.

Of course, programming jobs do exist where you do the same thing over and over
again. And there's a threshold of skill required before you can automate some
classes of things; and you also need a clear understanding of the task, to see
precisely which aspects are mechanical, and which aspects are configurable. It
pretty quickly gets into compsci research. And sometimes it's not worth the
effort (it can take a _lot_ of effort.)

But if you've ever called a method twice, instead of writing the code twice,
then you have done some of it.

I feel that your question "start to make sense" suggests your thinking is all-
or-nothing. Does _no_ aspect of programming make sense to you - or do some
"trivial" aspects make sense but they "don't count"? Does a print statement
make sense to you, to some extent? Does a loop make sense to you? There's a
continuum of mastery. If you only acknowledge perfect and complete mastery as
"mastery", then you won't feel any satisfaction in mastery of one small bit of
it. And without the confidence and encouragement of that success, it's very
hard to be motivated to continue. (oh yeah, plus, of course, it's impossible
to have perfect and complete mastery of programming anyway, for Turing's
reason.)

------
patio11
It took me a long, long time until I became reasonably confident that most
problems would eventually succumb to my programming ability. Probably almost
twenty years from when I wrote my first program, or a few years after college.

I can't write code on my own, though -- unless the problem is trivial and the
APIs I'm using I know like the back of my hand, I _need_ an Internet
connection to do it.

Part of this issue is possibly that competent people are disproportionately
stalked by the worry that they're secretly incompetent.

~~~
donaq
That is interesting. The experience has been almost the opposite for me. When
I first started programming, it did not take me long to start "getting it",
and I was very confident that there was no programming problem I could not
solve. As the years went by, I've noticed that my confidence has decreased to
the point where I am almost certain that there is no problem I _can_ solve
(besides the most trivial ones). Maybe I'm just getting dumber.

~~~
sga
Absolutely not. As you gain domain knowledge you should feel exactly this way.
I'd suggest that you be concerned if you didn't feel this way. When I finished
highschool I thought I was pretty damn smart and had a lot of things figured
out (clearly not the case). From an academic point of view as I worked towards
my Ph.D. I was constantly reminded of how very little I did know. While I did
learn new things day by day, my appreciation for how much I didn't know grew
exponentially. In fact I think what I'm left with after the whole exercise is
not a confidence in my knowledge but rather a confidence in my ability to
learn, problem solve and ask questions.

~~~
7402
"Universities are repositories of learning because students enter knowing
everything, and leave knowing nothing."

------
gagi
> Every time I try to learn programming, it feels painfully slow compared to
> other things I've picked up.

It's probably slow because you're not having fun with it. You're probably not
having fun with it because you're not solving a compelling goal. Ask yourself
whether you're learning "just to learn it" or are you trying to solve a
problem and this particular language/api/compiler/implementation will help you
achieve that goal.

I might be presumptuous here (and I apologize if I'm wrong) but the times I've
found myself stuck "learning" have been when I was just going through the
lessons for the heck of it, without a real goal in mind, without something to
accomplish.

Also, have a look at this:
[http://railstips.org/blog/archives/2010/01/12/i-have-no-
tale...](http://railstips.org/blog/archives/2010/01/12/i-have-no-talent/) I
found it inspirational.

~~~
owyn
It was no fun when I REALLY learned how to program, it was pure panic. I was
half way through a CS degree and got a summer job, and I just had get it done
no matter what so I beat my head against the problems and solved them. After
that, all the theory that I'd been learning started to make sense, and now I
have a more nuanced approach to coding, and a successful career.

Just trying to say, learning is not always fun. Get a job doing something you
don't know how to do. Maybe that will motivate you. :)

------
InclinedPlane
I cannot stress this enough: _learn refactoring_ ,
[http://www.amazon.com/Refactoring-Improving-Design-
Existing-...](http://www.amazon.com/Refactoring-Improving-Design-Existing-
Code/dp/0201485672)

You will simultaneously learn:

\- terminology and models relevant to software design and construction at
every level

\- principles of good coding and how to tell good code from bad

\- the ability to redesign code as needed

\- the experience and knowledge necessary to approach coding with confidence

All of these are the most critical tools you need to transform yourself from
someone who sorta-kinda knows a few principles of coding to someone who groks
software construction.

If I had to choose between a co-worker who truly groked the principles of re-
factoring and a co-worker who had a PhD in Computer Science I would choose the
former every time. It's really that important.

~~~
jng
I don't think that's good advice for a newbie.

To the OP: practice, practice and practice. It will take a long time. Months
to start getting it, years to go anywhere. 10+ years to be good. If it's too
hard, choose another profession. 99% of folks out there would hate
programming.

~~~
InclinedPlane
I could not disagree more, refactoring is perfect for a newbie. It's not an
advanced technique, it's fundamentals. Any beginner who can write a method can
extract a method.

But more than that, refactoring provides the mental models and the vocabulary
to talk about, reason about, and understand code. It provides well-worn expert
advice about the characteristics that make good code good and bad code bad,
heuristics to be able to recognize good and bad code, and basic techniques to
transform bad good into good safely and effectively.

There may be some advanced techniques in the book itself which won't be useful
to beginners, but that's true of any programming book, and that's easy enough
to skip over and return to later (especially with the organization of the
canonical refactoring book specifically).

A beginning programmer who has learned even the simplest of refactoring
techniques (extract method, insert/remove cached value, etc.) will be able to
look at a piece of code and see the ways it can be changed, and will also have
a reasonable idea about which changes are more likely to improve the code.
They will also have the mental models and vocabulary to talk about, reason
about, and understand the code, even if only to themselves. These tools are
hugely important for beginners. They can transform coding from a task filled
with uncertainty, fear, and irregular advancement born from experimentation to
a task filled with confidence, knowledge, and curiosity.

Certainly practice a lot, but don't just blindly stumble about on your own,
there's lots of good material out there, learn the techniques and then
practice applying them, build up your toolkit a bit at a time until you feel
more and more comfortable with coding.

------
rmorrison
For what it's worth, it took me several years before I really understood
programming. I distinctly remember thinking that I wasn't making progress, and
that I was wasting my time writing silly programs that didn't do anything
useful.

However, eventually things start to click (though it took me several years).
You'll get to a point where things make sense, and you can fathom how you'd go
about writing most of the software you use on a daily basis.

------
sunkencity
It took me about 5 minutes to get started writing code.

For some people programming can make sense, for others it's just a craft
that's in the hands. When I was at the university lots of people struggled
with "understanding" programming and they wrote little code, trying to more to
come to terms with what programming is rather than trying to do it. The people
that succeeded in learning to program wrote lots of code even though it was
hard to write the code and to understand. Some of the people that didn't never
entered their programs into computers and just ran the code by hand on a piece
of paper (to what practical use is that?).

For me programming is in the hands. When I learn a new programming language
it's total chaos for 1-2 weeks and then the new regime settles and I can
understand what I have been doing. After half a year of being exposed to a new
programming language even more of the teachings settle and I can begin
understanding more, but programming it's a practical art. I suppose it can be
different if you are more mathematically minded than I am.

I suggest doing ALL the exercises in a programming book - as fast as you can
without trying to really understand what is going on behind the scenes. The
secret is that you don't have to really understand what the hell is going on
behind the scenes, you just have to know enough to stay out of trouble and
that knowledge comes from experience. In the beginning of a programming career
it'll be impossible to guess what weird bugs might occur so just code and see
what happens.

In short, _you have to have a lot of practical knowledge of programming to
support your theoretical knowledge_ , otherwise you cannot do anything with
either. A chicken and egg situation, so it's best just to jump into the deep
waters and try to swim to the surface.

------
ajuc
I've got C64 and manual in German when I was 10 (I've only knew Polish at that
time, but who cares :)).

For a few years I only played games, and sometimes entered some example BASIC
code and tinkered with constans in code to see what will happen. I remember
that my copy of manual had error in some magic graphic system initialization
code, so I've never programmed graphic on C64. It was very frustrating.

Then I've got PC when I was 15 and I played with Turbo Basic, then Turbo
Pascal - then I've understood variables and it all started to make sense.
Since then I only feel like I know less, and less :)

PS - the most impressive thing I've seen that encuraged me to keep programming
was ASCII art adventure game written in windows batch files. I've thought - if
someon can do so much witch bat files, I can do everything with my knowledge
of Turbo Pascal :)

------
thibaut_barrere
Even once you can write code on your own, things are painful from times to
times, and I believe that's normal and a good thing.

It means you're pushing yourself out of the comfort zone, staying current.

But it's also important to detect when you should "give up" or not invest time
in something that is just too painful (I personally gave up on EJB, or
temporarily on C++ to go back to Pascal, then back to C++ a few years later).

------
csomar
Don't worry, you don't become a professional programmer in one day. It's a
long process.

I started programming (Qbasic) at the age of 12. My first programs were just
some combinations of blocks of code taken from the help document. Until 18, I
had been always an amateur programmer. Then Things changed. Programming can be
flipped from fun to work. I can get paid to have fun, so why don't do it?

I was introduced to the real world and I discovered that my knowledge, as huge
as it was (a little from everything) wouldn't really help building the
smallest application. I also can't write code on my own. I need another
application to copy from or re-use the code. My frustrations began, but they
lasted short.

I started reading books. My target was Visual C#. I read a book about .Net
fundamentals and another one about Visual Studio. I become a better
programmer. It did took me months to understand OOP, but I finished by
mastering it. And yay! I used collections.

I left Visual C# and decided to develop for the web. I planned to learn it
from scratch. From the start to the end. First, I need a strong knowledge
about the Client Side. That is HTML, CSS and JavaScript. The first two are
somewhat easy to master and learn. JavaScript is very expressive and can take
a while to master.

Actually, I felt in love with JavaScript and with it's prototypal and dynamic
nature. I'm 19 and I already built 2 scripts that I'm selling on code canyon
(I'm working on the third right now ;)) Suddenly while browsing on the web, I
found a small niche, that can be valued to $100K/year. It's hidden somewhere
and related to JavaScript. No one explored this domain (except low-quality
Open Source solutions) I made my researches, grabbed a related domain and
making a plan.

Learning Programming? Oups! I forgot about it!!!

------
CyberFonic
You need to design first - on paper, white-board, etc. You wouldn't build a
house without blueprints, so why try to write a big program without sketching
stuff out so that you can break down into manageable chunks.

If that doesn't help, then maybe you need to take a good CS course. If you
have only programmed in C++, then it doesn't sound like a comprehensive
background in CS.

~~~
jff
Exactly this. The image of the lone hacker sitting down and pouring out a
bunch of code straight from his brain is a romantic one, but if you haven't
spent a little time deciding what your data structures are going to look like
and how you're going to pass stuff around, etc., your code will be crap. "Just
coding it" leads to both frustration as you sit wondering what you should be
writing and why programming is so hard, and poor code. The poor code comes in
when you start throwing in stuff like one-use elements in your structs to keep
track of something you hadn't forseen, when a little bit of planning could
have alleviated that.

I'm certainly not saying you should go write up a design document complete
with UML and everything. That would be ridiculous, damn it I'm an engineer not
a bureaucrat! Just sit down and think (on paper) about how some of the
important stuff needs to look. It'll help a lot.

As for the second point, C++ does seem like a weird place to start. Go learn
assembly or C. Learning to write assembly is a process of continually solving
tiny programming puzzles, as you figure out how to hand-roll a loop and such.

------
wccrawford
I've been writing code 'on my own' since 4th grade. My school gave a class on
programming the Apple IIe and I loved it. My parents bought me a series of
computers, starting with a Sinclair 1000, and I wrote little programs for all
of them until they weren't good enough and we upgraded. I taught myself
several other forms of basic, then started on other languages like C, PHP and
Cold Fusion.

Maybe you need to stop 'learning' programming and just do it. Pick a task you
want to complete, possibly even a task you've done before, and just do it.

I learned all those other languages and language variants starting with the
same program: Sierpinski's Triangle. Why? Because I already knew the logic for
it inside and out and it was entertaining to watch. Every new language I came
across, I wrote another Sierpinski's Triangle program on it as my first
program.

------
ajuc
By the way, I have other problem with programming.

For some time it's not technical difficulty that prevents me from acomplishing
my programming goals, but my laziness.

I am very good at learning new languages, APIs, programming techniques, etc,
because that offers me fast positive feedback. I feel good because I've
learned sth new.

But to achieve anything I have to sit down to real, boring work, and this I am
to lazy to do. I prefer to try new cool languages than do any useful work in
languages I already know. I feel worse programmer than I was when I only knew
Basic and Turbo Pascal, no matter all the techniques, design patterns,
languages, etc, that I now know.

Do you have similiar experiences? How do you deal with this?

------
grigy
Can you explain how have you tried to learn? I have learned by books. Yes, it
took long time, but reading a good book is both fun and productive way to
learn. Unfortunately I can't recommend any of my books as they all were in
Russian.

------
rndmcnlly0
Programming, as a whole, is far larger than any one person could come to
comprehend in a single lifetime (imagine it being 1000x bigger). And to make
matters worse, it is continually growing more complex at a rate no person
could follow either!

Just when you think you've finally gotten a solid grasp on writing CRUD apps
in PHP, someone shows you Haskell, or Prolog, and suddenly realized just how
little you thought you knew.

That said, this all makes for programming being an excellent domain for both a
career and a passionate hobby. Easy to learn (a tiny corner) and hard to
master (a chunk you can really appreciate 10 years in) -- what more could you
want?

~~~
moggie
Disclaimer: I am very much a novice when it comes to any kind of programming;
I have only been working in PHP, which I know is considered a scripting
language and not a programming language, for a few months now. My
understanding is relatively limited.

"Programming, as a whole, is far larger than any one person could come to
comprehend in a single lifetime (...) And to make matters worse, it is
continually growing more complex at a rate no person could follow either!"

Isn't programming, essentially, the writing of instructions and providing them
to systems that act upon them? Reading through that statement I wonder whether
it's not _programming_ that is complex, but many problems that exist in
various fields of business or study—problems that need a programmed solution.

Please—if you don't mind—would you elaborate?

~~~
mechanical_fish
_whether it's not programming that is complex, but many problems that exist in
various fields of business or study_

Unfortunately, it's both. ;)

While PHP is indeed a programming language (the term "scripting language" is a
fairly meaningless label) when you work in PHP building web pages you're
likely to spend most of your time working on things that are computationally
tractable [1], but hard because it's just hard to translate the customer's
problems into code within the available budget. Your customer has a problem,
it's lots of work to map that problem onto code, it's hard to explain to the
customer just how much work it is to turn the "simple" activities performed by
(say) their administrative assistant into algorithms, and the result tends to
be expensive to document, deploy, and maintain. So, yeah, it's the problems
that seem to be hard, not the "programming" -- though, in fact, there is no
hard-and-fast distinction there.

But then there are problems in programming that are difficult to impossible,
all by themselves. The CS folks around here can point you at plenty of them,
but here's a famous one:

<http://en.wikipedia.org/wiki/Travelling_salesman_problem>

which is a member of an entire class of famously hard-to-compute problems:

<http://en.wikipedia.org/wiki/List_of_NP-complete_problems>

which (I believe) are not particularly rare, but which come up in various
disguises, and which must be carefully worked around.

On a somewhat more applied level, there are lots of difficult problems in code
optimization that you can work on:

<http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine>

Or you can spend your day exploring a giant set of data-storage possibilities,
each of which is right in its own way, and wrong in its own way:

<http://en.wikipedia.org/wiki/CAP_theorem>

[http://www.allthingsdistributed.com/2008/12/eventually_consi...](http://www.allthingsdistributed.com/2008/12/eventually_consistent.html)

One may suspect, of course, that this distinction I'm trying to draw between
"difficult programming" and "difficult problems" is not real; it's just a
matter of the degree of abstraction you use when describing the programming.
And I think you'd be right to suspect that. Programming is programming, and
programming is hard.

\---

[1] Though it is very, very possible to put something that is computationally
intractable into a "simple" web page. Web pages have no upper bound of
complexity.

------
skowmunk
If you really want to badly do it, then

Be patient with yourself, don't let frustration get the better of yourself,
keep trying, get immersed and give yourself some time.

For me, it took quite some time of interspersed half-hearted attempts, then
accidental and incremental opportunities to do increasingly complex tasks that
I could learn and scale (on different environments, SAP, NC, Excel Macros,
JMP), then some big time immersion over 4 weeks with David Power's books (his
style clicked for me). I am no expert now, but am doing stuff that I didnt'
think I could.

Would have to disagree about the "Natural" part of your comment. Keep working
at it.

Good luck.

------
davidw
Reading that makes me think I should call my parents and thank them again for
putting me in front of a Commodore PET at about 5. I may not be great at it,
but programming's always seemed fairly natural to me.

------
kapitalx
There are 2 aspects to programming that you might or might not be getting.
First is figuring out what the solution to your problem is, Second is to put
the solution on paper (write the program). Both of these take practice, but
the former is much harder to learn that the latter. Most programming courses
will teach you the latter. I wrote my first C program at 11, but I certainly
didn't understand what that * meant next to a variable at the time, but I
could think of the solution to the problem in terms of a program.

------
bobwaycott
I found programming a slow, grueling task until I had an ephiphany one day--
it's like learning any other [spoken] language. Now, I don't know if you're
particularly adept at picking up foreign languages, but the moment I realized
programming itself was the new language, I began viewing programming languages
through the lens of learning a new grammar or syntax or vocabulary, and
everything opened up for me. This was the same way things went with learning a
foreign language--once I understood that I was still just expressing myself
verbally, saying the same thoughts, it was only a matter of vocabulary,
grammar, and syntax.

Since then, I have picked up new languages that interest me far more rapidly.
I don't focus on how it compares to any other language I know or use. I don't
focus on it from the perspective of how classes and functions differ. I look
at any new programming language from a grammatical and syntactic view--and
once I have read enough code & documentation to understand its grammar and
syntax, I can start coding productively. That's the point I begin studying
classes, functions, built-ins, libraries--the grammar and vocabulary of
implementation.

I am by no means an expert programmer. I'd never call myself that. But I do
find that many would be better programmers if they understood the "language"
of programming. Learn as much as you can stand about data structures & types.
This is core--especially types. I have so often been frustrated by inherited
code that didn't show a solid understanding of data types (e.g., strings,
ints, arrays, etc.). Learn about classes, functions, inheritance, etc. These
are the building blocks of language, if you'll permit extending the analogy--
it's a bit like knowing how to structure a sentence, capitalize, punctuate,
etc. Learn the language of programming before you ever try to learn a
programming language. This is, perhaps, what you're missing. You're using a
programming language to understand programming. Take a step back and
understand programming itself first. Then sit back down with your language and
do programming.

Regardless of chosen language, the task is the same and the result should
(usually) be the same. The chosen language is really just an implementation
detail. You can write a program in Ruby, Python, C, PHP, etc., and it's still
going to be the same program. Most programmers, I believe, tend to choose the
grammar & syntax they like best. But the job of programming remains the same.

------
jasonkester
You're not going to like the answer, but:

Immediately.

Like in the first 5 minutes. When I was seven years old.

And frankly, if it didn't happen like that for you, you're pretty much
screwed.

Every good programmer I've ever known started doing it young and immediately
just "got it". Most mediocre programmers I know followed the path you're on,
learning it in a class in school, fighting to get things done, eventually
coming up with ways to solve particular problems, but never attaining fluency.

Try not to feel bad about it. It's just about the way your brain is wired.
Good programmers have a specific something wrong with their brain that makes
them ridiculously good at logic, and, sadly, not very good at much else. We
can overcome the "everything else" part through hard work, though we'll never
be as good at it as you. Similarly, you can overcome the programming part
through hard work, but you'll never be as good at it as us.

Sorry to be the one to break the news.

~~~
cturner

        Try not to feel bad about it. It's just about the way your brain is wired. 
    

No. I spent an entire summer staring at C and getting blocked on ridiculous
basic stuff because I had dumb learning techniques and kept being too
ambitious. I know a solid guy who did first-year C _three times_ before he
passed.

What got me through was learning to break problems up into tiny pieces,
practicing and learning patterns, and ignoring advice like "if you don't get
pointers straight away you'll never be a programmer".

For example, a pattern you use all the time is open a file, read some data,
close the file. More than half the people I've interviewed as programmers
can't do an adequate job of this from memory in their language of choice.
Practice just that until you have it memorised and can type it out at speed.

Look at programs as collections of patterns, and look for excuses to practice
dumb simple stuff (like scales in music). Something I knocked out over
breakfast on Sunday morning to price a collection of stocks: I have a file
containing a list of symbols. The program reads this data. It splits it into
tokens. It uses a yahoo web service to look up prices for them. It collects
the data in an object. I pass that to a formatter. Then I print it. I built
each pattern independently, and then stiched them together. Some people do
test-driven development to force themselves to construct software in this way,
and you might find that useful (I just do it that way without formalising the
tests).

amorphid wrote,

    
    
        Maybe I'm the opposite of a natural. 
    

I felt the same for five years _after_ I'd finished my degree. Work towards
mastering two things: (1) learn to reduce all problems to triviality. You can
use code to feel out a problem but do not ever try to cruise through
complexity - that's a path to certain failure. (2) Hone your tools (including
your memory for patterns) so that your cognitive load can be dedicated to
problems at hand rather than typing or looking up patterns for bread-and-
butter stuff like reading the contents of a file.

amorphid - I don't know what your problems are specifically but maybe some of
that will be useful.

Edit: I made a claim at the top that I couldn't reference. Removed.

~~~
jasonkester
_I spent an entire summer staring at C and getting blocked on ridiculous basic
stuff because I had dumb learning techniques and kept being too ambitious. I
know a solid guy who did first-year C three times before he passed._

Sounds like we're just using different definitions for "good". You seem to
define it as meaning competent, so yes, you and your friend fall into the
category of people who have successfully taught yourself to program computers
despite not being wired to do it.

I was talking about the Fred Brooks 10X types when I said "good". Those guys
didn't drop Comp Sci 101.

Again, please try not to take it personally. They're not better people than
you. They just took to computer programming like everybody else takes to
breathing.

~~~
thereddestruby
There's no magic wiring there - humans don't speak computer out of the womb.
Some people start programming at a younger age than others. Some move on, some
stick, some take it more seriously, some go on to become great.

It's like any other thing really. Football, Soccer, Jiujitsu, Ping-Pong, etc.

------
sethwartak
Work on something useful, something that has a goal.

Beating your head against a problem for hours is the best way to learn
something (because you learn all the ins and outs of that thing, not just the
part you were working on).

------
spooneybarger
Can you define what you mean by 'on your own'?

~~~
amorphid
Picked up a few books, wrote basic programs, etc. When it got harder, found
ways to ask people questions. I usually get frustrated when it comes to
solving puzzles that aren't linear programs.

~~~
spooneybarger
What is causing the frustration?

~~~
amorphid
I can see the solution in my head as a picture, not words. Maybe I need to
practice framing problems more.

~~~
Chris_Newton
That's interesting, and actually quite encouraging: it suggests that you do
think in terms of abstractions of the problem you're trying to solve, which is
arguably the most fundamental skill in programming. If your difficulty is that
you haven't got the mechanical process of turning your thoughts into code down
yet, that's a much easier thing to overcome.

Could you share with us what books and programming languages/tools you've been
using? While there are certainly common ideas, different types of language
take a different approaches to describing a program. Maybe whatever you've
chosen doesn't suit your way of thinking particularly well, and you would find
another tool more intuitive at this stage.

~~~
amorphid
The book I've had the most luck with is _Learning To Program_ by Chris Pine.
There's a question in the book about counting the sections of land on a
standard X,Y grid map. That would be a good example of a problem that blows up
my brain.

~~~
Chris_Newton
Which of these would you say is closest to your difficulty?

a) You don't understand what the problem means.

b) You can't describe an algorithm that would solve the problem in plain
English or "pseudocode".

c) You could describe the algorithm informally, but don't know how to code it.

