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

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?<p>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.<p>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.<p>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.<p>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.<p>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.

Slow and steady wins the race.<p>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.<p>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.

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.<p>There's a way of thinking that you need to be indoctrinated to. Really get a feel for thinking this way: <a href="http://en.wikipedia.org/wiki/Black_box" rel="nofollow">http://en.wikipedia.org/wiki/Black_box</a> 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.<p>When you think this way you are "chunking" the problem. (<a href="http://en.wikipedia.org/wiki/Chunking_%28psychology%29" rel="nofollow">http://en.wikipedia.org/wiki/Chunking_%28psychology%29</a>)<p>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.

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.<p>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.

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.

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