Lessons Learned

My last employer went through a round of lay-offs in mid-Dec. 2020 and I got whacked. No biggie – I’ve been here before (I’m looking at you, 2001 dot bomb).

With a few months away from the job now, I find myself reflecting on my time there, trying to draw some lessons from the experience. While none of these are mind-blowing, perhaps some of them will ring true to you in your endeavors.

Disclaimer: some of these are first-hand, some aren’t. I won’t say which are which 🙂.

Find an ally

Companies are unique in how they function as an organism and coming in to one as a newbie can be a bit daunting. While you could figure it out on your own, seeking out allies who you feel safe posing questions to will turbo charge your ability to get up-to-speed.

This is something that isn’t just for the sake of onboarding, either – finding people whose opinions and input you value will benefit you for the duration of your career.

Pick your battles

We all want to be assertive as a way of proving our value. But be careful how you do it – you don’t know what things are important or valuable to your co-workers and spouting your mouth off about X or Y could cause more harm then good.

Be prepared to “own” it

We often find ourselves fronting projects that are based on the input and expertise of others. Make sure you agree with their directives because, if you don’t, when it goes south you can’t very well say, “Yeah, well, we made those decisions based on that person’s input” – you just come off looking petty.

Be aware of this and have the hard conversations about why the input is incomplete and run it to ground. Do whatever you can to avoid putting yourself in that situation of having to defend a bad thought process.

Always give credit

I’m a big believer in this one – there will be times (hopefully many) when something will go well and you’ll get the credit for it. ALWAYS remember to loudly and publicly acknowledge anybody else who contributed to the effort, no matter how small.

This is nothing but a win/win: it takes nothing away from your accomplishment, it shows humility and openness and it lets those people know that you see their contribution and consider it valuable. People want to work with others who make them feel that way.

This is a ridiculously obvious principle but it stuns me how frequently it’s overlooked.

Be transparent with your teammates

When you’re in anything other than an entry-level position, you’re making decisions that affect others. It’s really important to make a constant, consistent effort to inform the team what you’re doing, why you’re doing it and when it’s going to happen.

You’ll be surprised at how often someone you might not expect will have some great input and expertise.

Be aware of your own bias

I’ve been in IT long enough and worked on enough different facets of the profession that I’ve developed my own “comfort zones” when it comes to solutions. It’s easy to want to downplay something new with “Well, what is that really doing that our current solutions isn’t already doing?”

Be aware of this in yourself and do whatever you can to lean into it – better to fully explore the option you think you know then to cut it off at the kneecaps prematurely.

It’s almost always process, not tools

I left this last because, in some ways, it’s the most important of all. As IT professionals, we’re frequently tasked with fixing existing systems. Oftentimes, the blame goes to the tool itself – “The interface is impossible,” “It doesn’t let me break it by doing this thing I need to do that it wasn’t designed for,” etc.

More often than not, it’s not the tool but the process being followed (or not followed) by the staff using the tool. Perhaps there’s a lack of training. Perhaps nobody’s ever thought to revisit the communication process. Perhaps one link in the chain insists on using an out-of-date app to do their part and it’s gumming up the works.

Always use “This isn’t working the way we need it to” as an opportunity to re-evaluate the process first – there’s usually a way to fix it without incurring cost while bringing the parties together to re-think how they work together (which can be a valuable team building exercise in-and-of itself).

Read More

The Dummy’s Guide to DMARC (Pt. 1 of 2)

Who is this for?
If you use a free email service like GMail, Yahoo, Outlook, etc. then this doesn’t apply to you – DMARC configuration only applies to those with their own domain and access to its associated DNS records.

DMARC is something I was first introduced to at my last job and, to be entirely honest, I never quite wrapped my head around the concept. However, a recent personal experience forced me to revisit it and I managed to unlock its secrets!

Honestly, DMARC isn’t really all that complicated. Basically, it’s primarily a reporting protocol that actually monitors two other authentication processes – SPF and DKIM – and then takes the next step by proactively recommending an action based on those results.

The main idea behind all three of these acronyms is to set up your mail server to ensure that bad actors out there are unable to spoof your domain and send spam/phishing messages that appear to come from you.

The easiest way to illustrate this is to briefly explain each of the three acronyms (and their function):


Sender Policy Framework is a method where a receiving e-mail server will check back with the source domain and confirm that the message was sent through one of a list of “verified SMTP servers.”

SPF isn’t foolproof, as spammers have learned how to tweak message header info to make the receiving server believe that the source IP matches the real SPF record. But it’s a start.

An example of a SPF record added to a domain’s DNS could be:

v=spf1 include:_spf.google.com ~all

Further Reference:


Domain Keys Identified Message involves the generation of a key for inclusion in the sending domain’s DNS records. The sending domain then “digitally signs” each message sent – any receiving server will verify this signature with the key of the sending server.

Generating a valid DKIM record for your domain involves digging into your domain provider’s admin console, but a simple example of a DKIM record added to a domain’s DNS could be:

v=DKIM1; k=rsa; p=<uniqueHash>

Further Reference:


Domain-based Message Authentication, Reporting and Conformance is a protocol designed to provide you with reporting feedback from receiving servers and to tell those servers what they should do when they receive a message (supposedly) from your domain that fails one or more authentication tests (like SPF or DKIM!).

An example of a DMARC record would be:

v=DMARC1; p=reject; rua=mailto:reporting@foo.com; ruf=mailto:reporting@foo.com;

where “p=” indicates the desired action (options are none, quarantine or reject), “rua=” indicates an email address to send aggregate reports about received messages to and “ruf=” indicates an email address to send forensic reports to.

Further Reference:


Now that we’ve explained the basics, stay tuned for Part Two of “The Dummy’s Guide to DMARC” where we’ll cover how to implement this in your own environment!

Read More

Pulling the ripcord on Google Keep

After consolidating my assorted online notes to Google Keep at the very beginning of this year and working with it for all of 2020, I finally decided to concede defeat and accept that I kind of hate it as a tool.

Between the horse-y way it presents your note collection as large, asymmetrical blocks and the fact that the note editor doesn’t provide even basic formatting options, it simply wasn’t doing the trick for me.

So, after deciding to commit to Evernote (I tool that I used to use erratically a number of years back), I set out to figure out how to move all of my Keep notes to it.

While Evernote doesn’t have a direct “import from Google Keep” function built-in, they DO provide basic instructions. And, by ‘basic’ I mean ‘useless.’

A bit of digging reveals that Evernote can import files in .enex (Evernote XML) format so, if you can get your exported notes into that then you’re in business.

Fortunately, some clever bugger has already figured out how to do this specifically for Google Keep exports: Charles Roberto Canato has posted a Python script to GitLab that handles this for you.

The instructions are a little incomplete so, for those of you who might need some extra pointers:

  1. This script will require you to first unzip the file you download from Google Takeout
  2. The version of python bundled with my clean install of macOS 10.11 “Big Sur” didn’t include the parsedatetime module, so run sudo python3 -m pip install parsedatetime to resolve that
  3. I found that the script didn’t produce an .enex file unless you explicitly specify an output file, despite the fact that Step 4a in the script’s README.md file says this is optional

Evernote did an excellent job of importing all of my notes (including the tags I’d assigned them in Keep) so, from there, it’s just a matter of spending some time setting up appropriate notebooks (don’t miss the ability to “stack” notebooks into categories!) and then shuffle your notes around as necessary!

Read More