- Taking Responsibility
- Applying Feedback
- Pragmatic Environment
- Coding Techniques
- Sign Your Work
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Applying Feedback
Feedback is one of those words we use a lot. When we let loose the battle cry of "Feedback!" we mean that you must never begin any task without knowing how to tell you're done. Any task? We're just talking about coding stuff here, right? No, not just coding. We're talking about planning for feedback at all levels, from writing a line of code, to project and process management, all the way up to ensuring client satisfaction. Without feedback, how could you ever know that the code was right? Or how could you tell that the client is satisfied? While some may disagree with us, "the check clears" is not an adequate indication that the client is happy.
For instance, you can tell that code performs as you expect by writing a unit test that matches your expectations, whether it's in terms of testing output for certain values, or completing a task within a certain amount of time, or whatever else. Unit tests allow you to prove it, rather than just assuming it.
The other side of the feedback coin is awareness. Some of the worst mistakes made when programming can happen when you're just coding away without thinking, or when you become so entranced in the engineering minutiae of a project that you lose track of the big picture. These sorts of lapses in attention can quickly lead to large (and sometimes unrecoverable) errors. Often what happens is that you become so engrossed in solving a particular technical problem that you overlook a radically simpler solution. Or you might not spot the fact that the solution you're slaving over has just been rendered obsolete by changes elsewhere in the system. Extreme programming addresses these problems during the coding phase by insisting that developers code in pairs—the driver doing the actual coding and the navigator suggesting directions to take and looking out for potholes. See Kent Beck's Extreme Programming Explained: Embrace Change (Addison-Wesley, 2000, ISBN 0-201-61641-6).
A more subtle and ongoing manifestation of this problem can be seen in what we call programming by coincidence. Without proper feedback, it's easy to be misled by coincidences into thinking that the code is working and everything is fine. Only when chasing down some obscure bug does the cold, gray steel of reality pierce you, and you realize that most of this stuff could never work.
All of us fall prey to these problems at one time or another; we teach some techniques that help guard against it, but regardless of how you do it, it's important to maintain awareness. Keep some attention on the big picture. Avoid being distracted by the minutiae that often overwhelm most projects. Avoid being fooled by things that seem to work. Remember Pragmatic Tip No. 27: "Don't assume it—Prove it."