Eight Habits of Highly Effective Programmers

Next to the gospel, my favorite self-help book is the Seven Habits of Highly Effective People. The Habits apply to any endeavor, and I like to say that the Seven Habits is the first book any novice programmer should read. To help underscore why, here’s my humble homage to brother Steven Covey: The Eight Habits of Highly Effective Programmers.

• Estimate (or Be Proactive)
  Programmers invent the future. It’s often hard for us to know how long something will take, because, often, we’ve never done this exact thing before. In the fictional series Star Trek, engineer Montgomery Scott would triple his estimates, so as to seem like a miracle worker. Software engineers often have to triple estimates just to be in the right ballpark!

Educators tell us that feedback is essential for learning. Before starting any programming task, write down an estimate first. After the task is done, compare your estimate with the actual result. Of course, all engineers are optimists, otherwise we couldn’t be engineers. But, with practice, we can learn what factor to apply to our internal estimates to match external events. (As implied, my factor is three!)

An easy way to get started with estimates is to keep a standup journal. Every day before starting work, jot down the most important task you did the last working day and the most important thing you hope to do today. Over time, you will develop a basis for comparing estimates with outcomes.

• Test First (or Begin with the End in Mind)
  Most projects budget at least some time for testing. Many projects schedule this time at the end, after the rest of the work is done. Tests serve two purposes. Run today, tests prove that our code works. Run tomorrow, tests prove that our code still works. Test-last development dilutes the value of tests. The earlier tests are written, the sooner they can tell us that the our code still works. Tests are most valuable when written before we write the implementation. By writing the test first, we define what our code needs to do to succeed. As a result, we write only the code we need to write, no more, no less.

• Iterate (or Put First Things First)
  Creating effective software is a learning process. Each release addresses old needs and exposes new needs. Many software products are written for small workgroups, or focus groups of representative users. The sooner we deliver a product that the group can review, the sooner we can verify that established needs are being met, and the sooner we can identify new needs. Early verification is important, since programmers often misinterpret needs and write great code that solves the wrong problem. Writing code is easy. Identifying what code to write is hard. Early iterations help us create a positive feedback loop, so we can deliver better applications.

• Narrate (Seek first to understand, then to be understood)
  Many teams define an application through a series of use cases, or plain-language workflows. To “set the stage”, a use case might begin with a narrative that describes one common instance of the workflow. The narrative often refers to a prototypical user and includes details of how that user would use the system under specific circumstances. By describing the workflow in plain language, from the user’s perspective, we can establish a dialog. Use cases help developers understand what clients want, and also help clients better understand what developers need to know to implement the workflow.

Next time: Habits 5 thru 8 …