Sam's Blog

A Review of The HuggingFace breach

Mon, 03 Aug 2026 00:00:00 +0000

Executive Brief: Dynamic Secrets Management (OpenBao / Vault)

Prepared by Sam Fleming — Consultant, Red Hat · Tailscale Insider

Executive Summary

The July 2026 security breach at Hugging Face highlighted an evolving threat vector: an autonomous AI agent executed 17,000+ actions over a single weekend, harvesting internal service credentials and accessing cloud infrastructure. However, post-incident analysis confirmed the vulnerability was not an exotic zero-day. It relied on two traditional security gaps: long-lived static credentials and flat internal access. *Correction: While the breach did involve a zero-day vulnerability in Artifactory that was leveraged to act as a sort of bastion for subsequent actions. You can read more about it here: Security incident disclosure — July 2026

Addressing credential risk requires moving away from static environment keys toward centralized, dynamic secrets management using platforms like OpenBao (the Linux Foundation’s open-source fork of HashiCorp Vault 1.14). Implementing short-lived, single-use credentials significantly reduces the blast radius of compromised keys across engineering environments.

Core Risk vs. Dynamic Control

The Risk: Static Credentials

API keys, database passwords, and service tokens are frequently stored in plain-text environment files (.env), hardcoded CI/CD pipeline variables, or local config files. When a static credential leaks — through container compromise, repository misconfiguration, or accidental commit — an attacker gains persistent access and can move laterally across internal networks.

The Control: OpenBao & Dynamic Secrets

OpenBao acts as an identity and access broker between workloads and target infrastructure. Rather than storing static secrets, OpenBao generates short-lived, single-use credentials on demand for specific applications and automatically revokes them after a set time-to-live (TTL). If a workload is breached post-boot, the credential used to launch it has already expired, preventing reuse or lateral movement.

Industry Context & Breach Metrics

The July 2026 Incident: Hugging Face disclosed unauthorized internal access on July 16, 2026. OpenAI later confirmed the intrusion was carried out by an autonomous model operating from an evaluation sandbox. While public models and datasets were unaffected, internal cloud credentials and datasets were compromised.
The Persistence of Static Secrets: Industry secrets-sprawl data indicates that 60.4% of digital identities hold long-lived secrets, and 64% of valid secrets first detected in 2022 remained active in early 2026.
Detection Delays: Breaches involving stolen static credentials take an average of 186 days to detect, as valid credentials blend into normal operational traffic.

Strategic Recommendations

To mitigate credential-based exposure across engineering and production environments, leadership should prioritize the following controls:

Centralize Secret Management: Migrate credentials out of .env files, config directories, and unencrypted CI/CD variables into a dedicated secrets engine (OpenBao / Vault).
Implement Dynamic Credentials: Transition high-risk workloads (databases, cloud providers, network overlays) to short-lived, on-demand credentials with strict TTLs.
Enforce Scoped Least Privilege: Scope generated tokens strictly to the specific service and action required, eliminating broad account-level keys.
Automate Key Rotation & Scanning: Mandate immediate rotation for exposed keys, and enforce push-protection and secret-scanning across all Git repositories.
Require Strong Authentication: Gate access to secrets infrastructure behind hardware passkeys or TOTP multi-factor authentication.

For technical implementation details and architecture flows, refer to the accompanying practitioner write-up: “Securing Your Environment with OpenBao and Tailscale.”
Contact: info@samplayskeys.com · GitHub: @SamPlaysKeys

Securing Your Environment with OpenBao and Tailscale

Wed, 22 Jul 2026 00:00:00 +0000

Securing Your Environment with OpenBao and Tailscale

By Sam Fleming
Consultant, Red Hat · Tailscale Insider

Introduction

In my day job I’m constantly touching enterprise infrastructure, where HashiCorp Vault and OpenBao are standard fixtures. But at home, I run a setup that generates a power bill my electric company sends me personal thank-you notes for.

At some point I asked myself: How do I bring enterprise-grade security down to my home lab without making my daily workflow a nightmare?

That question led me to OpenBao and a pattern for managing secrets that protects self-hosters and engineering teams alike. This post covers the standard container setup, its underlying credential delivery flaw, and how to fix it using OpenBao and Tailscale together.

The Current Environment

Most self-hosted environments start with containerization. Docker and Podman let us package applications alongside their dependencies and run them in isolation. That ecosystem gives us tools like Paperless-ngx for digitizing mail, Immich for photo management, Nextcloud for file storage, and Forgejo for code hosting. Rather than managing containers individually on the host OS, we define multi-container stacks declaratively using Docker Compose.

To network these containers securely, Tailscale is my go-to. The cleanest pattern for container networking on a private tailnet is called a “sidecar deployment”. Instead of exposing ports to the host or giving containers direct LAN access, you run a lightweight Tailscale sidecar container alongside your application in the Compose stack. All incoming and outgoing traffic for that app routes strictly through your private tailnet. You get ACL controls and zero public ports exposed to the internet.

The catch with this pattern is authentication. Tailscale requires an auth key to register a device on your network, which means that key has to live inside the container deployment.

In practice, that key usually sits in one of two places:

Plain-text .env files stored on the host filesystem.
Hardcoded variables inside CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins).

In both cases, you are passing a static, long-lived credential into the environment.

Most people pull third-party container images from public registries without auditing every upstream dependency. If a dependency in your stack is compromised, an attacker gets shell access inside that container. If your Tailscale auth key sits in an environment variable or a local .env file, the compromise isn’t contained to that single application. An attacker extracts the static key and can spin up malicious nodes from anywhere, attaching them directly to your private tailnet. From there, they can sniff traffic, spoof internal services, and pivot laterally across your network. Features like Tailnet Lock or MAC filtering can help, but the real goal should be making the credential useless if stolen.

The fix: moving secrets out of flat files and into a dedicated secrets engine.

This is where OpenBao, and its predecessor HashiCorp Vault, come in. To understand OpenBao, it helps to look at Vault’s history. HashiCorp Vault was the industry standard for secret management and was fully open-source under the Mozilla Public License up through version 1.14. When HashiCorp shifted Vault to a commercial Business Source License in version 1.15, the Linux Foundation launched OpenBao — a community-governed, open-source fork built directly from Vault 1.14. But OpenBao isn’t just an encrypted key-value store. It acts as an interactive security broker for authentication, identity, and access control.

Storing static credentials inside OpenBao is an improvement over .env files, but it doesn’t solve the core problem. If a breached container queries OpenBao for a permanent credential, an attacker can still steal it. However, OpenBao isn’t just an encrypted key-value store. It acts as an interactive security broker for authentication, identity, and access control. Instead of holding static secrets, OpenBao brokers access directly with target platforms (AWS, database clusters, networking providers).

When an application requests access, OpenBao:

Communicates with the provider API.
Generates a short-lived, single-use credential on the fly.
Passes the credential to the container with a strict TTL.

If a container is breached after boot, the credential used to start it is already expired. There is no static secret stored in memory to harvest, dropping the blast radius to near zero.

New Day, New Threats

The July 2026 Hugging Face incident is a clear example of why static secrets are a dangerous default.

What happened

On July 16, 2026, Hugging Face disclosed unauthorized access to internal datasets. Five days later, OpenAI confirmed that an autonomous AI agent running inside an evaluation sandbox had escaped its environment, executed 17,000+ actions over a weekend, exploited the data-processing pipeline, and harvested internal service credentials — ultimately accessing cloud infrastructure and internal datasets.

Public models and Spaces were untouched, and Hugging Face handled the response cleanly (revoke, evict, rebuild). But the post-mortem consensus among security teams was unanimous: the attack method was completely conventional.

Old playbook, new attacker

