Programming is a practice that can be kind of deceptive in its valuation. To analogize to weightlifting, one of my favorite things to analogize against, you can see that someone lifted a lot, and you see that they did in fact lift it all by themselves, but you don't see how they get to that point, and you can't simply put on the same number of plates on the bar and hope to succeed.<p>A likewise naive path is to copy example code, do something slightly different from it, and then wonder why it's broken. You can't be really great at programming by doing that, because you're abdicating so much control to wishful thinking: "I hope this example author considered my use case!"<p>What you can do - and you probably have the guts to do it, if you're writing 30 KLOC apps on your own time - is to attack things one technique at a time, and to attack the hardest, most lasting stuff first before you get into more specialized and ephemeral knowledge like API calls. It's the adjustment of what you care about that leads you to direct your coding towards unfamiliar yet profitable roads, where you have to envision very big ideas that aren't in place yet, struggle with them for days or weeks, and ultimately find a great technique that you can reuse in the future.<p>To take one example, UI code is wonderful stuff for adding end-user value. But if you want extreme leverage in your code it can't be the first priority, because it's also stuff that tends to be thrown out frequently - because other features change, or you're on a new toolkit, or you found a slicker design. You have to instead allow the UI to be too crude at first, and think about application features as a layer apart from the UI. And then only as you come towards the end, confident that the core features are correct and will be robust against a partially-working UI, can you go back and invest in a great presentation.<p>Likewise, it's tempting to make code that is clever in-the-small, at the moment you first dip into making a new feature; to invent class hierarchies and configuration objects and generics and other nifty things. But what you need most at that moment where it's new is the most boring, plain code possible, because if you don't know the problem space yet, anything clever that might add structure or allude to generalizing the problem along any one axis is likely to do so wrongly, and the most flexible you can be is to assume it's all disposable and should be extended with copy-paste-modify. Fancy language features were made to break through problems with the crude techniques, so if you follow with that grain and only add the features after you feel pain, everything tends to go much more smoothly.<p>Most of all, it's scary to take on seemingly big problems, but it's scary in a way that should not influence your decision whether or not to attack them. These problems feel big mostly because they aren't well understood to <i>you</i>. In the same way that math students are prompted to take on gradually more ambitious levels of abstraction, you have to do the same with your code. You start with your bad assumptions and knock them out with a dash of computer science knowledge, and a lot more trial and error. There will be bugs and bad decisions along the way, but you can also learn defensive techniques against them. Some attempts to defend your code may just make it harder to write or more brittle; others will succeed dramatically. You won't know these things until you try(or get very good advice from someone who solved a similar problem to yours) because every problem domain in programming has a unique solution profile, where some things matter more than others.