Thanks for subscribing to the HonestRepair Newsletter!
I'd like to start off this newsletter by apologizing for skipping last month. The holiday's got extra crazy and yeah, I'm really using that as my excuse. I still found the time to roll out a lot of exciting stuff with more on the way.
HRConvert2 - Nothing new to report.
HRCloud2 - In December I released a new repo full of browser games that I converted to work with the HRCloud2 App Launcher. That repo can be found on the official HRCloud2 Game Pack Github repo. I also created a backupCore for HRCloud2 that does exactly what you'd expect it to do. Adding this feature enables admin controlled backups and allows for a $BackupLoc variable to be set in config.php. I did my best to make the system forgiving and backwards compatible but some admins may want to manually add the latest variables to their config.php just to be safe. The system also contains a script that can be dropped into a cron folder for automatic backups and a security mechanism for identifying when it's run from a GUI, command line, or cron. There's also a mechanism to ensure that the user attempting a backup is an administrator. The cron script isn't perfect yet so I recommend holding off on using it unless you're willing to help me debug it (which I would appreciate).
HRScan2 - Nothing new to report
Atoner - Minor creative work. Nothing worth talking about.
HonestRepair Network - Renewed our ISP contract. On paper our network increased in speed nearly 600%, but real world performance wasn't quite that much. In addition to increased speed through our ISP, I also managed to further optimize the websites front-end. Most requests should now come in under 310kb with 8 or 9 requests all handled by HonestRepair servers. No CDN's or external resources are used. I also upgraded our WordPress installation to 5.0.2 from 4.9.8 hoping to skip some headache associated with a major update but that wasn't the case. I'm sure the WordPress guys will sort it out, but if you're still on the fence I'd give them another couple of weeks. Lastly I've loaned one of HonestRepair's servers to the local hackintosh community so they can hopefully work out some hardware/firmware bugs they've been working on. That machine should be back by next month, but there's no reason it couldn't be spared for longer if needed. I'm proud and confident enough to call our services straight-up fast.
In The News
Usually I'd write a little blurb for some of the headlines that caught my eye between Newsletters, but since so much has happened in the 2 months since I've done one of these I'm going to skip the news. Instead I'll link to a recent statement made by HonestRepair in regards to some recent developments with some of our dependent packages. Click here to read the "Statement on 7z encryption bug & PHP-Pear Supply Chain attack." And with that I'll segway straight into this month's feature piece! Please read the entire thing before passing judgment on the title. I tried to make it interesting but I think some of my colleagues were put off initially by the click-bait-y title. Sorry for that in advance.
Why Does IT Suck With Computers?
I'm pretty sure everyone has had an experience with tech support where they called into question, either verbally or mentally, the qualifications of the person on the other end of the line. Its even more frustrating when that person is struggling through the same problems you were struggling through, and seems to know little about the problem or how to even begin to fix it.
The truth is, your IT guy doesn't have all the answers in his head already. He has to understand the problem and develop a solution. Technology is as powerful as it is today by compounding the knowledge of thousands of programmers over decades of development. This knowledge combines on our technology to create an ecosystem. In order to diagnose problems in this ecosystem, one must understand what makes it tick.
Your IT guy knows these ecosystems. He knows how the different components react with one another. He knows what components require other components. He knows what components conflict with each other. But no two ecosystems are alike, and it takes your IT guy time to build a representative model of that ecosystem in his mind. You don't pay your IT guy for fixing your problems. You pay him for knowing how to fix your problems. If you were paying him for simple action without knowledge you wouldn't need an IT guy at all. Anyone could do it!
So What's Taking So Long?
Your IT guy is going to want to verify the problem for himself. This doesn't mean he doesn't believe your description of it. This means he needs to see for himself all the factors that go into the problem, and what about the result was undesirable. He will want to see the affected system. He will want as much context about what's going on as possible.
He may want to setup his own ecosystem where he can tweak some of the variables and recreate the problem on his own. This will allow him to measure the problem and the effectiveness of his solutions. This will also help to identify anything about the problem that you might have missed. Maybe the problem you're reporting is a side-effect of a larger problem.
He's also probably going to search online for other instances of the problem. As much as this can be seen to non-techies as a weakness, it is most certainly a strength. There's millions of people out there searching for solutions for things online. Why duplicate work when someone else could already have the answer? If you're considering shaming IT for utilizing an internet browser because you don't consider it work; you're costing yourself productivity. It's like telling a mechanic to use a ratchet instead of a pneumatic wrench because he might use the air compressor to paint his car instead. Besides, learning is work. If your IT person didn't have a knack and passion for learning they wouldn't be in IT in the first place. You should encourage your IT personnel to set aside some time on a regular basis for learning new skills and researching things they aren't confident about. This will pay off in the long run when your IT staff are better prepared to solve problems and better equipped to tackle projects. It also increases morale which improves productivity and effectiveness.
Are You Sure He's Not Just An Idiot?
That depends. I know I certainly don't have a 100% solution rate and I sleep just fine at night. Some problems can require expertise outside what you've got, which is why it's important you allow your IT people to learn and expand their skills on the job. You can consider lack of specific expertise the fault of the IT person, but keep in mind that NO IT person on Earth possesses expertise in all subsets of IT. It's just too much for one person to know. Take me for example. I can write computer programs and scripts in 6 Turing-complete languages. I know 4 markup languages and am familiar with 2 database engines and their query languages. On any given workday I'll use 4 different PC operating systems. While that sounds impressive, and I'm quite proud of myself, there are still dozens (if not hundreds) of common languages, databases, and OS's that other shops require and I've never seen before. So expertise is a matter of context. Plain and simple.
Of course some bugs are just outside the scope of IT in the first place. Even the best IT person can't solve a bug in proprietary enterprise software. The best they can do is communicate the problem to your software vendors and hope that they take the problem seriously. Perhaps an even larger subset of problems are user-created. That means that if your other users were more knowledgeable that they would never have experienced a problem in the first place. As tempting as it might be to lay all of your organizations problems at the feet of your IT department come review time you must realize that not every problem has a solution. There are other metrics you should use to measure the performance of your IT group.
What differentiates a "good" IT person from a "bad" IT person, from a problem solving standpoint, is:
How Can I Help IT Help Me?
Report the issue promptly and include plenty of information. Don't be offended if they seem to re-verify what you've given them. It's nothing personal and it's not because they don't trust you. This story about a 500 mile email reminds me to always take a client for their word. After that you will simply want to give them space.
After your ticket is closed you should be sure to report any recurrences of the issue to the same person you reported the original issue to. If a developed solution stops working and IT isn't made aware they may continue deploying an ineffective patch and making things worse rather than better.
Ultimately being understanding of the fact that solving IT problems isn't an exact science is the best thing you can do for your IT department. Sometimes just trusting that they want to solve your problem as much as you do is all it takes. Sure it's hard watching someone fumble around the same buttons you were just fumbling with, but that's the process just about any IT professional is going to take.
Recently Published On HonestRepair
Rowley MA, USA
All work licensed under GPLv3.
To change your subscription, click here.