March 22, 2007
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.
Jerry Weinberg: The 10 Commandments of Egoless Programming
- Understand and accept that you will make mistakes.
- You are not your code.
- No matter how much "karate" you know, someone else will always know more.
- Don't rewrite code without consultation.
- Treat people who know less than you with respect, deference, and patience.
- The only constant in the world is change.
- The only true authority stems from knowledge, not from position.
- Fight for what you believe, but gracefully accept defeat.
- Don't be "the guy in the room."
- Critique code instead of people -- be kind to the coder, not to the code.
Dare Obasanjo: Top 10 Signs Your Software Project is Doomed
- Trying to do too much in the first version.
- Taking a major dependency on unproven technology.
- Competing with an existing internal project that is either a cash cow or has powerful backers.
- The team is understaffed.
- "Complex problems require complex solutions".
- Schedule Chicken
- Scope Creep
- Second System Syndrome
- No Entrance Strategy.
- Tackling a problem you don't know how to solve.
Omar Shahine: Top 10 Tips for Working at Microsoft (or Anywhere Else)
- Process is no substitute for thinking.
- Get out of your office.
- Use your product (the one your customers will).
- Fix things that are broken rather than complain about them being broken. Actions speak better than your complaining.
- Make hard problem look easy. Don't make easy problems look hard.
- Use the right communication tool for the job.
- Learn to make mistakes.
- Keep things simple.
- Add value all the time.
- Use their product.
Michael McDonough: The Top 10 Things They Never Taught Me in Design School
- Talent is one-third of the success equation.
- 95 percent of any creative profession is shit work.
- If everything is equally important, then nothing is very important.
- Don't over-think a problem.
- Start with what you know; then remove the unknowns.
- Don't forget your goal.
- When you throw your weight around, you usually fall off balance.
- The road to hell is paved with good intentions; or, no good deed goes unpunished.
- It all comes down to output.
- The rest of the world counts.
Andres Taylor: Top 10 Things Ten Years of Professional Software Development Has Taught Me
- Object orientation is much harder than you think.
- The difficult part of software development is communication.
- Learn to say no.
- If everything is equally important, then nothing is important.
- Don't over-think a problem.
- Dive really deep into something, but don't get hung up.
- Learn about the other parts of the software development machine.
- Your colleagues are your best teachers.
- It all comes down to working software.
- Some people are assholes.
Steve Yegge: 10 Great Books
- The Pragmatic Programmer: From Journeyman to Master
- Refactoring: Improving the Design of Existing Code
- Design Patterns
- Concurrent Programming in Java(TM): Design Principles and Pattern (2nd Edition)
- Mastering Regular Expressions, 2nd Edition
- The Algorithm Design Manual
- The C Programming Language, Second Edition
- The Little Schemer
You may wonder why I included a top 10 list from someone who is clearly a designer and not a programmer. I agree with Joey deVilla:
Software development is a kissing cousin of engineering (if not an engineering discipline itself), and blends creativity with math and science. That's why I find that a lot of advice to creative types is also applicable to software developers.
You may also want to contrast and compare my recommended reading list with Steve Yegge's. And yes, there is a reason Refactoring and Design Patterns aren't on my list, just as I'm sure there's a reason Code Complete is not on Steve's list.
Posted by Jeff Atwood
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!
... 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.
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:
1. Design Patterns
2. Code Complete
3. Learning C++: A Hands on Approach by Eric Nagler:
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.
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, 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.
LaggedOnUser, that's a fine list. You should start a blog and post your list, with a little more explanation behind each item.
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.
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.
Software development is a kissing cousin of engineering (if not an engineering discipline itself)
ABET (a href="http://www.abet.org/"http://www.abet.org//a) 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".
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 like very much the lists from Jerry Weinberg and Omar Shahine, and I think that, yes, the best book is "The Pragmatic Programmer"..
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.
I does want to now about this topic
Ohiit did you post the same comment on the other blog that you're referring to? The mere fact that this post from Jeff is dated more than a year prior to the other one says a lot.
Very Good Tips and Ideas, Thanks a lot for sharing :)
But Number 10 from Andres Taylor is just so Funny...
hahahaha... and true... hahahaha
Must read by all programmers