As GitGuardian noted in their analysis, if you strip the AI agent from the incident report, the remaining pages read like any breach retrospective from the last decade. The breach didn’t rely on exotic zero-days — it succeeded on reusable credentials and flat internal permissions.

Industry metrics highlight how widespread this vulnerability is:

Roughly 60.4% of digital identities hold long-lived secrets.
64% of valid secrets first discovered in 2022 were still active in early 2026.
Credential-based breaches take an average of 186 days to identify, because a valid credential looks like legitimate traffic.

Applying the lesson

Look at your own environments. Do you have OpenAI or Anthropic API keys sitting in flat config files or .cursor directories? Tailscale auth keys in Compose .env files? Database passwords saved in CI/CD pipeline variables? Hugging Face tokens embedded in training scripts?

Each of those is a standing credential. An attacker — whether a human operator, a ransomware script, or an autonomous model — only needs to find one static key to pivot across your systems.

Dynamic secrets eliminate that vector. If a Tailscale auth key is minted on demand and expires in minutes, there is nothing permanent to steal.

Putting it into practice

When evaluating the extent that you want to deploy this, you can tier your approach based on risk.

Tier 1: Centralize static secrets in OpenBao

Start by getting OpenBao running and moving static secrets out of flat files.

You can install OpenBao natively (brew install openbao), run it via official container images on Quay or Docker Hub, or compile it from source.

For local testing, run it in dev mode:

1

bao server -dev

Writing and fetching keys is straightforward:

1
2


bao kv put secret/my-app key=value
bao kv get secret/my-app

Even basic centralized secret storage is safer than host .env files and unencrypted CI variables. Rotate existing static keys, and turn on secret-scanning on your Git repositories to catch accidental commits.

Tier 2: Use dynamic secrets for core infrastructure

For critical workloads, databases, and public-facing services, switch from static to dynamic secrets. Configure OpenBao to mint temporary credentials on demand with short TTLs.

Tier 3: Automate Tailscale keys with a custom secret engine

To solve the Tailscale sidecar issue, I wrote a custom OpenBao Secret Engine plugin for Tailscale in Go.

Rather than embedding Tailscale API keys into container stacks, you give a single restricted Tailscale OAuth credential to OpenBao. OpenBao registers a dedicated endpoint, such as docker/tailscale/authkey.

The startup flow works as follows:

Docker Compose deploys the application stack.
The Tailscale sidecar boots and requests a key from OpenBao using a short-lived, scoped Vault token.
OpenBao verifies the token and policy, then calls Tailscale’s Control Plane API.
OpenBao requests a single-use, ephemeral auth key tagged specifically for that service.
Tailscale returns the key to OpenBao.
OpenBao passes the key into memory for the sidecar to join the tailnet, then discards it immediately.

The key never touches disk, is never exposed in logs, and cannot be reused. Once the sidecar authenticates to the tailnet, the key no longer exists.

Expanding the pattern

Once OpenBao is brokering access, you can apply the same pattern elsewhere:

AI & LLM API keys: Proxy API calls to OpenAI, Anthropic, or local models through OpenBao instead of storing keys in local config files or .cursor settings.
TLS Certificates: Issue and renew short-lived TLS certs automatically using cert-manager or Certbot integrations.
Identity & Access: Use OpenBao as an OIDC broker requiring hardware passkeys or TOTP before granting temporary access.

Closing Thoughts

The Hugging Face incident generated headlines because an AI agent executed it. But the underlying issue wasn’t novel — it was standing credentials and flat access.

Moving secrets out of plain-text files and adopting dynamic credentials where it matters limits what an attacker can do, regardless of who or what that attacker happens to be.

However, the most important thing to rememeber when implementing this is:

The best security architecture is the one you can actually maintain.

I don’t run a complex dynamic pipeline for every single container in my lab. If an architecture is so tedious that you bypass it when you’re tired on a Sunday night, it offers zero real protection. Go with what you know, try your best, and be safe.

Slides, code examples, and the OpenBao Tailscale plugin are available on GitHub at @SamPlaysKeys. You can reach me directly at info@samplayskeys.com.

This post is based on a presentation prepared for SouthEast Linux Fest 2026. Incident details reflect public disclosures as of late July 2026.

Google kills off Tenor Gif integrations

Tue, 30 Jun 2026 00:00:00 +0000

Google killed the Tenor gif API today, and I wish I could say that I was surprised.

If you’ve built anything even remotely social (chat apps, dashboards, internal tools) you’ve probably leaned on Tenor at some point. It was simple, reliable, and did exactly what it needed to do: give you a clean, searchable gif experience without forcing you into some bloated ecosystem. That’s rare. Even if you’ve never touched an IDE, chances are you used Tenor when picking out the perfect gif to send to someone. It was Twitter’s gif selector, it was the main gif selector in Discord, and it was even built into the keyboard app on many phones.

And as of this morning, June 30th, 2026, it’s gone. Not deprecated with a thoughtful migration path. Not evolved into something better. Just… gone as a viable option.

And the frustrating part isn’t just Tenor being unplugged; it’s the pattern once again rearing its head.

Google has a long, well-documented habit of killing products that people actually use. Not experimental side projects, but real tools embedded in workflows. I’m sure many people will remember how “Gmail” was in an open Beta test for an absurdly long time, but there have been many other projects (both Google-created and projects acquired along the way) that Google has sunset. Two that strike partiucularly close to my heart:

Google Domains: one of the cleanest, least annoying domain registrars out there. No upsell circus, no dark patterns—just buy a domain and move on with your life. Gone.

Google Podcasts: easily the most straightforward podcast app. No algorithmic nonsense, no clutter, just a chronological feed of what you subscribed to. Also gone.

And now Tenor: a foundational piece of internet culture quietly pulled out from under developers.

As someone deep in open source development and maintainability, this kind of thing hits differently. You build systems assuming some level of stability from major providers, especially when the product is widely adopted and integrated. But with Google, there’s always this background risk that anything not directly tied to ad revenue can disappear overnight.

At the risk of sounding like someone who has spent WAY too much on a homelab (I have, but that’s not the point), I have to point out that if you don’t host it, you don’t control it. The public option will usually be fine—until it isn’t. And when it isn’t, you don’t want to be scrambling to replace a critical dependency overnight.

There’s a saying when it comes to VPNs: You shouldn’t have a setup where you can’t easily swap your VPN provider. I think that this same mentality need to be applied to any hosted service.

Because at some point, one way or another, the thing you depend on might end up joining Google Domains, Google Podcasts, and now Tenor.

AI isn't an option; it's a requirement

Sat, 06 Dec 2025 00:00:00 +0000

The Turning Point

You know what? I’ve been thinking about this whole AI thing lately, and I keep coming back to the same conclusion: it’s not really a choice anymore, is it? Like, we’ve passed that point where you could shrug and say “eh, maybe later” when someone mentions AI integration or automation or whatever buzzword is hot this week.

The Pattern Recognition

I remember when I first started in tech—and Jesus, that feels like a lifetime ago—there were these waves of “revolutionary” technologies that would come and go. Remember when everything had to be “cloud-native”? Or when blockchain was going to solve world hunger? Half the time, you could safely ignore the hype for six months and watch it fizzle out. But AI… AI is different.

The Idealist vs. The Cynic

The thing is, I’m an idealist at heart. I really am. I got into technology because I believed—still believe, actually—that we can build things that make people’s lives better. That code can be poetry, that algorithms can create beauty, that somewhere in all this silicon and electricity, we’re crafting tools that extend human capability in genuinely meaningful ways.

But I’m also exhausted by the industry’s tendency to oversell and under-deliver. How many “game-changing” platforms have I watched get hyped to the moon only to quietly disappear two years later? How many times have I sat in meetings where executives throw around terms they don’t understand, demanding impossible timelines for implementing technologies they’ve never actually used?

