Retooling

I spent the past two weeks digging into the details of how to customize Ghost, the publishing software I'm using for this site, which has then led to learning more about what the product is capable of doing, which has led to more questions, which inevitably results in finding myself on their support forums and discovering best practices as well as limitations.  

I'm glad I've invested the time in learning how to use it, because I can see how this will pay off in spades down the road.  It's a bit like discovering a new super power.

Such is the usual pattern when you are learning how to use a new tool.

Last year, stumbling across VuePress was a similar experience.  The core use of VuePress is to build out documentation sites.  Often, you'll have a codebase where the code is documented in a certain way, and tools like VuePress can generate a documentation site, which can help people learn how to use your code.  What makes this tool a time saver is that the user interface and interaction model of the system is optimized for reading documentation: it's designed for long-form content, it's easy to organize and structure content in a hierarchy, in many cases there's also a sequential nature, etc., and much much more.  It's a very distinct use case from blogging software, which is optimized for displaying a collection of standalone posts in a reverse chronological feed.  Kind of like how the structure of a magazine is different than an encyclopedia.

I didn't know at the time that what I was missing in my life was a publishing tool optimized for documentation, but once I discovered it, it unlocked so many possibilities for me on a few critical projects that had been somewhat stalled:

• Orbital needed a better member guide than the rag tag Google Doc that we had, which wasn't scaling given the complexity and amount of information and functionality required, and that was leading to a lot of administrative and communication challenges.
• Chris and I needed a way to archive all of our work on teaching entrepreneurship, and neither Medium nor Google Docs nor Github were quite the right container for it.  The work had outgrown all of these adhoc systems that we'd stitched together over the years.

All of this has reinforced the idea that significant part being an effective self-driven learner is investing the time to experiment and play with tools out of your own curiosity, before you even know what you'll use them for.  It's an investment rather than a waste of time.

There's far too much accepted process for "how to do things" that is completely rationally driven, which is the topic for a different post altogether, but what I've found is that problem solving is rarely linear.  

That is, the act of investigating the problem may lead to a deeper understanding of it, but it'll rarely lead you to the solution.  Almost by definition, solutions can't be derived solely by the research, especially for the really hairy ones.

Instead, you need a parallel track, guided by your own curiosity, to explore the growing world of what is possible.  At some point, you'll either connect the dots and have an epiphany that unlocks new paths for you to go down, or you'll need to keep exploring.

My takeaway from this whole experience is that I probably need to be spending even more time immersed in understanding and leveraging new tools, given that we're effectively in a golden age of SaaS.  And what that means is that our default sense for what we're individually capable of supporting may need to be continually refreshed.