SHARE:
Uncategorized

Anal v Methodical

Flatiron School / 17 October 2013

The following is a guest post by John Richardson and originally appeared on his blog. John is currently in the Ruby-003 class at The Flatiron School. You can follow him on Twitter here.

POODR and Everybody Poops

Everybody Poops

For those of you who don’t know, Everybody Poops is a popular potty training book for toddlers that catologues the pooping habits of man and beast.

I start here because when I first got interested in programming, I thought I might be good at it because I was anal. Or more accurately, anal retentive, a character trait that is meant to be acquired during the ‘anal’ stage of development. From wikipedia:

The term anal retentive (also anally retentive), commonly abbreviated to anal is used to describe a person who pays such attention to detail that the obsession becomes an annoyance to others, potentially to the detriment of the anal-retentive person.

I can definitely be obsessive. I believe there is a right and wrong way to do things. Heck, I can even tend towards the obsessive compulsive at times. Did I turn the stove off?

Anal retentive v methodical

The more I meditate on being anal, and the more I learn to program, the more I think that being anal could be a liability and not an asset. From what I can tell at this point, being methodical is much more important than being obsessive, and yes, they are very different things.

Asserting control over things like cleaning or safety can appear a virtue. You know, being fastidious and organized. Failing to prepare is preparing to fail. But obsessing over the details of knowable, controllable things like cleaning and safety is relatively easy. This is why obsessive behavior is annoying to others. To the unobsessed, this type of obsession feels like overkill. An unwarranted and intrusive allocation of energy to relatively small problems.

Methodology, on the other hand, is about applying a systematic or established procedure (aka method) to solve a problem. You do not have to wholly understand the thing you are dealing with to be methodical about finding a solution. Take an example from vertebrate taxonomy:

Coelacanth

Thought to have been extinct for millions or years, coelacanths (aka the “living fossil”) were rediscovered swimming around the sea in the late 1930s. More closely related to landlubing creatures than typical fish, they are difficult to classify. Unable to quickly tidy them away into a preexisting understanding, the anal biologist might become overwhelmed when confronted with such a challenge.

Alternatively, a methodical biologist could apply a series of procedures or methods to find a home for this old timer. Does it have feet? fins? lungs? gills? scales? skin? These individual questions are a set of methods for establishing the taxonomy of an animal. We can apply these methods to animals both known and unknown, and develop an understanding of their characteristics and habitats.

POODR

The complexity of technology and programming languages make them hard to obsessively control. And even if you manage to develop an encyclopedic understanding of today’s technology, the constant change would eventually overwhelm even the deepest capacity for memorization. By developing a systematic, methodical means of approaching code, you don’t have to worry about knowing everything or being in control. You can simply chip away at a big problem until it eventually becomes manageable.

I am coming to terms with the fact that the answers to code questions don’t have to be knowable or neat at first. What I seek to find now is not the answer, but a methodical means to find those answers. The more I understand the art of programming, the more comfortable I become with the unknown.

Meditations Previous Post Making a Good Lookin’ CLI Next Post