As we’ve established before, I’m a slave to process. I practice the philosophy of systemization, to the often benefit of my work life, and the sometimes detriment of my life of cohabitation (a topic for another post on another blog). I’ve been bestowed an eye for the detection of lapses in efficiency, fbofw, and spend what could safely be described as a scandalous amounts of time correcting them. I think about this stuff a lot.
Of course, there reaches a point where the amount of time spent executing a process outweighs the time gained by it. This has happened to me recently in how I manage site templates.
The old way
Some time back in my old job, when we were building out new sites at a pretty aggressive clip, I thought it’d be useful to develop a starter kit—a directory of files, folders, useful styles and Javascript functions that would serve as a foundation from which to build out a new site. When I left the job, I took the kit with me, and continued to update it with new techniques and standards as I developed them.
Except this wasn’t as easy as it sounds. When in the process of developing a site do I decide that a piece of code is suddenly a new standard and needs to be added back to the foundation? Standards don’t come about immediately, they are sussed out over time. Only after a technique has been tried and tested is it ready to be put into the vault, and by that time, I’ve moved onto other parts of the project.
Even if I do decide some particular solution is vault-worthy, the last thing I want to do is stop the flow of my work and figure out a way to abstract what I’ve just done and fit into a generic template. It was becoming more trouble than it was worth.
The new hotness
I’ve come up with a plan. Instead of committing to a master template that contains all my best code, along with the burden that comes with its upkeep, I’m designing something much lighter. It’s a simple table: a list of techniques in one column, and the site where they’re used in another. It’s an abstracted, distributed solution, which, taking the cues from wikis and the like, holds much more promise for long-term usefulness.
With a list like this, the template still exists, but in a bare-bones form. There will always be pieces of a site that are universal, like the DOCTYPE, a basic directory structure, and certain CSS files. Beyond that, the template is a clean slate. All those tricks and tools that get used only occasionally—mostly CSS and Javascript techniques—are getting removed and abstracted into this new list.
I see a couple benefits. There’s the relief of the frustration I mention above, with the constant wondering if what I’m doing needs to be abstracted for vault-keeping. Now, if I recognize that something I’ve coded or designed deserves to be memorialized, I simply have to list a reference to it. Then, later, if I want to expand its scope to include references to solutions I see out in the wild, I can.
I’ve only started putting this idea to use, so I can’t yet say if it’s the right solution. The key here, as with any system, will be remembering to use it. Both on the input end and the output. It’s no good having a list of tips to refer to if the list doesn’t mature and stay relevant.
I know this is an over-glorified bookmarking system. You can forgive me if I treat it like a bit of a breakthrough. Anytime I can increase my ratio of productivity : time, it’s cause for a minor party in my brain.