

Ask HN: How did you get programming down pact? I am losing focus/hope. - ghettoeinstein

I have a problem with programming I just can't shake. It seems I have some mental or arbitrary conventions in my head which are preventing me from reaching my programming "aha moment" or getting the gotcha I want. A little background on me, undergraduate senior in a comp sci related field(Computer Technology, more of a sysadmin/network generalist curriculuum with minimal programming) who is seriously trying to become an adept programmer. I've ran through basic tutorials for Ruby,RoR,Python, Codecademy Tracks, took a Java course at school  and other beginner things. Through all of it, I have determined a couple things: I can pick up syntax fairly well, I can read through code and understand logic, I am not afraid of programming.<p>In my mind I have this stigma of I can't produce a "large program", or I cant forsee the paths to make my ideas about problems come to life. Sure those tried and true tutorials are good to start with, but I feel like since I have such a heavy background in computing and a natural knack for all this, I need some sort of "middleware" education material to get me to the level of abstraction to feel like a average programmer at least.<p>Its hard for me to gauge where I am at, cause I haven't gotten on the "just start coding" bandwagon, but I have irrational worries about my self-taught methods of learning.<p>Can anyone relate to what I am saying, or can attest to techniques or a path you went to get to a good feel for software development?
======
zellio
The first thing that jumps to mind is "Why are you forcing your self to do
this?". Which I won't address, but it might be something worth seriously
asking your self. If you don't like it, why are you wasting the cycles?

I find in programming, like in many creative disciplines, there isn't a
singular Aha! moment but rather a series of them. One must continuously learn
and work. The process is generally prodigious amount of toil and frustration
for brilliant moments of elation and clarity.

The ability to do large projects comes from doing large projects. You can read
all you want about project management and software design but until you are in
the thick of it, none of that matters.

I became a much more liberated and free programmer when I accepted that all of
my code is crap. In point of fact, most code is crap and in light of that I
strive not to write good code but to write better code than I did yesterday.

In short, forget about worrying. If you want an idea of organization then read
through the source of a large project. Better yet, start one. Think through
the issues that arise as you try to manage a large project. You will fail,
this is okay, good even. Learn through failure and don't invest your self in
your code. You are not your code. Be proud of your success and toil but don't
worry what others think. We were all bad programmers once and most of us still
are.

Note: This is based on my personal taste and experience. I am a professional
in the IT industry with over ten years programming experience. Not a huge
amount I guess, but definitely not that shabby. Currently I am not a
professional programmer per-say, but it makes up a large amount of my daily
work.

------
nirvanatikku
Slow and steady wins the race.

As you tackle more problems with software, you'll start to realize that
building large systems is really about understanding how to break things down.
What you're describing is akin to what I felt when graduating college (did EE,
started working in Software), but its been almost 5 years now and I realize
that the 'large programs' or complex programs, are simply built over time.
That's not to say that large programs need to be built in weeks/months, that's
all up to the dev talent that you employ, but your approach/strategy starts to
change significantly; what you currently consider challenging will become
trivial. I've also found that if the solution to a problem starts to get too
complex, you're probably stuck with technical debt or doing it wrong.

Regarding the 'aha moment' -- it isn't actually as momentous as one thinks. It
starts to become commonplace, and it's important that you don't let those
moments guide you, but instead, treat them as milestones and learn from them.
You're always going to learn, grow and craft your expertise. One thing I would
personally suggest is for you to work on problems that you enjoy (if not in
professional capacity, on the side). Also, realize that programming requires
dedication, commitment and humility. Always strive for the best, and you'll
get there.

------
adamcscott
There's lots of paths. Self-taught is the hardest, longest, path, but over
time it will pay off in some ways as you will have learned how to fix
anything.

There's a way of thinking that you need to be indoctrinated to. Really get a
feel for thinking this way: <http://en.wikipedia.org/wiki/Black_box> It's
fundamental to thinking like an engineer. All systems can be broken down into
a series of black boxes. So when you are programming you are just working on a
box at a time, no matter the size of a program or system. The entire ecosystem
(OS) of a program can be thought of this way as well.

When you think this way you are "chunking" the problem.
(<http://en.wikipedia.org/wiki/Chunking_%28psychology%29>)

The worries of being self-taught can be justified in that your are missing out
on the "culture" of the tool-builders (the compiler writers, the framework
creators, etc.) The other aspect, is you don't know what you don't know.
Successfully completing projects probably is the best help here. There's
always things to learn.

------
rachelbythebay
I didn't start trying to write large programs. I started writing really small
programs. They were things like "enter the time" (the machine didn't have a
permanent clock) and "enter the alarm time". Then it would sit there and print
the clock on screen (a TV) and when the alarm time came, it would make noise
for 5-10 seconds. Then it would go to sleep again.

I did a bunch of little things like that which seem dumb in retrospect but
probably helped me figure things out in the long run. I also wrote a bunch of
really bad medium and large programs before getting close to one which was
even kind of good.

------
spolu
Start small. Just produce something. You'll teach yourself how to handle a
large project mainly by making all the mistakes there is to make while doing
so.

------
metaphorm
large programs are collections of small programs working together. start by
writing some small programs.

