Naming convention decision

Final name: tfstate-{AccountId}-{GitHubRepo}

Example: tfstate-123456789012-aws-foundations

Why this name

The convention earns its structure because I’m committing to one terraform state bucket per project.

So, the three pieces of information communicated in the bucket name:

The convention scales cleanly: every future infrastructure repository gets tfstate-{AccountId}-{GitHubRepo}, with no naming decisions to revisit.

Options considered and why they were rejected

tfstate-aws-foundations

Not globally unique, and almost certainly already taken thanks to the known limitation of S3. It also encodes the github project name in a bucket originally conceived as potentially holding all account state. Once my intent changed, the name became misleading.

tfstate-{AccountId} (original)

Unique and future-proof, but loses the repo link. Fine if one bucket holds state for many projects; less good when the bucket is scoped 1:1 to a single repo, where the link has real navigational value.

{AccountId}-aws-foundations

Globally unique, still links to the repo. But without a tfstate indicator, anyone browsing S3 has no immediate signal about what the bucket is for. The AccountId prefix also groups infrastructure buckets together when sorted, at the cost of reading unnaturally left-to-right.

aws-foundations-{AccountId}

More readable than the account-first example, same repo link. Still missing the tfstate indicator.

tfstate-{AccountId}-aws-foundations (chosen)

Purpose is obvious. Guaranteed to be unique. The 1:1 GitHub mapping is perfect. The tradeoff: twelve digits in the middle makes the name long and not great to say out loud. That cost is low because this string gets typed approximately twice in the bucket’s lifetime – at creation and in versions.tf – so conversational readability is not important.

Convention going forward

tfstate-{AccountId}-{GitHubRepo}

Other projects I create that require aws infra will each get their own S3 state bucket following this pattern.

This gives me state isolation between projects; a terraform mistake in one project cannot affect another, and state files stay small and fast.

I think that’s only half the story.

Chasing threads is about following inspiration when it strikes.

During my induction week as a graduate engineer, over seven years ago, I was told a story about our CEO. It’s where I first felt encouraged to be curious at work.

The CEO had a planned visit to one of our front-line Telco stores. All staff were prepped with questions and had a stacked agenda for photos and content capture. When the boss arrived, he spotted a staff member off to the side, absorbed in something (repairing a device, restocking a shelf) I can’t quite remember.

He walked over and simply asked: “Hey what are you doing?”

Whoever this person was, they spoke about what they were doing with such genuine passion and joy that the CEO scrapped the rest of the agenda entirely. He spent the whole visit just talking with this one person about technology, about their goals, about what they loved about the job.

That conversation turned into a friendship. They kept in touch across the year. And eventually, that staff member grew into a role back at headquarters. All because the boss saw someone doing something that looked interesting, and went and spoke to them.

Do you know the feeling? You’re reading something and a word catches you, you look it up, and suddenly you’re twenty minutes deep into the history of something you never knew you cared about.

The conventional wisdom says to ignore that. To get back on task and stay on track.

But what if the thread is the track?

Here’s the reframe I often come back to: life is distractions. It’s the distractions the give life meaning. Not in the doom-scrolling-at-2am sense. In the sense that the interesting stuff, the stuff that actually shapes who you are, rarely arrives through the front door. It sneaks up on you. It’s the thing you weren’t supposed to be doing that ends up mattering most.

Steve Jobs is probably the most famous example of this. In his 2005 Stanford commencement speech, he talked about dropping in on a calligraphy class at Reed College out of pure curioisty, with no practical application in mind. A decade later, that class became the foundation for the beautiful typography of the first Macintosh.

He didn’t chase calligraphy because it was strategic. He chased it because it pulled at him. Same instinct as a CEO who walks past a stacked agenda to talk to someone doing something interesting. Same instinct as anyone who follows a word into a twenty-minute rabbit hole and comes out knowing something they didn’t expect to care about.

But I have to be honest with myself, because this idea has a dark twin. Something a colleague of mine introduced me to because I was chasing the latest technologies all the time.

There’s a concept called Shiny Object Syndrome. The idea that some people —especially curious, creative, entrepreneurial types— get so drawn to the next interesting thing that they never actually go deep on anything. They bounce from project to project, tool to tool, always chasing novelty, never building something real.

I’ve been there. Most curious people have. You pick up a thread and it leads you to another thread, and another, and before you know it you’ve spent a whole day falling down rabbit holes and nothing is finished.

The shiny ball of yarn is real. And if you’re not careful, chasing threads becomes a sophisticated-sounding excuse for avoiding the hard, slow, unglamorous work of actually finishing things.

The difference between a thread worth chasing and a shiny object isn’t obvious in the moment; but it becomes clear with a bit of distance. If you park an idea for a few days and it’s still pulling at you, it’s probably a thread worth chasing. If you forget about it, then it probably wasn’t worth following anyway.

So go chase your own threads. Not all of them and not recklessly. But when something tugs at you, don’t immediately dismiss it as a distraction.

meta – Posts about this site itself – announcements, changes, meta type entries. Use when: the post is about the website or process specifically, not a topic within it.

ai – Artificial intelligence, large language models, and how I’m using them in work or writing. Use when: the post is primarily about AI tools, AI tech, or AI behaviour

career – Work, professional growth, team dynamics, and lessons from the industry. Use when: the post reflects on the people side of software – roles, culture, collaboration.

communication – Explaining ideas about communicating, for example to non-technical audiences, across teams, or in documentation. Use when: the post is about how we convey information to other people.

conference – Notes and reflections from conferences I attend. Any conference I go to gets written up here. Use when: the post is about a conference or event I attended, its talks, and what I took away from it.

definitions – Posts that define how I use a specific term, phrase, or concept – personal vocab entries. Use when: the post is structured around explaining what something means to me.

devops – Platform engineering, infrastructure, CI/CD, and the operational side of software. Use when: the post is about systems, pipelines, or keeping things running.

devtools – Tools that shape how I work - editors, CLIs, SSH, local setup. Use when: the post is hands-on with a specific tool or workflow.

writing – Reflections on the writing process, publishing, and finding my voice. Use when: the post is about writing itself, not just a post that happens to be well-written.