If you enjoy knowing how something works, then you and I, are cut from the same cloth. I want to know it all. The more I know, the better I can work with something and understand precisely how to use it in the most efficient way possible.

But knowing everything is a fantasy. Much like a good Steven Seagal movie, it’s never going to actually happen. Even the seemingly most simple things can have a near endless depth hiding behind it. Take, for example, setting the a variable to the value of 1, in C++:

int variable = 1;

This seemingly simple instruction can easily have layers and layers of complexity hiding behind it. Like how the variable – or more accurately – the space in memory representing the variable, is allocated and assigned, i.e. heap and stack. Another layer of complexity to explore is whether the variable is ever actually memory-allocated and set during execution, depending on the which settings the C++ compiler had set during compilation, and which of the many C++ compilers was used. The memory allocation and assignment instruction may be optimized away.

The point is: Whether I want to acknowledge it or not, it is literally impossible for me to understand all the concepts I would like to understand, to the depth I would prefer. While I’m sure that the ever shrinking amount of free time I have as an aging adult contributes to this feeling, I think the real accelerant has been gaining deep knowledge in about 3 or more fairly separate fields of technology.

So what do you do? If – like me – you’re a strong believer in skill stacking you definitely do not want to reduce your areas of specialization. If skill stacking is an unfamiliar concept, I urge you to read Tomas Pueoy’s article about it. The gist is: It’s nearly impossible to become the world’s best at one single skill, but it’s quite possible to become the absolute best at a combination of skills, particularly if the combination of skills don’t tend to go together. The key is to find the skills that do not tend to go together, but still compliment each other well, e.g. programming and public speaking. Honestly, if you’ve never read Tomas Pueoy’s article, it is a better use of your time, than reading my own word salad. Feel free to leave, become wise, and then when you’re ready to continue slummin’ it here with me, I’ll see you then.

All caught up on skill stacking? Great!

Having solidified that we don’t want to drop any field of expertise as a whole, how do we determine what to become selectively ignorant of?

I suggest any sufficiently complicated tool you don’t use often enough. Vague, I know. What’s not often enough, and what if I suddenly need this tool unexpectedly again? While I cannot help predicting the latter, I can comment on the former. “Not often enough” is contextualized by all the complicated tools you use in life. Somewhere, in your every-day activities, is one or more tools that you use the least, and is far more complex than all the others you use just as little. That’s a good place to start.

Allow me to break my own motivation for embracing selective ignorance into bullet points, with minor examples relating to my old – now retired – custom-built PHP-based Laravel back-end:

• Knowledge degradation – Our memory is ever fading. I acknowledge this upfront as it is a core component of why the upcoming points end up being so problematic.
• One-off tasks – Tasks that need to be dealt with once a year. Building a custom PHP/Laravel website back-end, running on a local virtual machine, is choc full of one-off tasks, particularly during the initial scaffolding setup. You don’t think much of this until much later, when all of a sudden you need to touch some of this scaffolding again. But by then, you may barely recall the details. How exactly did I stop/start this obscure service that occasionally fails via SSH again?
• Evolving tools – Most tools evolve over time and we must learn to keep up with the changes or become unable to effectively use them. Different tools evolve at different speeds, e.g. web standards and associated tools generally evolve faster than tools for desktop applications.
• Growing expectations – As a craft grows, so do expectations. Website visitors have higher expectations these days, compared to the heady early internet days in the 90s. If you want to maximize your ability to meet these expectations, you’ll need to commit a huge amount of time to keep implementing and maintaining features, or make use of middleware.

Your milage for these points will – of course – vary, depending on which type of technology you’re considering turning the other cheek towards.

A reasonable counter-argument to the first two points is documentation. You can document the most esoteric knowledge you accumulate, and there are numerous platforms available to host a small knowledge base for free. But make no mistake, documentation is more work. Documenting a process only for yourself is a large overhead for a limited benefit. Good documentation takes a long time to write, and the only reader, would be you.

The last two points highlight the growing complexity the web offers. You can choose to opt-out of new features/standards and risk alienating visitors, put in more effort, pay someone else for the effort, or reach for middleware. Those are basically your options when it comes to the web.

My own embarrassingly overdue epiphany came about when Google’s chrome, and most other browsers, opted to label all non-SSL sites as unsafe in 2017. Despite reassurances from some developers (see warning further below), that transitioning from http to https was a small task, I felt deep down that this was actually the last of many tasks that finally broke my own back.

Even if the task was small, and by small I mean one that would merely take a day, for the unseasoned virtual machine host to implement, there would always be more ‘never seen before’ tasks. Many of these, as previously noted, would be near one-off tasks, never to return, until right about when the last vestigial thread of knowledge for that one-off task has left your brain. Then, and only then, would the task make its triumphant return, maximizing the amount of time you must spend getting back into the right knowledge context to address it.

So if you wish to run a standard website offering many contemporary conveniences and neither your paid work, nor your core hobby activity is webdesign – and possibly even then – pay someone to help. If not, I’d argue you run a high risk of finding yourself often having to spend a surprising amount of time re-learning context, dealing with multiple one-off tasks, or otherwise risk the website deteriorating.

The 10-15 USD you’ll be spending a month is well worth leaving the back-end tools behind, which you’ll rarely use, yet must always be somewhat up-to-date with, in order to keep your website from falling behind or off a cliff.

If you’d also like advice on how to make the transition from a more hands-on approach to a managed WordPress solution, tune in again next week for the final part in this series, same bat-time, same bat-website…