A book called "The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt and David Thomas promises to "cut through the increasing specialization and technicalities of modern software development to examine the core process--taking a requirement and producing working, maintainable code that delights its users."
Pragmatism is a school of epistemology. Most of the thinkers who describe themselves as pragmatists consider practical consequences or real effects to be vital components of both meaning and truth. In ordinary usage, pragmatism refers to behavior which temporarily sets aside one ideal to pursue a lesser, more achievable ideal. It is difficult to determine what ideal the authors are setting aside in order to achieve their programming goals, however their list of tips (sample shown below) looks interesting. The Stroop effect is also kind of neat. See also Jon Aquino's blog post for his explanation of the benefits of reading code aloud.
Extracted From The Pragmatic Programmer
by Andrew Hunt and David Thomas.
Copyright 2000, Addison Wesley.
- Care About Your Craft. Why spend your life developing software unless you care about doing it well?
- Always Use Source Code Control. Source code control is a time machine for your work---you can go back.
- Use Blackboards to Coordinate Workflow. Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
- Estimate the Order of Your Algorithms. Get a feel for how long things are likely to take before you write code.
- Some Things Are Better Done than Described. Don't fall into the specification spiral---at some point you need to start coding.
- Costly Tools Don't Produce Better Designs. Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.
- Invest Regularly in Your Knowledge Portfolio. Make learning a habit.
- Separate Views from Models. Gain flexibility at low cost by designing your application in terms of models and views.
- Work with a User to Think Like a User. It's the best way to gain insight into how the system will really be used.
- Don't Be a Slave to Formal Methods. Don't blindly adopt any technique without putting it into the context of your development practices and capabilities.
- Sign Your Work. Craftsmen of an earlier age were proud to sign their work. You should be, too.