Top Rules for Programming
March 22, 2007
Presented, in no particular order, for your reading pleasure: my Top Rules for Programming. 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
Compilers
WikiWikiWeb
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.
March 22, 2007
Presented, in no particular order, for your reading pleasure: my Top Rules for Programming. 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
Compilers
WikiWikiWeb
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.
No comments:
Post a Comment