Back in the groove

I've been thinking about "The Programmer's Oath" lately. Specifically, as it relates to my apprenticeship experience. While no specific disciplines are overtly stated in the text, I'm sure Robert Martin, the author, had a few in mind when he wrote it.

For instance:

• Item #1 (morality) while quite lofty, is about consciously applying one's abilities to make the world a better place to live than it would otherwise have been. It should go without saying that this often requires restraint and discipline.
• Item #2 (craftsmanship) is about high and consistent standards relative to one's work, requiring determination, diligence, and yes, discipline.
• Item #3 (proof) is most-often satisfied by disciplines such as TDD, BDD, and TCR.
• Item #4 (small releases) implies the disciplined use of revision control software, continuous integration, and continuous deployment.
• Item #5 (refactoring) is all about making disciplined changes to software, which is really only possible when the code is covered by extensive tests (see #3).
• Item #6 (productivity) hints at disciplines related to preserving and honing focus, such as Pomodoro Technique, GTD and getting adequate rest.
• Item #7 (reduncancy) is about frequent collaboration such as pair and mob programming.
• Item #8 (estimates) is about planning, specifically "The Planning Game".
• Item #9 (learning) is about disciplined application of time and effort in approaching problems just outside the comfort zone of one's current abilities.

A bit ago I experienced what I called "a lapse in discipline". It was a good lesson to (re-)learn. You see, one of the most difficult character qualities to develop is diligence. What do I mean by that? Well, there are certain decisions that would only need to be made once, except that we lack diligence in our resolve and, for whatever reason, we cut corners.

Anyway, I'm happy to report that I test-drove almost an entire user-interface from scratch today! But, that draw function in main proved difficult to 'prove' without resorting to visual verification (it's a bunch of quil library calls that do the rendering).

(defn draw-root [state]
  (quil/background background-color)
  (quil/fill background-color)

  (when (not (game/playing? state))
    (quil/stroke grid-color)
    (doseq [[x y] full-grid]
      (quil/rect x y width-of-each-cell width-of-each-cell))

    (quil/fill text-color)
    (quil/text-align :center :center)
    (let [[x y] control-panel-center]
      (quil/text click-to-begin-text x y)))

  (quil/stroke live-cell-color)
  (quil/fill live-cell-color)
  (doseq [[[x y] _upper-right] (get-in state [:grid :live-cells])]
    (quil/rect x y width-of-each-cell width-of-each-cell)))

In the spirit of "[producing], with each realease, a quick, sure, and repeatable proof that every element of the code works as it should", what would your approach be?

-Michael Whatcott