Philosophy and Introduction – Geek-as-a-Trade series


I’ve been a geek all my life. My work, my play, my housekeeping all involve geeking at some level. While plenty of geeks involve geekery in all parts of life, here is how I think I differ from most geeks especially at work and what’s important and valuable about that difference: I write stuff down and I plan for the future of whatever I just did in a world where I no longer do it, remember it, write about it or talk about it. Wherever I go I build a library of documentation about my research and creative process.

One of the things I’ve noticed about how my practice of being a geek differs significantly from other’s style and philosophy is that many geeks are very much in the moment.

They find and fix problems within their own specialties and that’s it. They try to identify and address issues as elegantly and quickly as they can, implement the fix, and move on.

In contrast, while I like to be quick and elegant, I don’t just move on. I document the discovery process, the steps to reproduce the issue, the steps to fix it, and make sure the documentation is in a place where people will be able to find it if they need it. Because my approach to being a geek includes leaving a decipherable trail so that other geeks can follow in my footsteps if they choose, not having to reinvent the entire process again unless they desire to.

This morning I read a piece on the Full Stack Employee (by Chris Messina), which aptly describes most of the method to my madness. I grew up as a geek, firstly with science, then computing and electronics, then the boundless wonder of the Internet. Though I may lose my hard, bleeding edge knowledge in a specialty field after I leave it, I do not forget the principles and methods that lead to success in that field and I do not forget the philosophy of its practice.

Once I was in computer security, I never lost knowing the way that a security engineer evaluates and manages risk, exposure and the constant probability of a hack. Once I was in chemistry, I never lost the principles of scientific investigation nor the philosophy and discipline of designing and executing a respectable scientific study, nor the essential methods of statistical analysis and interpretation, nor of being able to quickly evaluate the rigorousness or scientific worth of scientific studies.

I am a polymath in tech and business. A representative list of skills and job roles I have are as follows. (This list represents about 30 years of paid and volunteer jobs, internships and other experience and on-the-job learning.)

  • Systems and software architect
  • Software integration research, design and implementation
  • Technical writer
  • Information architect
  • Customer support (first level through third and fourth level escalations)
  • Human resources benefits analyst
  • Business process design and improvement
  • Business continuity design and documentarian
  • Quality assurance analyst
  • Vendor manager
  • Database design and analysis
  • Network design and engineering
  • Server farm design, engineering and implementation
  • Configuration management design, engineering and implementation
  • Security analysis and design
  • Project manager
  • Business analyst
  • Information security analysis and coordination
  • Software and Hardware design, engineering, consulting and implementation
  • Scientist (chemistry/physical chemistry/biochemistry)
  • … and there’s more

I enjoy jobs where, despite the job title, I’m expected to work independently to solve broad problems that span many disciplines in both Information Technology and in business process and in customer experience (from both the technical and the process perspective).

This is the essence of professionalism in the business context, applying to both how to do a job well in IT and how to do a job well in any field or function that is exposed to or touches a customer or a customer’s experience.

For my standards, what I expect to deliver on any issue that demands resolution or any issue I intend to bill for is the following:

  1. Issue status (in progress, on hold and why, resolved, closed).
  2. Reminder of context/summary of last direction.
  3. Summary (if a non-technical person or non-stakeholder) or details (if a technical person or a person who will be working with other technical people) of work done, suitable for forwarding to others.
  4. If the work falls outside the expertise I’m supposed to have, or that my colleague(s) have, a list of references I used to research the topic to round out my innate knowledge of the subject.
  5. If I know this deliverable will be used by others as a reference going forward, documentation or links to documentation I created to support the process.

For me, this is the required minimum at a task hand-off. Information on status, context, work done, references used and any relevant documentation. The minimum is not, I repeat, not simply a status of “fixed.” Because if this is all you hand off, you’re forcing the next person to do the minimum for you/the company/the client, and the best you’ll do just reporting “fixed” and moving on, is be tolerated until they can hire someone more like me, someone who leaves a trail of good documentation and reliable, repeatable process wherever I go.

,