1 / 12

The Pragmatic Programmer I

The Pragmatic Programmer I. 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

geoff
Download Presentation

The Pragmatic Programmer I

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related