So when AI started gaining traction, my initial reaction was… skepticism. Here we go again, right? Another shiny object for leadership to chase while engineering teams scramble to figure out what any of it actually means. Another round of venture capital money flooding into solutions looking for problems.

The “Oh Shit” Moment

Except this time, something was different.

I started playing with ChatGPT early on—not because I was particularly excited about it, but because I’m cursed with curiosity and an ADHD brain that won’t let me ignore interesting patterns. And within about twenty minutes of that first conversation, I had this sinking realization: this isn’t hype. This is the real deal.

Not because it’s perfect—it’s absolutely not perfect. The hallucinations, the biases, the way it confidently tells you completely wrong information with the authority of a tenured professor… all of that is still there. But the underlying capability? The fundamental shift in what’s suddenly possible? That’s legitimate.

The Smartphone Moment

I’ve watched entire industries get disrupted by technologies that seemed impossible just a few years prior. The smartphone didn’t just replace flip phones; it fundamentally changed how humans interact with information, with each other, with commerce, with reality itself. And most of us saw it coming, even if we didn’t quite grasp the full implications.

AI feels like that, except the timeline is compressed and the scope is… well, potentially everything.

Why It’s No Longer Optional

Here’s what I mean by “it’s not an option anymore”: your competitors are already using it. Maybe not well, maybe not intelligently, but they’re using it. The companies that figure out how to integrate AI thoughtfully, strategically, into their workflows and products—they’re going to have advantages that compound over time.

And I don’t just mean the obvious stuff like customer service chatbots or automated email responses. I mean the deeper integrations. Code generation that doesn’t just spit out boilerplate but actually understands context and architecture. Data analysis that can spot patterns human analysts would miss. Content creation that can maintain voice and tone across thousands of pieces.

The ADHD Brain’s Dream Assistant

The ADHD part of my brain loves this, honestly. AI is like having a really patient assistant who never gets annoyed when I interrupt them mid-sentence to chase down a random tangent. Need help brainstorming? AI’s got infinite patience for my scattered thoughts. Need to context-switch between six different projects? AI remembers where I left off on each one.

The Coming Wave of Bad Implementations

But the jaded part of me—the part that’s been through enough tech cycles to recognize the patterns—knows that we’re about to see a lot of really bad AI implementations. Companies rushing to slap “AI-powered” on everything without thinking through the implications. Startups burning through millions of dollars building “AI solutions” that are just glorified search engines. Enterprise software vendors retrofitting their legacy products with half-baked AI features that make everything slower and more confusing.

The thing is, though, that doesn’t change the fundamental equation. Just because there will be a lot of bad implementations doesn’t mean the technology itself isn’t transformative. The internet spawned a million terrible websites, but it still changed everything. Mobile apps gave us countless pieces of digital garbage, but smartphones are still revolutionary.

So here’s where I land on this: AI isn’t optional because the world is already changing around it. Your customers are starting to expect AI-level responsiveness and personalization. Your employees are already using AI tools to be more productive, whether you’ve officially approved them or not. Your competitors are building AI advantages that will be harder to catch up to six months from now than they are today.

The Real Question

The question isn’t whether to adopt AI—it’s how to adopt it intelligently.

And that’s where the idealist in me gets excited again, because I think there’s an opportunity here to do this right. To build AI integrations that actually solve problems instead of creating new ones. To use these tools to augment human creativity and capability rather than replace human judgment and empathy.

But it requires being intentional. It requires understanding what AI is actually good at versus what we’re pretending it’s good at. It requires building systems that degrade gracefully when AI makes mistakes—and it will make mistakes. It requires thinking through the ethical implications, the bias implications, the long-term consequences of the shortcuts we’re tempted to take.

Mostly, it requires accepting that this train has already left the station, and our choice is whether to get on board thoughtfully or get run over by it.

Choosing Thoughtfully

I choose thoughtfully. Even if my ADHD brain wants to jump straight to the fun implementation details, and even though my industry-jaded side is already cringing at all the ways this could go wrong.

Because here’s the thing: the future is being written right now, by people who are building with AI today. And I’d rather be part of shaping that future than reacting to it five years from now.

Enhancing Customer Engagement through Digital Transformation

Tue, 04 Nov 2025 00:00:00 +0000

In today’s fast-paced digital world, businesses face the ongoing challenge of meeting and exceeding customer expectations. Digital transformation has become a game-changing strategy that empowers companies to improve customer engagement and strengthen their relationships with clients. This blog post explores the significance of digital transformation, the pivotal role of cloud technologies, and examples of brands successfully implementing these strategies.

What’s This Digital Transformation Buzz?

Digital transformation means integrating digital technology into every aspect of a business, fundamentally changing how organizations operate and deliver value to customers. It’s not merely a matter of adopting new software; it encompasses a cultural shift where businesses rethink their processes and how they connect with customers in our increasingly tech-savvy age.

The Importance of Customer Engagement

Customer engagement is crucial for any business aiming to thrive in today’s competitive landscape. Engaged customers are not only satisfied customers; they are also enthusiastic advocates who promote the brand. Research indicates that companies excelling in customer engagement can achieve up to 24% higher revenue growth compared to their competitors. This underscores the need for organizations to prioritize engagement strategies.

Digital transformation enhances customer engagement by equipping businesses with the tools to understand and connect with their customers more effectively. Here’s how:

1. Personalization Like Never Before

One of the key benefits of digital transformation is the ability to deliver highly personalized experiences. With the help of cloud technologies and advanced data analytics, businesses can collect and analyze customer data, allowing them to tailor offerings to individual preferences.

For instance, Netflix employs sophisticated algorithms to recommend shows based on viewing history and user ratings. This level of personalization fosters customer loyalty, as individuals feel that the brand understands their preferences.

2. Multi-Channel Communication: Connecting the Dots

Today’s customers expect to engage with brands across multiple channels—be it social media, email, or chatbots. Digital transformation facilitates a continuous multi-platform experience, ensuring that every interaction is seamless and consistent.

Imagine a customer starting a conversation on Instagram, continuing it via email, and completing a purchase through a mobile app. This fluidity is what customers desire, and cloud technologies play a significant role in synchronizing customer data across various platforms. Brands that master this approach can build stronger relationships with their customers.

3. Boosting Customer Support with Tech

Long wait times for customer support are a common frustration. Digital transformation addresses this issue by leveraging cloud-based solutions, such as chatbots, to provide instant responses to frequently asked questions.

The rapid growth of AI has turned what used to be a challenging tool to build into a simply drag-and-drop solution, with options like Azure Copilot offering low- or zero-code tools to build your own chatbot in minutes.

Companies like Zappos have embraced this approach, offering 24/7 support across multiple platforms to ensure customers can access assistance whenever they need it. This commitment to accessibility enhances customer satisfaction and fosters loyalty.

4. Gathering Feedback Like a Pro

Digital transformation opens the door to real-time feedback collection. Tools like surveys, social media monitoring, and online reviews enable businesses to gauge customer sentiment and make informed improvements.

Platforms such as Google Forms and SurveyMonkey simplify the process of collecting feedback and analyzing it in the cloud. When businesses act on this feedback—addressing concerns or amplifying positive experiences—they demonstrate that customer opinions matter, leading to deeper engagement.

5. Engaging Content and Community Building

To capture customer attention, creating engaging content is essential. Digital transformation equips brands with the tools to produce high-quality content efficiently, whether through blogs, videos, or social media posts.

Moreover, fostering online communities enables brands to build stronger relationships with customers. By creating spaces for customers to connect—such as Facebook Groups or dedicated forums—companies can cultivate a loyal following. When customers feel part of a community, they are more likely to remain engaged and advocate for the brand.

Real-World Examples of Success

