Month: October 2023

Keep It Secret, Keep It Safe

Keep It Secret, Keep It Safe

By | | Comments 0 Comment

AWS recently announced that blocking public access to published AMIs will be enabled by default. This is good news, as it’s an easy way to accidentally leak sensitive data. When I first started using GovCloud (2015 maybe?) I remember stumbling into a set of AMIs that, based on their names alone, clearly weren’t intended to be shared. Thankfully a quick note to AWS support and the offending party squared things away post haste, though I’ll never know if damage had already been done.

Horror stories are easily found online of the easiest way to make this mistake: turning on public access to an S3 bucket. Thankfully AWS has made taking this step difficult; in our internal accounts, in fact, without getting prior approval, creating a bucket with public access would get you a Sev-2 page in about 15 minutes. Unfun.

Which is why I found it so surprising to discover that in GCP, the only way I can tell to host a static website behind a CDN is to make the backing cloud storage bucket public. I mean, I recognize by definition it’s okay for the data to be Internet-accessible, but it meant turning off the “don’t allow public cloud storage” block project-wide, which seems a bad idea. Bad enough that the moment I hit that button I got a security warning via email. Am I missing something here? Would love to know if there’s a better way.

In any case, it’s going to be an adventure learning all these subtle differences as I broaden my cloud experience. Passing certifications is nice, but it’s no substitute for kicking the tires.

(Editor’s Note: I’m chuckling to myself as I add Amazon LP tags to a post that’s partly about GCP. Those things are burned into my brain forever).

Clear Eyes, Full Hearts

Clear Eyes, Full Hearts

By | | Comments 1 comment

Amazon promotions require “best reasons not to promote” to be documented, both from a manager and from any colleague who provides formal feedback. Arguably it was the most important part of the process, because it demonstrated that input came from individuals who could see the candidate clearly enough to speak honestly about both their strengths and their shortcomings.

When coaching candidates for promotion, I recommended they write their own version of that section, and then we’d review theirs alongside my own. Why? Because if you shy away from your deficiencies, you have no counterargument to them. They’re going to be found out anyways by any competent promotion evaluators, so why not get ahead of the curve.

I don’t pretend this is easy, especially for people who have battled insecurities or have lacked encouraging support throughout their careers. But it’s essential for making meaningful career progress. When advocating for yourself, look your shortcomings straight in the eye.

There isn’t a day that goes by that I don’t miss my Dad, but this week I’ve been particularly reminded of him being the reason I rarely feel insecure in naming my professional weaknesses. What a tremendous gift from a parent, the words “I love you” and “I’m proud of you” spoken aloud, simply and frequently. I must have heard those words hundreds of times. Thousands. So often that their truth got into my bones. I believed him then, and I still do now, even though he’s gone. Thanks Dad.

Cerberus

Cerberus

By | | Comments 1 comment

I’m coming up on six months since I took the CTO job at RIPL. Enough time to meet the team and get settled in, even bring a few tactical benefits that solve immediate needs. But the real work begins now, that of strategic planning that sets us up for long-term success.

Operating in a C-Suite is new to me. I don’t have a point of comparison, but so far it’s been great. Between the three of us we have a well-distributed set of skills and experiences, which means we can lean into our strengths while knowing the others have our blind spots covered. In many ways we’re operating as a coalition of equals more than a hierarchy; of course there’s deference when required, but the level of mutual trust is such that it doesn’t really come up often. And I genuinely enjoy the company (in both senses of the term). Not sure if this is rare or common, but I’m grateful either way.

Perhaps this is how the best leadership teams operate, more like a unified whole than a siloed set of individuals? It’s an idea worth exploring further; the Freakonomics episode Are Two CEOs Better Than One is probably where I’ll start.

A corollary to the above, especially given I’m the oldest person in the group (a fact worthy of its own post), is that finding mentorship from professionals with more experience in my role means that I have to look to sources outside my employer. It’s why I’m trying to build a better professional network through activities like starting 4S Tech, attending CTO Lunches, joining the Rand Leadership Slack, and taking a tech ethics class. I consider these efforts part of my job, because I owe it to my company to develop myself further.

Like Tears In Rain

Like Tears In Rain

By | | Comments 1 comment

It was six months ago now, but I clearly remember the feeling of sitting with my AWS laptop on a Friday morning, knowing it was the last time I’d use it. There’s a surprisingly emotional bond that develops between a technologist and their equipment; I was genuinely sad about turning it in. But handing over the hardware wasn’t the worst part, it was knowing that every digital file I’d created on that laptop would be erased, thus anything I hadn’t transferred to someone else or otherwise handed off for preservation would be gone forever: every half-completed business idea one-pager, all my customer presentations, any little code utilities I’d built. Everything. Four years worth of accumulated artifacts is no small thing, and I didn’t want to see it disappear.

I was in this same situation back in 2014 when I left my first job, and at the time, for confidentiality and security reasons, I’d done nothing I could publish publicly or otherwise take with me. That was unfortunate, and I didn’t want to repeat that disorienting experience. Thankfully during my AWS tenure I’d taken steps to release whatever I could via open source mechanisms. And what I couldn’t directly publish, I’ve tried to capture after the fact on this blog, including this post on how to approach certifications (reconstructed from a talk I gave at an internal conference), my advice on brag documents (also from a talk), and a process for doing project estimation (rewritten by memory from a team wiki page).

Don’t make the mistake I did and wait until the 15 year point of my career to take these sort of steps. And don’t wait until you’re at the end of your time at a company either; like documenting your accomplishments, archival work is best done in real-time. Embracing open source development can help, even more so if your employer is onboard. Push them if you need to (you can find some talking points in this excellent article).

A final argument: continuous improvement is predicated on retention. “Those who cannot remember the past are condemned to repeat it” applies not just to history, and the DRY principle applies across both spatial and temporal dimensions. Or even more simply: save your work!

Terminus

Terminus

By | | Comments 0 Comment

Ending conversations is always a bit awkward, whether it be in-person goodbyes, the “uh, are we done?” Zoom meeting closer, or wondering if an email chain needs a final “Thanks” acknowledgement.

Real-time text-based exchanges are particularly tough. Here’s my question: is an emoji response a sufficient message that “yes I got your message, I’m acknowledging that, but I’m not keen to talk further”? Is the vibe different if I send the emoji as a standalone response vs applying the emoji as a reaction to the last message I received?

Need some help from someone in the know, which probably means someone younger than myself.