Today I ran into an obscure JavaScript error that seemed to only be present on the CMS build. I ran through the usual suspects: trying a few tricks I know, scouring Google and Stack Overflow for a similar answer, and hitting up the GitHub issues on the related projects.
They were all of no use in this case. Many issues seemed similar, but none of the solutions seemed to work.
And an error in JavaScript on the browser is difficult. This is because stops the processing of JavaScript and thus breaks the functionality of your site.
Luckily for this project I had a solid set of front-end code built out. Since the CMS implementation used a common set of build tools and templates, I could quickly find the answer.
But first let me tell you how I learned this technique. Back in my 20’s I used to work as a contractor for Apple telephone tech support in Sacramento.
The single most important takeaway from this job is the idea of isolation.
In their case they applied it to troubleshooting computer hardware, but it can be used for literally anything. I have used it myself in countless other applications, including troubleshooting and fixing automobiles.
The idea is that you want to isolate the issue you are having. On a computer you can do that by removing everything and only connecting the bare minimum. On a website, it is no so easy to disconnect things.
That is where quality front-end code comes in. This allows you to have something that is simple and can be easily isolated.
It gives you a test bed that is decoupled from your working site where you can test ideas and solve any issues that arise. It can then act as a blueprint as you roll the changes back out to your production product.
This gives you efficiency, the ability to use a variety of tools in your troubleshooting process, and to speed up your progress by limiting the number of moving parts.
I wondered what I might have done if I didn’t have the front-end code available.
I suppose I could have continued searching, but I am not sure I would find a solution. I guess I could asked around to see if anyone had the same issue. Or I could tried to fix it by trial and error.
The common thread here is that all of these would have been terribly inefficient and burned a lot of time. Design Systems Engineering if done right, gives you a set of tools to get some of that time back. And, with a lot less uncertainty and stress.
This is what the process looked like instead.
I used a tool called Kdiff 3 which has a nice feature of being able to compare entire directory structures of files against each other. It annotates files that have differences with a red color, which allows you to see which files are different between the two sets. It allows you to also see in each file, what is different and what is the same.
I used this tool to compare my front-end code against my CMS build. I able to identify the offending line of code and quickly patch it. Simple, clean, and easy.
