notabot

The cat’s taken the dog’s bed amd the dog’s taken the human’s bed, so the human shoild sleep in the cat’s bed.

QED.

Walnut bread is pretty great too.

Back in the day, the entire game came on physical media, and patches were things you sewed to your clothes, so the publishers had to, at least try to, ship a working game, with all it’s features in place.

Now get off my lawn you kids!

It sounds like there’s something up with your instance. The word is t i m e, and it shows up ok here.

In general this isn’t going to work with any language that the people reviewing the recording can find a translator for, however a variant of the idea did serve the Allies in WWII. Native Americans were drafted into the military as “code talkers”. They used their native languages to send and receive radio messages, and, as the Axis powers did not have access to anyone who spoke those languages, they could not understand intercepted messages.

Although no code talkers was ever captured, it is alledged that a member of each unit they were attached to was given a secret duty to shoot them if it looked like they would be, in order to protect the code.

They don’t want to replace the you that is producing free content for them to ingest, they want to replace the you that earns enough money to live.

Mariah Catrey?

After a certain point in the day, “same day delivery” is a threat, not a promise.

One other thing: get all requests in writing, or confirm them back to the requester in an email if they insist on giving verbal instructions. This will save a lot if miscommunication and misunderstanding. Instigate a ticketing system if you can, and only process tasks through that. Add the tasks yourself if you have to. Users may start off hating it, but they’ll come to appreciate being able to see how their request is progressing, and what else you’re being asked to do.

This sounds pretty normal for a small company that doesn’t really understand its I.T. needs yet.

Aim to automate as much as you can, you’ll be busy enough without having to perform the boring, but necessary, repetitive tasks like handling user on-boarding, off-boarding, password resets, and permission changes. I’ve generally found that it’s best to do a job manually first, noting down everything, then aim to automate it the second time, because, if there was a second time, there’ll be a third, fourth, fifth, and so on ad-nausiam.

Try to also automate testing. A script that can sanity check permissions, paths, and the like will save you many painful hours of debugging as you can test every change, rather than working out that the quick fix you did last Tuesday has broken the CEOs access to a critical slide deck today, and needs to be fixed 5 minutes ago.

Document the why, the how, and the what of everything you do. It doesn’t need to be fancy, a set of text files is more than enough, but I’ve been using Obsidian, or vimwiki on Linux, and it will save your bacon when you need to figure why something is the way it is, how you can fix it, and what to change. If you do use a wiki, keep a daily journal, but link the entries to pages about the relevant services. Don’t store the wiki on sharepoint, or you risk not having access when you need to fix sharepoint.

Set up an internal monitoring service that can notify you if a service goes down, or one of those tests you automated starts to fail. You will seem like a wizard when you’re already fixing a problem before anyone else notices.

Seen as the CEO has admin access, as, presumably, does the external IT person, enable audit logging on everything. That way, when something breaks, you’ll know who did it, and what they did, even if it was you.

As others have said, this will be hard, but it’s a massive opportunity to grow your skillset rapidly, in an environment that sounds like it may tolerate some mistakes.

Good luck.