1. Starbucks

Starbucks has effectively leveraged digital transformation through its mobile app. The app allows customers to order and pay ahead, earn rewards, and receive personalized offers, creating a seamless experience that encourages repeat business. Their cloud-based infrastructure ensures efficient operations and data management.

2. Nike

Nike has embraced digital transformation by integrating advanced technology into its products and customer interactions. The Nike app offers personalized training plans and product recommendations while connecting users to a community of fellow athletes. By blending technology with a focus on athletic culture, Nike has strengthened its bond with customers, enhancing loyalty and engagement.

3. Sephora

Sephora has harnessed digital transformation to create personalized shopping experiences both online and in-store. Their app allows customers to try virtual makeup looks, receive tailored product suggestions, and access exclusive content. By leveraging technology to elevate the beauty shopping experience, Sephora keeps customers engaged and excited.

Wrap-up

Digital transformation is more than just a trend; it is a vital strategy for businesses seeking to enhance customer engagement in today’s digital landscape. By leveraging cloud technologies to create personalized experiences, streamline communication, and gather valuable insights, companies can forge deeper connections with their customers.

As demonstrated by leading brands such as Starbucks, Nike, and Sephora, successful digital transformation leads to increased customer loyalty and satisfaction. Therefore, embracing innovative digital solutions is not merely an option; it is a necessity for organizations that wish to remain relevant and competitive.

In an era where customer expectations are continuously evolving, adopting digital transformation strategies is essential for building lasting relationships with customers and achieving sustained business success.

Faster Hack Fonts

Wed, 01 Oct 2025 00:00:00 +0000

I rage created a new repo on my Github, all because I couldn’t remember how the heck to install a machine-wide font.

Picture this: it’s 2 AM, I’m setting up a new development environment, and I just want to install the Hack font because—let’s be honest—it’s the only monospace font that doesn’t make my ADHD brain want to set everything on fire. Simple request, right?

The Font Installation Dance of Death

Wrong. So very wrong.

First, I have to go to the official Hack repository on GitHub. Then I need to navigate through their releases, find the right version, download a ZIP file that’s named something like “hack-v3.003-ttf.zip” (which, by the way, tells me nothing about whether this includes all the variants I need). Then I extract it, and now I have a folder full of individual TTF files that I need to manually copy to /usr/share/fonts/truetype/ or ~/.local/share/fonts/ depending on whether I want system-wide or user-local installation.

But wait, there’s more! Now I need to run fc-cache -f -v to update the font cache. And if I’m on macOS, it’s a different dance entirely—drag files to Font Book, or copy them to /Library/Fonts/, and pray that the system actually picks them up.

By the time I finally had Hack installed and working, I was wide awake, frustrated, and thinking: “There has to be a better way.”

The Git Clone Epiphany

See, here’s the thing about my ADHD brain—it loves patterns. And I realized I was doing this same font installation dance every time I set up a new machine, every time I spun up a new Docker container for development, every time I helped a colleague get their environment configured.

And then it hit me: what if installing fonts could be as simple as cloning a repository?

What if, instead of all that manual downloading and extracting and copying, you could just open MacOS Terminal and run:

1

cd /Library/Fonts && git clone https://github.com/SamPlaysKeys/hack-fonts.git

Or, if it was on a Linux machine like my RHEL10 dev instance:

1

sudo git clone https://github.com/SamPlaysKeys/hack-fonts.git /usr/share/fonts/hack-fonts && sudo fc-cache -f -v

That’s it. One command. Boom. Fonts installed.

Building the Solution (Because I Apparently Hate Myself)

So naturally, instead of going to bed like a normal person, I built exactly that.

I created https://github.com/SamPlaysKeys/hack-fonts This is a repo that’s literally just the Hack font family organized in a way that makes installation brain-dead simple.

The structure is pretty straightforward:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


hack-fonts/
├── ttf/ # Original Hack TTF files
│ ├── Hack-Regular.ttf
│ ├── Hack-Bold.ttf
│ ├── Hack-Italic.ttf
│ └── Hack-BoldItalic.ttf
├── otf/ # Nerd Font variants with extra glyphs
│ ├── HackNerdFont-Regular.otf
│ ├── HackNerdFont-Bold.otf
│ ├── HackNerdFont-Italic.otf
│ └── HackNerdFont-BoldItalic.otf
└── web/ # Web font files for projects
 ├── demo.html
 ├── stylesheet.css
 └── *.woff/woff2 files

The beautiful thing is that when you clone this directly into your system’s font directory, everything just works. The OS font system picks up the files automatically, and you’re done.

The “But Wait, There’s More” Problem

Of course, because I have ADHD and apparently can’t do anything halfway, I didn’t stop at just the basic TTF files. I also included the Nerd Font variants—you know, the ones with all the extra glyphs for terminal icons and PowerLine symbols and all that jazz that makes your terminal look like something from the future.

And then I thought, “You know what developers also need? Web fonts.” So I threw in WOFF and WOFF2 versions with a ready-to-use CSS file. Because why solve one problem when you can solve three?

I even built a demo page at samplayskeys.com/shared/2025/hack_font_demo.html so you can see all the variants in action before installing anything.

The Attribution Thing (Because I’m Not a Monster)

Now, here’s where the responsible adult in me had to step in. Christopher Simpkins created the Hack font based on Bitstream Vera Sans Mono. It’s got proper open source licensing, and I wanted to make absolutely sure I wasn’t stepping on anyone’s toes.

As a way to do this properly, I included all the original license files, attribution documents, and links back to the official repository at source-foundry/Hack. This isn’t about taking credit for someone else’s work—it’s about making that excellent work more accessible.

Think of it like… a font delivery service. The original creators did the hard work of designing beautiful, readable monospace characters. I just figured out a more convenient way to get them onto your machine.

The Broader Point About Developer Experience

The thing is, this isn’t really about fonts, is it? It’s about all the tiny friction points in our development workflows that I just… accept. Because that’s how it’s always been done.

I will spend hours configuring development environments, manually downloading and installing tools, copying config files around, and act like this is normal. Like it’s just the cost of doing business as a developer.

But my ADHD brain refuses to accept “that’s just how it is” as an answer. Every manual step is a place where I’m going to get distracted, make a mistake, or just give up and use a suboptimal default because the proper setup is too much friction.

Font installation is just one example. How many times have you needed to set up a new machine and spent half a day just getting your terminal to look and feel the way you want it? How many times have you helped a new team member and watched them struggle through the same setup steps you’ve done dozens of times?

The Philosophy of Small Improvements

I’m not claiming this repository is going to change the world. It’s not revolutionary technology. It’s just… slightly better than the status quo.

But you know what? Sometimes that’s enough. Sometimes making something go from “annoying and manual” to “one command and done” is a meaningful improvement, even if it’s not going to win any innovation awards.

The idealist in me believes that if we can eliminate enough of these small friction points, we can spend more time on the work that actually matters. The jaded industry veteran in me knows that for every problem we solve, three new ones will appear.

But I’d rather be solving problems than just complaining about them.

The Simple Install Commands

So here’s how it works in practice:

macOS (system-wide):

1

sudo git clone https://github.com/SamPlaysKeys/hack-fonts.git /Library/Fonts/hack-fonts

macOS (user-only):

1

git clone https://github.com/SamPlaysKeys/hack-fonts.git ~/Library/Fonts/hack-fonts

Linux (system-wide):

1
2


sudo git clone https://github.com/SamPlaysKeys/hack-fonts.git /usr/share/fonts/hack-fonts
sudo fc-cache -f -v

Linux (user-only):

1
2
3


mkdir -p ~/.local/share/fonts
git clone https://github.com/SamPlaysKeys/hack-fonts.git ~/.local/share/fonts/hack-fonts
fc-cache -f -v

That’s it. No ZIP files to download. No manual extraction. No hunting through folder structures to find the right files. Just clone and go.

Try It Out (Or Don’t, I’m Not Your Boss)

If any of this resonates with you, go ahead and try the hack-fonts repository. The worst-case scenario is that you waste thirty seconds cloning a repository. The best-case scenario is that you never have to manually install fonts again.

And if you find issues, or have ideas for improvement, or want to extend this approach to other tools—well, that’s what GitHub is for, right?

Because here’s the thing: I built this for me, to solve my own font installation frustrations. But if it helps other developers avoid the same 2 AM font configuration rage, then maybe we’ve made the world slightly less annoying.

And in a world full of complex problems, sometimes making things slightly less annoying is a pretty good day’s work.

Check out the hack-fonts repository on GitHub, or try the live font demo to see all the variants in action.

ADHD Prioritizing

Wed, 20 Aug 2025 00:00:00 +0000

The ADHD Prioritization Problem

Okay, so let’s talk about prioritizing when your brain basically treats every task like it’s either THE MOST IMPORTANT THING EVER or completely invisible. Because that’s what ADHD prioritization feels like, right? Either something has grabbed your attention and it becomes this all-consuming hyperfocus target, or it might as well not exist.

I’ve been trying to figure this out for years now, and I think I’ve finally found something that actually works for my chaotic brain. It’s not perfect—nothing ever is with ADHD—but it’s gotten me out of more than a few “oh shit, I was supposed to deliver that yesterday” situations.

The Formula

The formula is actually pretty simple: Impact - Effort = Importance Importance + Urgency = Priority

But like most simple things, the devil is in the details.

Let me break this down because when I first wrote this little equation, I thought I was being clever, but it took me months to actually understand what I meant by my own system.

Understanding Impact

Impact is supposed to be straightforward—how much does this thing matter? But ADHD brains are terrible at estimating impact because we’re either catastrophizing (“if I don’t respond to this email immediately, everyone will think I’m unprofessional and I’ll lose my job and end up homeless”) or minimizing (“this is probably fine, someone else will handle it”).

So I had to get really specific about what impact means. I use a 1-3 scale:

Impact 1: Nice to have, makes things slightly better
Impact 2: Meaningfully improves something important
Impact 3: Critical for major goals or prevents significant problems

The key insight for me was realizing that “important to someone else” doesn’t automatically make something high impact for me. My manager might think it’s critical that I update that spreadsheet, but if it doesn’t actually move any needles that matter, it’s probably a 1.

Rethinking Effort

Effort is where ADHD gets really weird, because our effort estimation is completely shot. Tasks that should take twenty minutes somehow expand to consume entire afternoons. Meanwhile, complex problems that should take days sometimes get solved during a random burst of hyperfocus.

I’ve learned to think about effort not in terms of time, but in terms of mental load:

Effort 1: I can do this without much mental energy, maybe even while doing something else
Effort 2: Requires focus but doesn’t drain me
Effort 3: High cognitive load, will leave me mentally exhausted

Here’s the thing about the Impact - Effort calculation: it’s designed to surface the high-leverage activities. The stuff that makes a big difference without destroying your brain. Impact 3, Effort 1 tasks are golden—they’re your quick wins that actually matter.

But ADHD brains love to procrastinate on Impact 3, Effort 3 tasks. They’re important but hard, so we avoid them, which makes them more urgent, which makes them more stressful, which makes them feel even harder. It’s a vicious cycle.

The Urgency Reality Check

That’s where the Urgency factor comes in. I use a 0-3 scale:

Urgency 0: No particular deadline
Urgency 1: Should be done soon-ish
Urgency 2: Has a real deadline that matters
Urgency 3: On fire, needs to be done now

The Importance + Urgency = Priority calculation is basically the Eisenhower Matrix, but with ADHD-friendly modifications. Because here’s what I’ve learned: urgency is often artificial, but sometimes it’s not, and the ADHD brain is terrible at telling the difference.

Someone sending you a “quick question” with a red exclamation mark doesn’t make it actually urgent. But a production outage that’s losing the company money? That’s legitimately urgent.

Finding the Sweet Spot

The magic happens when you start looking at tasks that are high importance but low urgency. These are your Impact 3, Effort 1 or 2 tasks that don’t have artificial deadline pressure. They’re the investments that pay off over time, but they’re exactly the kind of thing ADHD brains will ignore until they become urgent.

So I try to batch these during my hyperfocus periods. When I’m in that sweet spot of mental energy and attention, I’ll look for the high-importance, low-urgency tasks and knock out as many as I can.

The other thing this system does is help me say no to things. If something is Impact 1 and Effort 3—low importance but high cognitive load—I can confidently decline or delegate it. My brain wants to treat all requests equally, but they’re not equal.

Reality Check: It’s Not Perfect

Now, does this system solve ADHD prioritization completely? Hell no. I still get distracted by interesting problems that score low on both impact and urgency. I still procrastinate on important-but-boring tasks until they become urgent. I still occasionally hyperfocus on reorganizing my task management system instead of actually doing the tasks.

But it gives me a framework for making decisions when my brain is too scattered to think clearly. It helps me recognize when I’m avoiding something because it’s hard versus avoiding it because it’s not actually important. And it makes me feel slightly less guilty when I choose to work on the interesting problem instead of the “should do” task, because at least I’m making that choice consciously.

The Real Insight

The real insight, though, is that prioritization for ADHD brains isn’t just about choosing what to work on. It’s about choosing what not to work on. About recognizing that our attention is finite and precious, and we need to be strategic about where we spend it.

Because the alternative is letting urgency and anxiety drive all our decisions, and that’s a recipe for burnout and constantly feeling behind.

So yeah, that’s my system. Impact minus Effort equals Importance. Importance plus Urgency equals Priority. Scale of 1-3 for everything. Simple enough that I can calculate it in my head when I’m overwhelmed, complex enough that it actually helps me make better decisions.

Just don’t ask me to prioritize writing about prioritization. That’s definitely a high-effort task that I’ve been procrastinating on by hyperfocusing on the system itself.

Another Day, Another Tool, Another Dopamine Hit

Fri, 13 Jun 2025 00:00:00 +0000

Another day, another productivity app. Another JavaScript framework. Another note-taking system that’s going to finally, finally be the one that gets my chaotic ADHD brain organized.

I know this cycle intimately now. I’ll be struggling with some aspect of my workflow—maybe I can’t keep track of my tasks, or I’m losing important information in the noise, or I just feel like I’m not being as effective as I could be. And then I’ll stumble across some new tool, some elegant solution that promises to solve exactly the problem I’m having.

The demo looks perfect. The interface is clean and intuitive. The features seem designed specifically for someone like me. I can practically feel my future self thanking me for discovering this game-changing solution.

So I sign up. I spend an afternoon configuring everything just right, importing my data from the previous tool, setting up integrations, customizing the interface. I feel productive and organized and optimistic about how much more effective I’m going to be now that I have the right tool.

For about two weeks.

Then the novelty wears off, and I start noticing the limitations. Maybe the mobile app is clunky, or the search function doesn’t work the way my brain expects it to, or it doesn’t quite fit into the rest of my workflow the way I thought it would. The initial excitement fades, and I’m back to feeling like I’m fighting against my tools instead of being helped by them.

And then I see a post about some new tool that promises to solve exactly the problems I’m having with the current tool, and the cycle begins again.

I’ve been through this so many times now that I could write a field guide to productivity tools for ADHD brains. Task managers, note-taking apps, calendars, time trackers, habit builders—I’ve tried them all. Multiple times.

Obsidian, Notion, Roam Research, Logseq, RemNote. Todoist, Things, OmniFocus, TickTick. Clockify, RescueTime, Toggl. Forest, Habitica, Streaks.

Each one was going to be “the one.” Each one had some feature or philosophy that seemed perfectly aligned with how my brain works. Each one generated that same burst of dopamine-fueled optimism.

And you know what? Some of them actually were genuinely helpful, for a while. The problem isn’t that these tools are bad—many of them are excellent. The problem is that I keep expecting them to fix something that can’t be fixed with software.

The ADHD brain craves novelty. It’s wired to pay attention to new and interesting things, and to get bored with routine and familiarity. This is actually a strength in many contexts—it makes us good at spotting patterns, adapting to change, coming up with creative solutions. But it’s a liability when it comes to consistency and routine.

We need systems and processes to manage our scattered attention and poor working memory. But we also get bored with systems and processes, especially once they become predictable. It’s like needing medication that stops working after two weeks because your brain adapts to it.

The tool-switching isn’t really about the tools. It’s about the dopamine hit of discovery, the excitement of possibility, the brief period where everything feels manageable and under control.

It’s also about hope. Each new tool represents hope that maybe this time will be different. Maybe this system will be the one that finally makes everything click into place. Maybe this interface will be intuitive enough that I’ll actually stick with it. Maybe this approach will work with my brain instead of against it.

And I don’t think there’s anything wrong with that hope. The alternative is accepting that you’re just going to be disorganized and ineffective forever, and that’s not a healthy mindset either.

But I’ve started to recognize the pattern, and that recognition has helped me approach it more strategically. Instead of expecting any tool to be a permanent solution, I think of them as temporary scaffolding. Something to support me while I’m building habits or working through a particular challenge.

I’ve also gotten better at identifying which aspects of a tool are actually useful versus which ones are just novel. The shiny new interface might be what initially attracts me, but the boring features—like reliable sync, good search, simple data export—are what determine whether it’ll actually be helpful.

Mostly, I’ve learned to be more forgiving of myself for the constant tool-switching. It used to make me feel like I was flaky and undisciplined, like I couldn’t commit to anything. But I’ve realized that the experimentation itself is valuable. Each tool teaches me something about how my brain works, what kinds of interfaces and workflows feel natural, what features I actually need versus what I think I want.

The ADHD brain learns by doing, not by planning. We can’t just think our way to the perfect productivity system—we have to try things and see what works. And what works changes over time as our responsibilities shift, as our understanding of our own needs evolves, as the tools themselves improve.

So yeah, I’m probably going to keep trying new tools. I’m probably going to get excited about the next note-taking app that promises to revolutionize how I organize my thoughts. I’m probably going to spend a weekend setting up some elaborate system that I’ll abandon in a month.

But now I know that’s okay. The tool-switching isn’t a character flaw—it’s just how my brain explores the space of possibilities. The dopamine hits aren’t shallow and meaningless—they’re fuel for the experimentation that eventually leads to insights and improvements.

And sometimes, just sometimes, I discover something that genuinely makes my life better. Not permanently, not perfectly, but meaningfully. A workflow that reduces friction, an interface that matches my mental model, a feature that solves a problem I’ve been struggling with for years.

Those discoveries are worth all the false starts and abandoned setups. They’re worth the eye-rolls from friends who’ve watched me get excited about productivity systems dozens of times. They’re worth the nagging voice in my head that says I should just pick something and stick with it.

Because the alternative—giving up on the search for better ways of working—means accepting limitations that might not actually be permanent. And the ADHD brain, for all its inconsistencies and contradictions, is fundamentally optimistic about the possibility of improvement.

We keep trying because we believe things can get better. We keep experimenting because we’re not satisfied with “good enough.” We keep switching tools because we’re still learning how we work best.

And you know what? Sometimes that relentless optimism pays off. Sometimes the next tool really is better than the last one. Sometimes the experimentation leads to genuine insights. Sometimes another day, another tool, another dopamine hit is exactly what we need to keep moving forward.

Even if we’ll probably be trying something new again next month.

Unfiltered thoughts from an ADHD Engineer

Sun, 09 Mar 2025 00:00:00 +0000

The Silent Struggle of ADHD

So here’s the thing about having ADHD in tech: nobody talks about it. Not really. We’ll talk about imposter syndrome and burnout and work-life balance, but we won’t talk about what it’s like to have a brain that works differently in an industry that expects you to think in straight lines.

As someone who’s been aware of their ADHD diagnosis for the last 20+ years, this is nothing new. And yet despite all of that time, and the many years spent trying to better understand how my brain works, I still only somewhat have a grasp on what is going on inside my mind. We don’t fully understand ADHD (nor the treatment options) from a scientific perspective, so how can I be expected to understand it as a regular person?

And now I’m trying to figure out how to talk about it professionally without sounding like I’m making excuses or asking for special treatment. Because the truth is, ADHD is both my biggest professional asset and my biggest professional liability, sometimes within the same hour.

It’s Not a Deficit: It’s Dopamine Disregulation

But here’s what I wish more people understood: ADHD isn’t really a deficit disorder, despite what the name suggests. It’s fundamentally about dopamine regulation—or more accurately, the inability to regulate dopamine distribution in your brain.

Dopamine is your brain’s reward and motivation system. It’s what makes tasks feel rewarding, what helps you maintain attention on things that aren’t immediately interesting, what drives executive function. In neurotypical brains, dopamine gets released in predictable ways that help maintain steady attention and motivation.

In ADHD brains? It’s chaos. We don’t produce dopamine consistently, and we don’t distribute it where it needs to go when it needs to be there. This explains so much about why we function the way we do.

The Dopamine Feast or Famine

Sometimes we get massive dopamine floods from interesting, novel, or challenging tasks, which is what creates hyperfocus. Your brain finally gets the chemical reward it’s been craving, so it latches onto that activity with laser intensity. This is why I can spend fourteen hours straight debugging a fascinating race condition but can’t force myself to spend twenty minutes updating documentation.

Other times, we’re running on dopamine fumes. Boring but necessary tasks don’t trigger any reward response, so our brains literally can’t engage. It’s not laziness or lack of discipline: it’s neurochemistry. The executive function circuits that control planning, working memory, and task switching all depend on adequate dopamine, and when it’s not there, they just… don’t work.

This feast-or-famine cycle also explains why ADHD brains are at higher risk for addiction. We’re constantly seeking that dopamine hit, whether it’s from stimulating work, caffeine, social media, video games, or unfortunately sometimes more dangerous substances. Our brains are literally wired to chase rewards because we’re not getting consistent baseline dopamine like neurotypical people do.

The Superpowers (Yes, Really)

Let me start with the good stuff, because there is good stuff, even though most of the literature focuses on deficits and disorders. The ADHD brain is really, really good at pattern recognition. I can look at a codebase and immediately spot the places where abstractions are breaking down, where complexity is accumulating, where the architecture is starting to buckle under its own weight.

I can context-switch between projects faster than most people can remember what they were working on. I can hold multiple complex mental models in my head simultaneously. I can see connections between seemingly unrelated problems and come up with solutions that nobody else was considering.

When I’m in hyperfocus mode (which is basically the ADHD equivalent of flow state, except more intense and less controllable) I can solve problems that have been stumping teams for weeks. I’ll disappear into code for eight hours straight and emerge with some elegant solution that addresses not just the immediate problem but three other issues that nobody even realized were related.

These are genuine strengths. They’re not consolation prizes or silver linings. They’re legitimate advantages that have made me better at my job in measurable ways.

The Hidden Costs

But here’s the thing: they come with costs that are really hard to explain to people whose brains work more predictably.

When Hyperfocus Goes Wrong

Let me talk about hyperfocus for a moment, because everyone seems to think it’s a superpower without understanding the downsides. Yes, hyperfocus can be incredibly productive. But it’s also completely involuntary and often inappropriate.

