Saturday, February 5, 2011

Iron Filings

Iron by iron is sharpened, And a man sharpens the face of his friend.
A minor incident this week reminded me of this proverb. Actually, a lot of incidents do. As a metal blank is turned into a usable tool, it must first be shaped, then smoothed, and finally polished. Likewise, older tools can be refurbished by first welding, then re-grinding and polishing. In the process a lot of little bits of metal castings are generated, the stuff that was useful at some moment in time but now goes completely against the grain of the refurbishment.

My hope is to be able to find a path that makes me feel that I'm not constantly leaving great big piles of "me castings" around on the floor.

The other day, I cut some code for a Rails report. Relatively simple stuff. But there were a few problems. First, I was fatigued. Second, I was programming alone. These contributed to the actual root causes, the "me castings" for this week:

  • Short-cutting tests is just a way to lull yourself into a false sense of security. Run them the way they are supposed to be run, completely, from top to bottom, and pay attention to the details of what the results are saying. Make sure you run tests fully before attempting to commit changes. 
  • When you have a failing test, don't commit. Or if you do commit, make it clear to everyone involved that you have failing tests, and ask for help; or offer to commit to a branch; or stash the changes and move on momentarily until you can get help. 
  •  Line-wise and paragraph-wise Cut and Paste is a recipe for error injection. It is just dangerous, period. I used to code by cut-and-paste often in 4GL languages due to the repetitiveness of the apps' boilerplate approach to development. I foolishly thought I could use it and find a way to not inject errors. The lesson, in retrospect, is that there is no way to separate cut-and-paste errors from cut-and-paste. Copying lines and paragraphs is especially evil because my brain tends to be looking for and see the similarity, and auto-correct for the differences, but those corrections may never make it to my fingers.  Besides, the approach to Rails used here is most definitely not a boilerplate approach: the app may be copied to start, but everything after that is treated as one-of crafting. This was the most grievous "me casting" of the week.
  • Cutting into other's code requires special mindfulness. Doing it with cutting-and-pasting is completely wrong. Doing cutting-and-pasting while tired is a crime. At one point, I saw what looked exactly like a three-line function I just wrote,  so I cut.  It wasn't my function, and had I run Rake properly I would have seen that it was not. Fortunately, we had git. Make sure you communicate if you have an elusive sense of uncertainty, but especially if you feel completely confident. 
I'm tempted to force git to warn me had I not run Rake before committing, or obfuscate the line-oriented cutting commands in Vim, but these are mere technical crutches. The reality of the examples of practice that I'm seeing, is that it forces you to be mindful of your surroundings, of your code, of your peers.

Being mindful enough of the affect of your actions, and communicating often and early with those in your circle, is critically important. At least, if you want to stay in the circle. It has been many years since I've been in a group of developers that really functioned as a team. It is profoundly disturbing to see how much less proficient I can be compared to some of the younger developers, and as difficult to consciously spot and let go of poor habits. But I am trying. 

No comments: