Great coders will run into walls all the time. One of my favorite quotes is one by Randy Pausch (author of Last Lecture): "I believe brick walls are there for a reason. They're not there to keep us out. They are there to give us a chance to show how badly we want something."
Keep that in mind when you're hacking, as you are bound to run into problems. Just roll and keep persevering.
- http://norvig.com/21-days.html - http://catb.org/~esr/faqs/hacker-howto.html - http://paulgraham.com/gh.html (More Than Money)
He'll program in such a way that he can debug the hard bugs.
I'm passionate about becoming a great hacker and I'm regularly trying to improve my skills in both hardware and software hacking (20/80 split at the moment).
My main issue is that I require a lot of structure in terms of the way that I learn, to deal with this I've borrowed "Programming Interview Explained" [ http://www.amazon.com/Programming-Interviews-Exposed-Secrets... ] from a friend. It's a fairly short book but outlines what knowledge would be requisite for getting a job at Microsoft back in the early 2000s.
I'm going through the book and finding out what knowledge areas are currently lacking and supplementing them with books which are considered to be good for that specific subset of computing. E.g. I found out I was terrible at bit manipulation, so I've bought "Hacker's Delight" [ http://www.hackersdelight.org/ ], which is helping in both my software knowledge and hardware knowledge.
I figure that this method of learning will likely take me over a year if I limit the supplementing books to just 1 or 2 at most. After that I can go through it again, covering all of the topics that I thought I knew well enough to make sure my knowledge is all up to scratch.
TL;DR Persistance is key if you want to gain domain knowledge in your field. I'm taking a backwards approach and using a book to define my learning path.
1) Don't accept the status quo, when you see/imagine a better way.
Become a good hacker:
2) Exercise discretion and consideration. Assume you might (will) break stuff -- important stuff -- and design with adequate defenses in mind and demonstrated.
Next step?
3) Recognize where and how much risk is present. Don't over-engineer where the cost/benefit leaves it unwarranted or where it is outright counter-productive.
You're going to make mistakes at each step. It's a learning process.