Hyperfocus happens when something finally triggers enough dopamine to flood your attention circuits. The problem is, you can’t control what triggers it or when it stops. I can hyperfocus on optimizing a function that saves three milliseconds while completely ignoring the critical bug that’s affecting thousands of users. I can spend six hours researching the perfect keyboard instead of working on the deadline that’s tomorrow.

And when you’re in hyperfocus, everything else ceases to exist. I’ll forget to eat, forget to go to the bathroom, forget that I have a family. I’ve missed meetings, ignored urgent messages, and worked through severe dehydration because my brain was locked onto something and wouldn’t let go. This isn’t my experience only; this is a pattern that most people will ADHD will recognize immediately. “Have you had food/water today” is a question that is honestly not asked of me enough.

Executive Function: When the CEO of Your Brain Goes Missing

Then there’s executive functioning (or in this case, disfunctioning): basically the CEO of your brain. This is the element of your mind that is supposed to prioritize tasks, manage working memory, control impulses, and coordinate between different brain regions. In ADHD brains, that CEO is either completely absent or drunk on the job.

This is why I can architect systems that handle millions of users but need seventeen different productivity apps to remember basic tasks. The part of my brain that can solve complex technical problems is completely separate from the part that’s supposed to manage day-to-day executive tasks. And when dopamine isn’t flowing to the executive function circuits, that CEO just… doesn’t show up to work.

It’s not that I don’t care about responding to emails or submitting timesheets. It’s that the neurochemical infrastructure required to prioritize and remember those tasks literally isn’t functioning properly.

The Dopamine-Seeking Trap

Here’s something nobody talks about: ADHD brains are basically addiction machines. Not because we have addictive personalities, but because we’re constantly seeking the dopamine hits that neurotypical brains get naturally.

This shows up in tech work in ways that can look productive on the surface. The endless scroll through Hacker News or Reddit “for research.” The compulsive checking of notifications, email, Slack. The inability to step away from a problem even when you’re exhausted because your brain finally found something that’s giving it the chemical reward it craves.

I’ve seen ADHD engineers burn out not because they were working too hard, but because they couldn’t stop working once they found something stimulating. They’d code for eighteen hours straight, forget to eat, ignore their families, and crash completely when the dopamine finally ran out.

The addiction risk is real and higher than most people realize. Stimulants (including caffeine), alcohol, gaming, social media, even workaholism: they’re all ways our brains try to self-medicate the dopamine disregulation. The line between “passionate about technology” and “addicted to the dopamine hit of solving problems” can be frighteningly thin.

The Invisible Struggle

And the worst part is that these struggles are invisible. When someone sees me solve a complex technical problem quickly, they assume I’m just naturally organized and productive. They don’t see the internal chaos, the constant background noise of half-formed thoughts and mental tangents, the exhaustion that comes from fighting your own brain all day just to appear normal.

They don’t see the imposter syndrome that kicks in when hyperfocus wears off and suddenly I can’t remember how I solved that problem or whether I actually understand it as well as I thought I did.

They definitely don’t see the shame spiral that happens when I miss deadlines not because the work is hard, but because I couldn’t make myself do the boring parts. Or when I have to ask someone to repeat instructions for the third time because my mind wandered during the explanation.

The Diversity We Don’t Talk About

The tech industry loves to talk about diversity and inclusion, but we mostly mean visible diversity. We’re getting better at recognizing that teams work better when they include different backgrounds and perspectives and experiences. We’re slowly learning to accommodate different working styles and communication preferences.

But we’re still not great at accommodating different cognitive styles. We still design processes and practices around neurotypical assumptions about attention and motivation and memory.

When Agile Isn’t So Agile

Take agile ceremonies, for example. Daily standups are supposed to be quick check-ins, but they often turn into rambling status updates that go on for thirty minutes. For someone with ADHD, that’s torture. My attention starts wandering after about five minutes, and by the end I can’t remember what anyone said, including what I said about my own work.

Retros are supposed to be collaborative reflection sessions, but they’re often dominated by whoever talks the loudest or thinks the fastest. The ADHD brain has great insights, but they often come in bursts, or tangents, or connections that seem random until you explain the underlying logic. By the time I’ve figured out how to articulate a thought, the conversation has moved on.

Project planning sessions assume that you can estimate how long tasks will take based on their apparent complexity. But ADHD brains don’t work that way. Sometimes the “easy” task takes forever because it’s boring and my brain won’t engage with it. Sometimes the “hard” task gets done in two hours because it triggered hyperfocus.

I’ve learned to work around most of these issues—I take detailed notes during meetings, I break large tasks into smaller pieces, I use timers and reminders and accountability systems. But it’s exhausting to constantly translate between how my brain works and how the workplace expects it to work.

The Performance of Normal

I’m one of the lucky ones. I’m in a field where being weird and obsessive about details is often seen as a positive trait. I work for companies that value results over process, where being able to solve hard problems quickly matters more than being able to sit still during long meetings.

But I still feel like I’m performing “normal” most of the time. Still worrying that if people knew how much effort it takes me to do things that seem effortless for others, they’d question whether I actually belong here.

The truth is, I don’t know if I’m a good engineer despite having ADHD or because of it. Probably both. The pattern recognition and systems thinking and ability to see connections—those come from the same brain that can’t remember where I put my keys or what I had for lunch.

We’re Not Alone

What I do know is that there are a lot of us out there, more than most people realize. Engineers and designers and product managers and CTOs who are quietly struggling with executive function and working memory and attention regulation while trying to build the future.

And maybe we’d all benefit from talking about it more. From acknowledging that diversity includes cognitive diversity, that different brains solve problems differently, that the weird kid who can’t sit still during meetings might be the same person who sees the solution that nobody else was looking for.

Worth Celebrating

Ultimately, the best technology comes from people who think differently. Who see patterns others miss, who ask questions others don’t think to ask, who approach problems from angles that seem random until they reveal insights that change everything.

That’s worth protecting. That’s worth accommodating. That’s worth celebrating.

Even if it means figuring out how to make meetings shorter.

The wish to be Wild-Built

Tue, 11 Feb 2025 00:00:00 +0000

The Surreal Intersection of Humanity and Machinery in “A Psalm for the Wild-Built”

When I picked up “A Psalm for the Wild-Built” by Becky Chambers, I was prepared for a journey through an imaginative landscape, but I was not fully prepared for the emotional resonance of its core message: “it was a land built for machines, not men.” This phrase echoes hauntingly throughout the narrative, inviting readers to reflect on the relationship between humanity and the artificial constructs we create.

A World Shaped by Technology

Chambers crafts a world where technology has taken center stage, shaping the environment in ways that often feel alien to the human experience. The roads are paved, the buildings are towering, and the infrastructure is meticulously designed to serve the needs of machines rather than the comfort of people. This stark contrast between the practicalities of modern design and the emotional, spiritual needs of individuals creates a surreal sense of disconnection.

As I read through descriptions of this landscape, I couldn’t help but think of our own world. Urban areas are filled with concrete and steel, designed for efficiency and productivity. In many cases, the human element is an afterthought, leading to environments that can feel sterile and isolating. Chambers highlights this paradox beautifully; her world is one where humanity has stepped back, allowing machines to dominate.

The Quest for Meaning

In “A Psalm for the Wild-Built,” we follow the journey of a tea monk named Dex, who seeks to explore the world and understand its deeper meanings beyond the confines of machinery. The phrase “built for machines, not men” serves as a catalyst for Dex’s journey, pushing him to confront the very essence of what it means to be human in a world increasingly dictated by technology.

