I think, many programming error will taught you to being a good programmer.
When we occur error, solved it, learned from it and practiced again and occurs error again,then solve..............again and again to become a good programmer.....
A long time ago (but not in a galaxy far away) I bought a C cross-compiler from a small company in Newcastle, in the north-east of England. I travelled up there (about a 4 hour drive each way) and spent a couple of hours while they demonstrated their products and I decided what to buy. I left with the software (on a few 5.25" floppy disks) and a few A5 ring binders with the manuals. The C compiler ran on an 8085-based Microprocessor Development System and targeted code for an 8080-based custom controller that I had built myself.
Among the manuals was a rudimentary C language reference which included a few pages of what we would now call a Style Guide. That included a sentence that, even after all these years, I can almost remember word for word: "Nothing in this section affects the way the program works and you don't have to follow any of these rules but these high-handed dicta have proved their worth time and again." Having never programmed in C before I followed the guidelines carefully and now (more than 30 years later) my coding style is still based on the same standards. I have changed little other than to add more rules in the same spirit (to suit C++ and C#) that I impose on myself with equal rigour. I subsequently discovered that some of the style in that guide is quite different from K&R and I still firmly believe that in those places K&R were wrong!
I often think about the unknown author of that guide and how much I owe to him or her. I lost those little black plastic binders a long time ago but I will never lose what their contents taught me. Thanks a million, whoever you are!
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
When I was learning OO, I found Booch and OMT very useful. There was another very good book on cue card method of OOD, but don't remember the name.
For UI design, I was really impressed by Alan Parker’s "About Face"
I picked this book up after programming for 20 years. It's a truly wonderful book about practical software design and implementation. I found it almost shocking how all of the new 'movements' in software development were all in here.
Iterative development, clean interface decoupling, etc.
While the "design pattern/pattern language" javalicious object everything approach has some gems in it.
I started to learn programming with C then switched to C++.
But it was a book about programming in Java (I cant remember the title) that was the most influential to me.
That book really showed me a power of OOP and good design patterns.
Since then I always have this nagging notion of an elegant code in my mind .
Previous -> Read "CLR via C#" by Jeffrey Ritcher.
Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder.
Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
I learned to program in assembly, the programs we wrote were for troubleshooting early IBM PCs. The two processors we wrote for were the Z80, the Intel 8080 and the 8086. I still have my Understanding Microprocessors text book from 1993 that covers the Intel processors.
I still use assembly today for Freescale (Motorola) HC08 microcontrollers.