Pragmatic 1
Download as PPT, PDF0 likes380 views
The document summarizes key chapters and concepts from the book "The Pragmatic Programmer". It emphasizes that programmers should take pride in their work, continuously learn and improve, and view problems as opportunities to find solutions rather than make excuses. It also stresses the importance of clear communication and documentation when working with others. Programmers are advised to regularly invest in expanding their knowledge through various means and to address issues promptly to prevent larger problems.
Pragmatic 1
- 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