my favorite is from Andres Taylor - number 10.

Great post, bookmarked, printet, saved.. ahh:)

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. :)

Do share Jeff - why isn't Refactoring and DP on your list?

What, you couldn't come up with 10 top 10 lists? :P

look who's trying to make it back on digg!

Believe me when I say I have no desire to be on Digg:

http://www.valleywag.com/tech/data/digg-users-like-a-pack-of-wild-dogs-231930.php

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.

Not to mention how they bring down your site. I'm a fan of http://programming.reddit.com/ these days.

... Top 10 Top 10 lists of why you're suffering from Digg "Top 10" syndrome, and how to find the Top 10 reasons why...

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.

Missing book: Concepts, Techniques and Models of Computer Programming

http://www.info.ucl.ac.be/~pvr/book.html

It's the most pedagogically sound programming book I've ever read.

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, K&R 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 K&R 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:
1. Design Patterns
2. Code Complete
3. Learning C++: A Hands on Approach by Eric Nagler:
http://portal.acm.org/citation.cfm?id=1209946&dl=GUIDE&coll=&CFID=15151515&CFTOKEN=6184618
4. Writing Effective Use Cases, by Alistair Cockburn
5. Applying UML and Patterns, by Craig Larman
6. Use Case Driven Object-Modeling with UML, Doug Rosenberg and Kendall Scott
7. Advanced Windows, by Jeffrey Richter

Books that corrupted the software industry, doing more harm than good:
1. Kernighan and Ritchie
2. Kernighan and Ritchie, the Sequel (otherwise known as The C++ Programming Language by Bjarne Stroustrup)
3. Programming Windows 95 by Charles Petzold.

Tim

7 diggs in 2 hrs.. http://digg.com/programming/Top_6_List_of_Programming_Top_10_Lists
Sorry, Jeff, but this post just might be another digg front page coming your way.

Good luck, and thanks for sharing, as usual, very valuable stuff.
F.O.R.

He's saving four more lists for a follow-up post, I know it.

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:

1. Focus on the end user. How does what you are doing help them accomplish their goals?
2. 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.
3. Learn about your system through its documentation, both writing and reading it.
4. Define your goals clearly. Put more effort into the front end of a project (design) than the back end (testing, maintenance).
5. Leverage the benefits of automation at all levels, especially automated testing.
6. Training new employees effectively is important so they can avoid beginner mistakes.
7. Quality of information is more important than quantity of information (less is more).
8. Designs should be simple, encapsulated, orthogonal, and re-usable. Put extra effort into making key parts re-usable.
9. Be systematic in your approach to all development processes, always integrating your efforts into a larger unified whole.
10. Don't re-invent the wheel. Use open-source code as the foundation for your project whereever it is available.

LaggedOnUser is almost right, but some of the items of the lists are not bogus. His list is very good, indeed!

Steve Yegge is wrong in two ways. First of all, Friedl's Mastering Regular Expressions is simple the best technical book ever written. Second, K&R second edition? The original is where it is at!

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.

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.

Tim

LaggedOnUser, that's a fine list. You should start a blog and post your list, with a little more explanation behind each item.

Just wanted to say thanks for posting wonderful articles time and time again, Jeff. Not only does your blog make my day, but so often I can use these tips in every day life.

Omar Shahine's #5: Make hard problems look easy, or Jerry Weinberg's How to treat someone with less knowledge.

Nice little daily reminders of stuff I'd forgotten :) Thanks Jeff!

Good list... thanks for posting.

ditto!

I have a list as well. However my list is more of a daily guideline.

http://www.benkruger.com/2007/02/bens-software-manifesto.html

> Software development is a kissing cousin of engineering (if not an engineering discipline itself)

ABET (http://www.abet.org/) would say it's more than just a kissing cousin, as they accredited a Software Engineering degree where I went to college. I was a Computer Engineer, myself, and based on what I heard from my friends in the Software major, the difference was they got plenty of indoctrination on "process" (read: waterfall) and "business".

I like very much the lists from Jerry Weinberg and Omar Shahine, and I think that, yes, the best book is "The Pragmatic Programmer"..

Top 10 Tips for Working at Microsoft (as a contractor)

1. You are scum
2. You are NOT part of the team
3. Everyone else is smarter than you
4. Don't believe what they tell you
5. People will not talk to you
6. Don't piss anyone off
7. Don't try to accomplish anything
8. Don't step on anyone's toes
9. Head down, fingers on keyboard
10. Don't try to fix anything

I didn't like LoggedOnUser's list. Something about it bugged me.

By LoggedOnUser's own criteria, their list is just as lame because it's so general and pretty much not specific to software development. e.g. Think of designing boxes for packaging. Everything listed is equally relevant to box building, shipbuilding, painting, secretarial work, etc. Putting in a few software centric keywords like 'open source' just doesn't cut it for me.

Let's get a list that is specific to software (or aspects of software) like (and in no particular order)

1. Code is meant to be read by people, not computers.
2. Computers are stupid. They'll do anything you tell them, even stupid things
3. The compiler is your friend, provide type-safety whenever possible.
4. Convention over configuration.
5. Don't 'gold plate'.
DO Look to the future to see how things will evolve.
DO NOT add every possible combination from the start. There is a good likelihood you are wrong, and you have wasted effort, introduced bugs, introduced dead code, and raised complexity.

Sorry LoggedIn, they are valid points, and following them would make anyone a better person, but they're not specific to what we do.