Cold Hard Code

If you haven't read Zed Shaw's C2I2 Hypothesis, you should really do so now.  I mean it, go read it.  I'd like you to come back here but if you don't that's ok, I'll understand.

The main gist is properly identifying just what type of person you are working with, and to a more significant degree, what type of person you are (which is variable).  I have my own thoughts on the specifics that he lists that I'll likely write up later, but for now just reading it is a good start to continue my current thoughts.

I think that it equally important to understand the tools you are using. It seems a lot of people use a specific tool because they don't really think about other tools. If a problem looks like a nail, they use a hammer.  While I hate metaphors when they're not necessary, I think using the nail/hammer metaphor does work for this case.

What ends up happening is the, "When all you have is a hammer, every problem looks like a nail." syndrome.  Conversely, if you have a vast array of tools at your disposal, you are going to over-complicate problems.  There is a very important balance that must be maintained.

If I had to pick over-engineering a problem, versus simply driving a nail in a plank of wood and calling it a deck, I'd over-engineer it every time. This is coming from years of experience, and several contracts that seemed to extend in two-week intervals where I was expecting to find another gig every two weeks.  One of those went for 2 years, adding two-weeks worth of "enhancements". It was all hammer and planks of wood. Absolutely terrible.

The reason why I'm writing this is because a discussion popped up where I expressed my confusion in people using plain vanilla mod_perl, then being frustrated with testability and other nuances. Someone pointed out that mod_perl is a perl runtime inside of Apache that gives you programmatic hooks into Apache.

Fantastic.  However, that doesn't enter into what my point was.  People use mod_perl because that is the only tool they know.  I believe this is the case with most PHP-based engineering shops.  They use PHP because that is the tool they, or the managers, know.

The problem with this mentality is that by not knowing the tools, you are doomed to work within the confines of what you know.  While the skillset and knowledge may evolve, it won't have a renaissance or giant evolutionary leap.

This is the key reason for learning other toolsets and libraries that are available.  It isn't about jumping to trendy and shiny technology, it is about defining your own capabilities in relative scope to what other technology is around.

It's very easy to spot this type of individual, which I view as a blessing.  If a person ever argues against a tool (or rather, using a tool in place of something that they know) you can count on them being very limited in their ability to accurately scope and understand a problem.  They will mutate the problem to be solved with the tools at their disposal.

In context of Zed's C2I2 hypothesis, I've been struggling to really distinguish between a collaborator and an implementer.  They were very much the same in my mind.  Thinking about the usage and understanding of tools has helped clear this up for me.

A collaborator doesn't know the details of the tools.  They follow cookbook recipes.  Contrast that to an implementer, who still follows cookbook recipes but understands the tools that are being used.

The inventor, of course, usually is the one building the tools.  If a tool doesn't fit an implementers agenda, they'll either move on or smash at it until it works.  An inventor will go in and fix the tool.  A collaborator will be that guy on the mailing list you wish would go away, and probably be the first in line to argue against other tools they've never used.