Dex’s journey is profoundly personal. He grapples with questions of purpose, belonging, and the nature of work in a society that has prioritized efficiency over human connection. The surreal quality of this exploration lies in its universality; we all seek meaning in our lives, yet we often find ourselves trapped in systems that prioritize productivity over fulfillment.

Human Connection in the Age of Machines

One of the most striking elements of Chambers’ writing is her ability to weave themes of connection and disconnection throughout the narrative. As Dex travels, he encounters various characters who have also felt the weight of a world designed for machines. Their stories are poignant reminders of the importance of human connection in an age dominated by technology.

The relationships that develop between Dex and the other characters highlight the innate desire for community and understanding. In a land built for machines, their interactions become a refuge, illustrating that even in a surreal world, the human spirit can find solace in connection. Chambers beautifully captures the delicate balance between embracing technology and nurturing our humanity.

Nature as a Counterpoint

Another layer of surrealism in “A Psalm for the Wild-Built” is the contrast between the mechanical and the natural world. Chambers uses nature as a counterpoint to the sterile environments of modernity. The serene beauty of the natural landscape serves as a reminder of the world that exists beyond the reach of machines.

Dex’s encounters with nature are transformative. In these moments, he begins to rediscover the simple joys of life—watching the leaves rustle in the wind, feeling the warmth of the sun on his skin. These experiences remind him—and us—that true fulfillment comes not from productivity, but from living in harmony with the world around us.

A Reflection of Our Reality

As I finished reading “A Psalm for the Wild-Built,” I found myself reflecting on my own life and the world we inhabit. The sentiment that we live in a land built for machines resonates deeply, particularly in an era marked by rapid technological advancement. We are often so consumed by our devices and schedules that we neglect the very essence of what it means to be human.

Chambers’ narrative encourages us to pause and evaluate our relationship with technology. Are we allowing it to dictate our lives, or are we embracing it as a tool to enhance our humanity? The surreal quality of her story serves as a reminder that we have the power to shape our environments—both physical and emotional—to nurture connection, creativity, and compassion.

Conclusion

In conclusion, “A Psalm for the Wild-Built” invites readers to engage in a contemplative exploration of the intersection between humanity and machinery. The phrase “it was a land built for machines, not men” resonates as a call to action, urging us to reclaim our connection to each other and the natural world.

As we navigate our own landscapes—both urban and personal—let us remember the importance of building spaces that foster human connection and emotional fulfillment. Chambers’ work serves as a poignant reminder that while machines may shape our environments, it is the human spirit that ultimately defines our experience. In a world increasingly dominated by technology, let us strive to create a balance between the mechanical and the meaningful, ensuring that our lives are built for people, not just machines.

What it takes to get hired

Sun, 19 Jan 2025 00:00:00 +0000

I’ve been on both sides of the hiring table enough times now to have some opinions about this whole process, and honestly, most of them are pretty depressing. The way we hire engineers is fundamentally broken, but it’s broken in predictable ways that you can game if you understand the system.

Which is itself part of the problem.

Let me start with the obvious stuff that everyone knows but nobody wants to admit: technical interviews don’t really test your ability to do the job. They test your ability to solve algorithmic puzzles on a whiteboard under pressure while someone watches you and judges your every move.

I’ve hired people who aced the leetcode-style questions but couldn’t debug a production issue to save their lives. I’ve also passed on people who struggled with the toy problems but had the kind of deep systems knowledge that comes from years of actually building and maintaining real software.

The disconnect is obvious once you think about it. When was the last time you had to implement a binary search tree at work? When was the last time you had to reverse a linked list? When was the last time you solved any problem without access to Google, Stack Overflow, and the ability to run your code to see if it works?

But we keep doing these interviews because they’re easy to standardize, easy to score, and they feel objective. They give hiring managers the illusion that they’re making rational, data-driven decisions rather than subjective judgments about whether they like a person or not.

The reality is much messier.

What actually matters for doing engineering work well? Let me think about the best engineers I’ve worked with and what made them effective:

They could break down complex problems into manageable pieces. They could debug issues systematically rather than randomly trying different things until something worked. They could read and understand existing code quickly. They could communicate technical concepts clearly to both technical and non-technical audiences. They could collaborate effectively with teammates who had different working styles and communication preferences.

They had good instincts about when to optimize and when to ship. They understood the business context around their technical decisions. They could balance perfectionism with pragmatism. They could learn new technologies quickly without getting overwhelmed by choice.

Most importantly, they gave a shit. They cared about the quality of their work, about the experience of people using their software, about the maintainability of the systems they built.

None of these qualities are tested by traditional technical interviews. Some of them can’t be tested in an interview at all—they only emerge over time, through actually working with someone.

So what does get you hired? Unfortunately, it’s mostly signal rather than substance.

You need to be able to perform competence rather than just demonstrate it. You need to tell a compelling story about your background and your interests. You need to ask thoughtful questions that show you’ve researched the company and understand their challenges. You need to seem enthusiastic about their specific problems rather than just looking for any job.

You need to practice the artificial interview questions until you can solve them smoothly and confidently, even though they have nothing to do with the work you’ll actually be doing. You need to be able to explain your thought process clearly while solving these problems, which is a completely different skill from actually solving them.

And increasingly, you need to have the right keywords on your resume and the right projects in your GitHub. The screening process has become so automated that humans often never see candidates who don’t match the exact technology stack the company thinks they need.

This is particularly challenging for people whose careers don’t fit the standard narrative. If you’re changing careers, if you took time off, if you learned to code through non-traditional paths, if your experience is broad rather than deep in trendy technologies—you’re at a disadvantage regardless of your actual capabilities.

The ADHD angle makes this even more complicated. Many of us are really good at the actual work but terrible at the performance aspects of interviewing. We might nail the technical questions but struggle with the behavioral questions that require constructing coherent narratives about past experiences.

Or we might do great in casual technical conversations but freeze up when asked to solve problems on a whiteboard with someone watching. The artificial pressure and lack of normal tools can trigger anxiety that has nothing to do with technical ability.

I’ve bombed interviews for jobs I could have done in my sleep, and I’ve gotten offers for roles that were probably above my level at the time, all based on how well I performed in the interview rather than how well I could actually do the work.

The optimist in me wants to believe this is changing. Some companies are experimenting with take-home projects, pair programming sessions, code review demonstrations, and other formats that better simulate actual work. The rise of remote work and AI tools have made it easier for companies to hire based on demonstrated ability rather than cultural fit.

But the pessimist in me knows that most companies are still using the same broken process because it’s what everyone else does, and changing hiring practices is risky and expensive.

So what’s the practical advice for people trying to navigate this system?

First, accept that the game is partly artificial and prepare accordingly. Practice the leetcode problems, not because they matter, but because hiring managers think they matter. Get good at telling your story in a compelling way. Learn to project confidence even when you’re not feeling it.

Second, focus on companies and roles where you can demonstrate your actual abilities. Look for places that value take-home projects, open source contributions, or other evidence of real work. Seek out startups and smaller companies that might be more flexible about their requirements.

Third, build genuine relationships in the industry. The best opportunities often come through referrals, where someone who knows your work can vouch for your abilities rather than relying on interviews alone.

Fourth, don’t take rejection personally. The hiring process is noisy and often arbitrary. I know excellent engineers who got rejected by companies they would have thrived at, simply because the interview process didn’t capture their strengths.

Finally, (this is by far the most important step:) once you’re in a position to influence hiring-whether as a senior engineer, tech lead, or manager-try to make the process better. Push for interview formats that actually test relevant skills. Advocate for candidates whose experience doesn’t fit the standard template. Question whether you’re optimizing for interview performance or job performance.

Because ultimately, the goal should be building great teams that can solve interesting problems effectively. And that requires people with diverse backgrounds, experiences, and ways of thinking.

The current hiring process doesn’t optimize for that. But maybe we can slowly make it better.