The Pragmatic Programmer I

1. The Pragmatic Programmer I

2. About the textbook • The Pragmatic Programmer is full of helpful suggestions for surviving programming • It’s also enjoyably written • I’ll cover in class some of the material in this book • Mostly those things that I want to emphasize, or where I think I have something to say • I’ll feel free to test on all of the material • Current assignment: Read the Preface and Chapter 1

3. 1: Care about your craft • Take pride in your work • If you don’t enjoy your profession, you’ll never be great in it • If you do enjoy your work, you’ll also enjoy the process of getting better at it (mostly!) • In computer science, learning never ends!

4. Egoless programming • Some years ago, Gerald Weinberg coined the term egoless programming: • Software belongs to the organization, not the individual • You don’t “own” your code • The idea is that if you have an emotional interest in your code, you will resist criticism • I strongly disagree—it’s important to take pride in your work • But also realize that every program can be improved • Don’t take criticism of your program as personal criticism

5. 2: Think! About your work • Always be asking yourself: is there a better way to do this? • A better design, a better language, a better layout • A better job? • Always be critical of your own work • Always be ready to accept criticism—no program is ever perfect • If you ever think you “know enough,” you’re stagnant—and it’s time to do something else

6. Any program can be improved • There are few, if any, perfect programs • Always be ready to rewrite your program to make it better • But know when to stop! • Rewriting and re-designing your program is sometimes called refactoring

7. 3: Provide options, don’t make lame excuses • Some things can’t be done on time, others can’t be done at all • Don’t focus on what cannot be done • Concentrate on what can be done instead • Find solutions to problems • In “The War Against the Chtorr,” David Gerrold distinguishes between “guests” and “hosts” • A “host” does whatever needs to be done • A “guest” figures that it’s someone else’s job

8. 4: Don’t live with broken windows • If something is wrong, fix it • If you can’t get to it immediately, at least mark it for future work • Take some action to prevent further damage • Small problems accumulate and turn your code into crap • The law of entropy: • A spoonful of wine in a barrel of sewage gives you a barrel of sewage • A spoonful of sewage in a barrel of wine gives you a barrel of sewage

9. 8: Invest regularly in your knowledge portfolio • Learn at least one new language every year • Read a technical book each quarter • Read nontechnical books, too • Take classes • Participate in local user groups • Experiment with different environments • Stay current • Get wired

10. 10: It’s both what you say and the way you say it • Communication is important—more important than programming itself • How you present your program usually matters more than how good your program is • Make it look good • Use spell checkers • Learn something about good design • Good communication (and documentation) is essential for working in a team • Every piece of e-mail is a permanent record

11. More about the book • Chapter I deals mainly with philosophy—how you should approach the task of programming • Later chapters get into more technical detail • However, if you don’t strive to be the best you can possibly be, those chapters won’t help you any

12. The End