Stories from the office – subverted expectations

When I got into work this morning, right after the first two sips of coffee, I saw an inspirational video posted by one of my LinkedIn contacts. It was a challenge he sent out – to make today the most productive we can.

I had been on a productivity hot streak – I had written and posted eight blogs in seven business days, and I was ready to blast out another piece today. After seeing the LinkedIn video, I challenged myself to write two.

Unfortunately (fortunate for the tendons in my wrist, however), the hot streak came to a close.

Our CEO is a big believer in letting us carve our own path, discover the dead ends, and learn from them. There’s never been any pressure to not make a mistake – the expectation isn’t perfection, but rather the ability to pivot quickly and make the most from (and fix) said mistake.

Mistake #1

Not talking to any devs about the content wheels the content department came up with.

Believe it or not (but it’s very believable), before I started with NS804 I had about as little knowledge about app development as possible. The first smartphone I ever got was a hand-me-down iPhone 5c in 2015. I still use it – all five available gigabytes.

I’m pretty okay at learning new things, however, which is the reason I’m here. I’ve learned a lot in these past eight months, and I hadn’t hit a snag since January when I first tried to wrap my head around writing a layperson’s guide to Android development. I’ve gotten to that point where if a developer is talking about what they’re working on, I can glean about 70% of what they’re getting at – it’s like when you can understand the words of another language when it’s spoken to you, but you can’t form them in your head to respond. In my case, it usually means I spend about 70% of the conversation nodding my head up and down, because that’s the universal way to communicate “I understood what you said, I just have nothing important to add.”

So anyway, the title of the story I planned to write today was this: “How to migrate your users when updating your app.”

If you’re a developer, you most likely just blinked from the… ridiculousness of that title.

You see, I’m a writer, not a developer. I have a degree in creative advertising, not computer science or information technology. The last marketing department I worked in was for a reclaimed wood shop.

But don’t worry – our blogs and guides aren’t pulled out of a hat and vetted by someone who doesn’t have enough technical knowledge to understand when they’re on a wild goose chase (like the situation I’m currently writing about). There’s our dev’s expert review backing our content.

Mistake #2

“If you can’t find it on Google, it might be because the thing you’re looking for doesn’t actually exist.” – Future Kate, hindsight-ing past Kate.

I mean, yes, there are better resources out there, like Stack Overflow or Exchange for the answers to detailed or technical questions. But when you’re writing a piece that needs to be understood by everyone, it’s better to start with resources that were meant to be consumed by non-tech people. You know, don’t reinvent the wheel, work smarter, not harder sort of deal.

All that I could find were how-to’s on migrating your app to the cloud – all well and good, but it wasn’t what I was looking for. I’m not one who gives up all that easily, however, so I kept refining my queries, digging deeper.

For a while I was a little excited by the thought of writing a blog on a subject no one had touched yet – the fabled nascent piece of content. Now, if you are a developer, you might be shaking your head at your screen right now, thinking to yourself, “yeah, you couldn’t find anything because it’s a literal non-issue.”

But, dear developer, to someone who has worked on re-branding campaigns, it was a natural, completely rational subject to tackle.

The funny part is that I totally understood you could update an app’s code base with anything. Sure, if it’s on the App Store, you need to get your update approved by Apple first, but you can switch out a build that was made in React Native with true Native, or vice versa.

Unfortunately for my productivity, I had to be bashed in the face with this information before it really sunk in.

I finally found the answer as to why I couldn’t find any pertinent info about user migration on Google – from, you guessed it, Stack Exchange:

“Oh,” I found myself thinking. “Duh.”

Just to be sure, I walked down the hall to our senior Swift dev’s cubicle. She was talking to our CEO, who was sitting on the comfy red couch we like to gather around, their conversation about some company growth we’ve experienced recently.

“Sorry for interrupting,” I began. “but I have a question…”

We shared a laugh, them laughing at the situation, me laughing at my own expense. If you can’t laugh at yourself, you’ll never laugh again, after all.

They quickly responded with the exact reasons listed in the Stack Exchange answer, while I nodded along.

As if the universe wanted to ensure that user migration was a non-issue, our CEO reminded me of another fact – DIY app builders like Appy Pie (again, I don’t hate you Appy Pie) retain the rights to the entirety of the code of your app – so if you outgrow their services and want to make a new app, you’re starting from scratch anyway. Because the law.

Luckily, the best part about a content wheel is you have the next six months of your professional life planned out, so I told our CEO I’d just move on to the next blog topic we had strategized on.

“Write something about this,” he said.