Presented, in no particular order, for your reading pleasure: my top 6 list of programming top 10 lists. To keep this entry concise, I've only quoted a brief summary of each item. If any of these sound interesting to you, I encourage you to click through and read the original author's thoughts in more detail.
I don’t know if it is a personal flaw, but reading those lists’s from experienced developers makes more sense now that they would do 10 years ago. You can read a lot and get some guidance but you still need to experience all the good and the bad stuff yourself to truly understand it. Stuff like “… you WILL make mistakes” really makes more sense after a few mistakes.
Traffic and exposure is nice, but Digg is increasingly becoming a least common denominator experience, full of drive-by rubbernecking users clicking their way from one 3.6 second thrill to another.
Great lists, this post gets Google Reader Starred status from me.
My favorite is the first list and the first item on that one in particular. Mistakes are to be expected. Hopefully you make them early and often since they cost you so much more to fix the later in the development cycle you find them. #5 on that same list is good as well. I try to think about that one any time I’m talking to someone with a marketing degree and no programming background.
I concur with Peter too. These lists make a lot more sense to me now than they would have when I graduated in '93. Is that because I personally know more or because the software development industry at large knows more? Probably a mix of both.
In a weird moment of deja vu, two of the 10 on the book list were college textbooks of mine (UCSD '88-'93, yes it took me 5 years and I’m still explaining that to my mother). Compilers rules. I learned more in that class than any other I ever took.
I can’t accept as reasonable any top 10 list of books that includes Kernighan and Ritchie’s “The C Programming Language”. That is probably the worst textbook in the history of programming. All the stupid little “cutesy” tricks that programmers insert into C code - you know, all those ones that insert bugs while trying to safe a few processor cycles via pointer arithmetic and all those cutesy tricks using the “never use operator” (a.k.a.: the ternary operator) and other horrendous examples of code all come from that book. Singlehandedly, it tainted C programming for years (and probably still does). Rather than teach how to create readable code, KR seemed more interested in teaching how to obfuscate code. I was forced to use that to teach a C course one time and I spent half my time explaining to people why the cryptic examples they were pulling from KR were a sure-fire way to win you enemies in any software development project.
As for regular expressions, the best quote I’ve ever heard about regular expressions and the reason why I would never include a regular expression book in any “top 10 list” I put together is:
“Some people, when confronted with a problem, think “I know, I’ll use regular expressions”. Now they have two problems”. Jamie Zawinski (in comp.lang.emacs)
My top 7 computing books (because I’m too old and tired to remember 10) would be:
I thought those lists were bogus. A bunch of shallow generalities and airy nonsense. Since I thought I could do better, here is my top ten list of development tips:
Focus on the end user. How does what you are doing help them accomplish their goals?
Technology is a means, not an end. Don’t be dazzled by the baseless hype and unproven claims which constitutes about 90% of all software writing.
Learn about your system through its documentation, both writing and reading it.
Define your goals clearly. Put more effort into the front end of a project (design) than the back end (testing, maintenance).
Leverage the benefits of automation at all levels, especially automated testing.
Training new employees effectively is important so they can avoid beginner mistakes.
Quality of information is more important than quantity of information (less is more).
Designs should be simple, encapsulated, orthogonal, and re-usable. Put extra effort into making key parts re-usable.
Be systematic in your approach to all development processes, always integrating your efforts into a larger unified whole.
Don’t re-invent the wheel. Use open-source code as the foundation for your project whereever it is available.
Steve Yegge is wrong in two ways. First of all, Friedl’s Mastering Regular Expressions is simple the best technical book ever written. Second, KR second edition? The original is where it is at!
I think LaggedOnUser’s list is great. Too much emphasis in the software industry is put on technology, programming, code tools and the “Code Cowboy”. I might disagree with the open source list item because I think it can be taken too far but I’ll give LaggedOn the benefit of the doubt about the extremes or lack thereof he was professing with that statement.
Building quality software involves building software that the user wants to use and does what the user wants to do and only that. Extra bells and whistles that are not asked for or needed simply provide avenues for more bugs to be inserted.
The most valuable people in a software team are seldom (or, more accurately, almost never) the Code Cowboys and the Code Gurus. The most valuable people on a software team are almost always the communicators and the abstract thinkers - those who can convert the user’s needs into technical jargon and vice versa.
I found many things in the list is apt to the project I am currently working. The top 10 Commandments stands the Best in the Top 6.
“You are Not your Code” - People and Code are different. - The Best.