Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

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!"

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.

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.

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.

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

[Most likely] it is not that they got it right, right from the start. These 'awesome' programmers would have spent weeks before getting it right. These classify as throw away experiments and they keep at it till it satisfies their own internal target of what the solution should be like till it is right.

The best parameter of that right could be say the simplicity of the overall internal implementation and the exposed external API.

Now I am not saying that there are not geniuses around, but even if they are getting it right, it will still be backed by countless hours of hard work and practice.

Most likely asking these awesome programmers how they are getting it right, will throw some more light.