Hello again. I recently got laid off from a position I was trying to make work for myself as a Business Intelligence Analyst. Once the manager who hired me, himself left the company 3-4 months into my position, the time budget to train me on a legacy accounting system dwindled to 5 minutes question time two out of every three days as the talented professional training me was then promoted to the whole other job of running IT.

I struggled with how the inventory part of the system worked, took extra time to get acclimated, and then the axe fell just as I was beginning to understand it. I’ve been fired before, the first time when I was weeding flowers (slowly in the afternoon, after blowing away everyone in the morning) at Lew’s Nursery, age 13.

This wasn’t that.

They needed more than what I was originally hired for; they said so at my exit interview. (I probably should have faced that down earlier and looked for an exit.) No hard feelings, either way. Seriously – my trainer/manager has offered to speak on my behalf as a reference.

It wasn’t convenient; it never is. It begins another gap in the experience on my CV, hopefully short. But I learned SO much. It even improved my writing.

The most poignant thing I think I learned (in a professional context) was, TL:DR is real. Just because you can write much, doesn’t mean you always should.

Part of my old job involved walking the production floor every morning and making sure the monitoring was right. Problems were usually some form of wrong selection on the console at any line. I would take note, which line, which job, which problem, and report that to a list of managers and executives. They’d eventually clear up, and I’d release a day or two of “no anomalies detected” reports, and then it would happen again.

In my first reports, I used to try to explain what had gone wrong. That got corrected almost immediately; nobody needed my take on that! I stopped reporting minutiae like minor quibbles in actual headcount, and sticking to correctible things like ending the clock before you go home.

My new brevity was complimented, rewarded, and reacted to, positively.

Nextly, use your existing data to check yourself. That applies not only to matching figures, such as on an Excel sheet, but also to the history, the truth and the circumstances you’ve encountered around you. Past is prologue and precedent, to misuse a quote, but it is, even for technical problems and common errors.

On the reporting side, I’d need to start by tuning a SQL query so that it matched the numbers out of the accounting system, being presented the accounting system’s way to the 4 people the accounting system had authorized. This involved such devices as selecting, SUMming or AVGing a particular field, sometimes out of two or three options of similar columns that Could Be the right one. The PDF copy of the proprietary data dictionary was appreciated greatly, but not as good as someone else’s prior knowledge to help you.

So when I’d nailed the numbers and understood my subject, I wanted to save that for always and forever. I might get peeled off to another subject area on my next project, only to come back to the original area weeks or even months later. My SQL Server directory in Documents on OneDrive grew to 50, then 100 queries, with long, descriptive titles, so that I could keep track of them from File Manager windows.

For writing, that is also true. Things you’ve explained before, even if you have to tweak them for modernity, still have value. You might need something you wrote very well a while ago for a similar problem. So, save your work. Since you want your best work in a shareable version, you can remove the proprietary information, but the thoughts, and the words came from you, and they demonstrate your talent as a writer. So, you should use them.

I have scripts and articles I wrote and then recorded for a help system at the job before this last one. Since they belong to the company, and that departure was abrupt, I can’t access them. But they are still my best work in Technical Writing, for now. I have a glowing blurb of reference from my then-manager about those, but it’s not the same.

I may try to recreate something like that in Loom.

I left this last job at its root because there wasn’t real training and very little help in the moment to do it, but I’ll also admit to being discouraged by the lack of help to the point I didn’t always ask for it, especially when I got stuck.

I’m not a SQL DBA, but if I’m not careful, what I was allowed to do could break replication, if I made some stupid mistake like failing to properly temp my tables before inserting, etc. That brought the wrong kind of attention, and then often extra restorative work that precluded discussing any query issue for the time being.

To mitigate the times when I got stuck, I would step away from the problem, and attempt to flush my mind by catching up on email or reading an article on a different topic. Frequently, I successfully re-engaged and solved the problem, but this also got flagged as inactivity when the wrong people saw it. I explained what I was doing, but it brought unnecessary friction to any prospect of the training process, and required extra understanding from my manager.

Don’t make my mistake: Always ask for help when you need it. Whenever you need it. If a helper cannot get to you now, usually they’ll either route you to one who can, or they’ll set a schedule. My manager would often have me work on another project until he could get 15 minutes to dive into the issue on this one. It’s expected you won’t know everything, every time.

People like me forget that sometimes and get nervous to bother someone, and all of us need to stop.

But I certainly can write a PIVOT query and APPLY aggregate functions to single rows, now. I got that going for me.