Everyone knows the process is ridiculous, but they go along with it anyway. To enter the mess hall, you have to recite the pledge of allegiance. To be served food, you have to recite it twice. If you want salt, pepper, and ketchup, you have to sing the Star-Spangled Banner. Other condiments require signing a loyalty oath.

No one questions the process. Everyone follows along because the person before them did. The group behind this keeps escalating the requirements in their Loyalty Oath Crusade, but their goal has nothing to do with ensuring soldiers are loyal. They are simply trying to punish a single person.

This is delaying missions, creating unnecessary process, and slowing down the entire war effort. So how does the Loyalty Oath Crusade finally unravel? It takes one person speaking up. Major __ de Coverley walks in and sees all the commotion. People signing loyalty oath cards, singing the national anthem for ketchup, reciting the pledge of allegiance just to sit down.

He started forward in a straight line, and the wall of officers before him parted like the Red Sea. Glancing neither left nor right, he strode indomitably up to the steam counter and, in a clear, full-bodied voice that was gruff with age and resonant with ancient eminence and authority, said:

"Gimme eat."

Instead of eat, Corporal Snark gave Major __ de Coverley a loyalty oath to sign. Major __ de Coverley swept it away with mighty displeasure the moment he recognized what it was, his good eye flaring up blindingly with fiery disdain and his enormous old corrugated face darkening in mountainous wrath.

'Gimme eat, I said,' he ordered loudly in harsh tones that rumbled ominously through the silent tent like claps of distant thunder.

Corporal Snark turned pale and began to tremble. He glanced toward Milo pleadingly for guidance. For several terrible seconds there was not a sound. Then Milo nodded. 'Give him eat,' he said.

And just like that, the spell was broken. The entire process fell apart, the Loyalty Oath Crusade dismantled in a single stroke.

I think of this whenever I see a bloated process that has become embedded in work culture. We perform our ceremonies, our loyalty oath pledges, without ever questioning them.

"They do it at Google, so we must do the same." Never questioning whether it's the right process for us. Nothing changes because it feels like pushing back means going against the culture. But what does it actually take to make a change? You have to speak up.

Speak up when you think the processes don't make sense. Even if it comes out as an animalistic grunt. "Gimme eat" is as primitive as it gets, yet it conveys exactly what everyone else is feeling.

When a company grows to the point where you can't fit every employee in a single room, these unusual processes start to take shape. They usually begin with good intentions, you need process to manage a large group of people. But process breeds ritual. And those rituals may help one team while being completely detrimental to another. Individual voices start to disappear, replaced by metrics and managers summarizing the gist of things.

In an interview, Frank Herbert, author of Dune, was asked about the Bene Gesserit use of the Voice to control others. By modulating their tone, the Bene Gesserit can bend others to their will. Readers pointed out that this seemed unrealistic. Frank had a simple answer: it's not unheard of for people to use their voice to control others.

If you want to avoid that fate, don't let your voice disappear. Your voice is one of the most powerful tools you have.

But then people started asking: how does the teleportation device actually work? When a subject stands on the device and activates it, does it disassemble all the atoms of the person and reconstruct them at the destination? Or does it scan the person, kill them, and then replicate them at the destination?

This debate has been on going for as long as I can remember. Since teleportation machines exist only in fiction, we can never get a true answer. Only the one that resonates the most.

So, that's why I thought of Diff Teleportation. Basically, this is a Git workflow applied to teleportation. When you step onto a device, we run the command:

$> git checkout -b kirk-teleport-mission-123
$> beam -s kirk -d planet-xyz -o kirk-planet-xyz    # beam is a vibe-coded teleportation command

Then, the machine will have to suspend activity on the master branch. This will make merging the branch much simpler in the future.

# sci-fi git command
$> git suspend master

Now, the person that has been teleported can explore the planet and go about mission 123. While they are doing their job, let's see what flags are supported in beam:

$> beam -h
Usage: beam [OPTION]... [FILE]...
Beam a file to a destination

    -s, --subject               subject to beam
    -d, --destination       destination to beam a subject
    -o, --output                name of the file at the destination
    -D, --Destroy               destroy a subject

When the mission is completed, they can be teleported back. Well, not the whole person, otherwise we end up with a clone.

$> beam -s kirk-planet-xyz -d ss-ent-v3 -o kirk-temp

We could analyze the new data and remove any unwanted additions. For example, we could clean up any contamination at this point. But for the sake of time, I'll explore that another day. As an exercise, run git diff for your own curiosity. For now, all we are interested in is the information that the teleportee has gathered from the planet, which we will merge back into master.

$> git add src/neurons
$> git commit -m "add mission 123 exploration"
$> git stash
$> git stash drop   # Hopefully you've analyzed it.
$> git push origin kirk-teleport-mission-123

I imagine in science fiction, there is an automated way for PR reviews that is more reliable than an LLM. Once that process is completed, we can merge to master and run some cleanup code in the build pipeline.

$> git branch -D kirk-teleport-mission-123
$> beam -s kirk-planet-xyz -D
$> beam -s kirk-temp -D
$> git unsuspend master

Somewhere down on planet XYZ, a clone stepped onto the teleportation device. He saw a beam of light scan his body from head to toe. Then, for a moment, he wondered if the teleportation had worked. But right before he stepped off, the command beam -s kirk-planet-xyz -D ran, and he was pulverized.

Back in the spaceship, a brand-new clone named kirk-temp appeared at the teleportation station. He was quickly sanitized, diff'd, and reviewed. But before he could gather his thoughts, the command beam -s kirk-temp -D ran, and he was pulverized.

Not a second later, the original subject was reanimated, with brand-new information about "his" exploration on planet XYZ.

Teleportation is an achievable technology. We just have to come to terms with the fact that at least two clones are killed for every successful teleportation session. In fact, if we are a bit more daring, we might not even need to suspend the first subject. We can create multiple clones, or agents, and have them all explore different things. When their task is complete, we can wrestle a bit with merge conflict, run a couple beam -D commands, and the original subject is blessed with new knowledge.

OK, I'm getting out of this shower.

For me, being part of an online community started with Digg. Digg was the precursor to Reddit and the place to be on the internet. I never got a MySpace account, I was late to the Facebook game, but I was on Digg.

When Digg redesigned their website (V4), it felt like a slap in the face. We didn't like the new design, but the community had no say in the direction. To make it worse, they removed the bury button. It's interesting how many social websites remove the ability to downvote. There must be a study somewhere that makes a sound argument for it, because it makes no sense to me.

Anyway, when Digg announced they were back in January 2026, I quickly requested an invite. It was nostalgic to log in once more and see an active community building back up right where we left off.

But then, just today, I read that they are shutting down. I had a single post in the technology sub. It was starting to garner some interest and then, boom! Digg is gone once more.

The CEO said that one major reason was that they faced "an unprecedented bot problem."

This is our new reality. Bots are now powered by AI and they are more disruptive than ever. They quickly circumvent bot detection schemes and flood every conversation with senseless text.

It seems like there are very few places left where people can have a real conversation online. This is not the future I was looking for. I'll quietly write on my blog and ignore future communities that form.

Rest in peace, Digg.

Then he plugged the device into his computer, opened a terminal on the projector, and pushed some code onto it. A couple of minutes later, he unplugged the cable, powered on the calculator, and sure enough, Snake was running on it. A student raised his hand. The professor leaned forward, eager for the first question of the semester.

"Um... is this going to be on the test?"

While the professor was showing us what it actually means to build something, to push code onto hardware and watch it come alive, his students were already thinking about the grade. About the exit. The experience meant nothing unless it converted into points.

That was college for me. Everyone was chasing a passing grade to get to the next class. Learning was mostly incidental. The professors tried, but our incentives were completely misaligned. Talk of higher education becoming obsolete was already in the air, especially in CS. As enthusiastic as I had been when I started, that enthusiasm got chipped away one class at a time until the whole thing felt mechanical. Something I just had to get through.

I dropped out shortly after the C++ class, which had taught me almost nothing about programming anyway. I was broke and could only pay for so many courses out of pocket. So I took my skills, such as they were, to a furniture store warehouse. My day job.

When customers bought furniture, we pulled their merchandise from the back and loaded it into their trucks. They signed a receipt, we kept a copy, and those copies went into boxes labeled by month and date. At the end of the year, the boxes went onto a pallet, the pallet got shrink-wrapped, and a forklift tucked it away in a high storage compartment.

Whenever an accountant called requesting a signed copy, usually because a customer was disputing a charge, the whole process ran in reverse. Someone licensed on the forklift had to retrieve the pallet, we cut the shrink-wrap, found the right box, and sifted through hundreds of receipts until we found the one we needed. The process took hours.

One day I decided enough was enough. After my shift, I grabbed the day's signed receipts and fed them into a scanner. For each one, I created two images: a full copy and a cropped version showing just the top of the receipt where the order number was printed. I found a pirated OCR application, then used VBScript and a lot of Googling to write a script that read the order number and renamed each image file to match it.

I also wrote my first Excel macros, in Visual Basic this time, which wasn't so different. When everything was wired together, I had a working system. Each evening, I would enter the day's order numbers, scan the receipts, and let the script match them up with a preview attached. When the OCR failed to read a number, the file was renamed "unknown" with an incrementing number so I could verify those manually.

From then on, when an accountant called, I could find and email them the receipt in under a minute, without ever leaving my desk.

When I left that warehouse, I was ready to call myself a programmer. That one month building that system taught me more than two years of school ever had. But the education didn't stop there.

Years later, now considering myself an experienced developer, a manager handed me what looked like a giant power strip. It had a dozen outlets, and was built for stress-testing set-top boxes in a datacenter. "Can you set this up?" he asked.

A few years earlier, I would have panicked. I would have gone looking for someone who already knew the answer, or waited until the problem solved itself. But something had changed in me since the warehouse. Unfamiliar problems no longer felt like a barrier. They felt like the first receipt I ever fed into a scanner. It was just something to pull apart until it made sense.

I had never worked with hardware. I had no idea where to start. But I didn't need to know where to start. I just needed to start. I brought the device to my desk and inspected every inch of it. I wasn't looking for the answer exactly. Instead, I was looking for the first question. And I found one: an RJ45 port on one end. Not exactly the programming interface you'd expect, but it was there for a reason.

I looked up the model number of the device, downloaded the manual, and before long I was connected via Telnet, sending commands and reading output in the terminal. Problem solved. Not because I knew anything about hardware going in, but because I had learned to spend time with unfamiliar problems.

None of this was in the syllabus. Nobody graded me on it. There was no partial credit for getting halfway there.

That's the difference between school and work. School optimizes for the test, like that student who couldn't look past the grade to see what was actually being shown to him. School teaches you the shape of a problem and gives you a method to solve it. Work, on the other hand, doesn't care about the test. Work hands you something broken, or inefficient, or completely unfamiliar, and simply waits.

Often, there are no right answers at work. You just have to build your own solution that satisfies the requirement. You figure things out, not because you memorized the right answer, but because you thought your way through it. Then something changes in how you approach every problem after that. You don't flinch at the next problem. You understand that facing unfamiliar problems is the job.

The camera on your laptop is pointed at you right now. When activated, it can record everything you do. When Zuckerberg posted a selfie with his laptop visible in the background, people were quick to notice that both the webcam and the microphone had black tape over them. If the CEO of one of the largest tech companies in the world doesn't trust his own device, what are the rest of us supposed to do?

On my Windows 7 machine, I could at least assume the default behavior wasn't to secretly spy on me. With good security hygiene, my computer would stay safe. For Windows 10 and beyond, that assumption may no longer hold. Microsoft's incentives have shifted. They now require users to create an online account, which comes with pages of terms to agree to, and they are in the business of collecting data.

As part of our efforts to improve and develop our products, we may use your data to develop and train our AI models.

That's your local data being uploaded to their servers for their benefit. Under their licensing agreement (because you don't buy Windows, you only license it) you are contractually required to allow certain information to be sent back to Microsoft:

By accepting this agreement or using the software, you agree to all of these terms, and consent to the transmission of certain information during activation and during your use of the software as per the privacy statement described in Section 3. If you do not accept and comply with these terms, you may not use the software or its features.

The data transmitted includes telemetry, personalization, AI improvement, and advertising features.

On a Chromebook, there was never an option to use the device without a Google account. Google is in the advertising business, and reading their terms of service, even partially, it all revolves around data collection. Your data is used to build a profile both for advertising and AI training.

None of this is a secret. It's public information, buried in those terms of service agreements we blindly click through. Even Apple, which touts itself as privacy-first in every ad, was caught using user data without consent. Tesla employees were found sharing videos recorded inside customers' private homes.

While some treat the Ray-Ban glasses story as an isolated incident, here is Yann LeCun, Meta's former chief AI scientist, describing transfer learning using billions of user images:

We do this at Facebook in production, right? We train large convolutional nets to predict hashtags that people type on Instagram, and we train on literally billions of images. Then we chop off the last layer and fine-tune on whatever task we want. That works really well.

That was seven years ago, and he was talking about pictures and videos people upload to Instagram. When you put your data on someone else's server, all you can do is trust that they use it as intended. Privacy policies are kept deliberately vague for exactly this reason. Today, Meta calls itself AI-first, meaning it's collecting even more to train its models.

Meta's incentive to collect data exceeds even that of Google or Microsoft. Advertising is their primary revenue source. Last year, it accounted for 98% of their forecasted $189 billion in revenue.

Yes, Meta glasses record you in moments you expect to be private, and their workers process those videos at their discretion. We shouldn't expect privacy from a camera or a microphone, or any internet-connected device, that we don't control. That's the reality we have to accept.

AI is not a magical technology that simply happens to know a great deal about us. It is trained on a pipeline of people's information: video, audio, text. That's how it works. If you buy the device, it will monitor you.

The page receiving all the traffic had a total of 17 assets. So in addition to the database getting hammered, my server was spending most of its time serving images, CSS and JavaScript files. So I decided to set up additional servers to act as a sort of CDN to spread the load. I added multiple servers around the world and used MaxMindDB to determine a user's location to serve files from the closest server. But it was overkill for a small blog like mine. I quickly downgraded back to just one server for the application and one for static files.

Ever since I set up this configuration, my server never failed due to a traffic spike. In fact, in 2018, right after I upgraded the servers to Ubuntu 18.04, one of my articles went viral like nothing I had seen before. Millions of requests hammered my server. The machine handled the traffic just fine.

It's been 7 years now. I've procrastinated long enough. An upgrade was long overdue. What kept me from upgrading to Ubuntu 24.04 LTS was that I had customized the server heavily over the years, and never documented any of it. Provisioning a new server means setting up accounts, dealing with permissions, and transferring files. All of this should have been straightforward with a formal process. Instead, uploading blog post assets has been a very manual affair. I only partially completed the upload interface, so I've been using SFTP and SCP from time to time to upload files.

It's only now that I've finally created a provisioning script for my asset server. I mostly used AI to generate it, then used a configuration file to set values such as email, username, SSH keys, and so on. With the click of a button, and 30 minutes of waiting for DNS to update, I now have a brand new server running Ubuntu 24.04, serving my files via Nginx. Yes, next months Ubuntu 26.04 LTS comes out, and I can migrate it by running the same script.

I also built an interface for uploading content without relying on SFTP or SSH, which I'll be publishing on GitHub soon.

It's been 7 years running this server. It's older than my kids. Somehow, I feel a pang of emotion thinking about turning it off. I'll do it tonight...

But while I'm at it, I need to do something about the 9-year-old and 11-year-old servers that still run some crucial applications.

Then there's "hallucination." He didn't exactly invent it. The term has existed since the 1970s. In one early instance, it was used to describe a text summarization program's failure to accurately summarize its source material. But Karpathy's revival of the term brought it back into the mainstream, and subtly shifted its meaning, from "prediction error" to something closer to a dream or a vision.

Now, large language models don't throw errors. They hallucinate. When they invent facts or bend the truth, they're not lying. They're hallucinating. And with every new model that comes out and promises to stay clean off drugs, it still hallucinates.

An LLM can do no wrong when all its failures are framed as neurological disorder. For my part, I hope there's a real effort to teach these models to simply say "I don't know." But in the meantime, I'll adopt the term for myself. If you ever suspect I'm lying, or catch me red-handed, just know that it's not my fault. I'm just hallucinating.

I would love to have all the features enabled on all my devices.

I would love to have Siri on my phone.

I would love to have Alexa control the lighting in my house and play music on command.

I would love to own an electric car with over-the-air updates.

I would love to log in with my Google account everywhere.

I would love to sign up for your newsletter.

I would love to try the free trial.

I would love to load all my credit cards onto my phone.

I would love all of that.

But I can't. I don't get to do these things because I have control over none of them. When I was a kid, I imagined that behind the wild technologies of the future there would be software and hardware, pure and simple. Now that we have the tech, I can say that what I failed to see was that behind every product, there is a company. And these companies are salivating for data.

If you're like me, you have dozens of apps on your phone. You can't fit them all on the home screen, so you use a launcher to find the ones you don't open every day. Sometimes, because I have so many, I scroll up and down and still can't find what I'm looking for. Luckily, on most Android phones, there's a search bar at the top to help. But the moment I tap it, a notification pops up asking me to agree to terms and conditions just to use the search. Of course I won't do that.

Most people have Siri enabled on their iPhone and never think twice about it. Apple has run several ads touting its privacy-first approach. Yet Apple settled a class action lawsuit last year claiming that Siri had violated users' privacy, to the tune of $95 million.

I can't trust any of these companies with my information. They will lose it, or they will sell it. Using Alexa or Google Assistant is no different from using Siri. It's having a microphone in your home that's controlled by a third party.

As enthusiastic as I am about electric cars, I didn't see the always-connected aspect coming. I've always assumed that when I pay for something, it belongs to me. But when an automaker can make decisions about your car while it sits in your garage, I'd rather have a dumb car. Unfortunately, it's no longer limited to electric vehicles. Nearly all modern cars now push some form of subscription service on their customers.

Spy!

Have you ever been locked out of your Google account? One day I picked up my phone and, for some reason, my location was set to Vietnam. A few minutes later, I lost access to my Google account. It's one thing to lose access to your email or files in Drive. But when you've used Google to log in to other websites, you're suddenly locked out of those too. Effectively, you're locked out of the internet.

I was lucky my account was restored the same day, apparently there were several login attempts from Vietnam. But my account was back in service just in time for me to mark another Stack Overflow question as a duplicate.

I don't sign up for services with my real email just to try a free trial, because even when I decide not to continue, the emails keep coming.

When my sons were just a few months old, I received a letter in the mail addressed to the baby. It stated that his personal information (name, address, and Social Security number) had been breached. He was still an infant. I had never heard of the company responsible or done any business with them, yet somehow they had managed to lose my child's information.

I would love to not worry about any of this, but it's a constant inconvenience. Whenever I grab the TV remote, I accidentally hit the voice button, and the terms of service remind me that my voice may be shared with third parties.

Technology is amazing when you have some control over it. But when the terms of service can change out from under you without warning, I'll politely decline and keep my tin hat close by. I have so much to hide.

Isn't it better to upgrade MySQL to the latest version? "It depends."

Isn't it better to upgrade our Ubuntu version to the one that was just released? "It depends."

Our PHP instance is reaching end-of-life, isn't it better to upgrade it right away? "It depends."

At the time, that felt like the wrong answer. The correct answer was obviously "Yes." Of course it's better to do all those things. But there was so much that I couldn't see yet.

Have you considered that the main application using this instance can't be easily updated? It doesn't support newer MySQL drivers, which means we'd have to go through the process of upgrading the application first before touching the database. So yes, upgrading is better in theory. But it depends on whether we can allocate the time to do it in the right order.

It's great to move to the latest version of Ubuntu, but our policy was to stay on LTS releases for stability. Yes, a newer version means new features, but it also means risking breaking changes in a production environment. When you're responsible for systems other people depend on, latest isn't always safest.

At the time I asked this question, we were running PHP 4.x. PHP 5 was already out and receiving patches. Yes, upgrading would have improved performance and closed critical vulnerabilities. But we also ran several forums that had never been tested on PHP 5. In hindsight, they were completely incompatible. A hasty upgrade would have taken them offline.

My lead developer had been doing this for years longer than me. He'd already watched systems break after rushed upgrades. He'd seen obvious improvements cause cascading failures nobody anticipated. When he said "it depends," he wasn't being evasive. He knew there was a list of variables I didn't even know to ask about yet. I heard a non-answer. He was actually giving me the most honest answer possible.

The more I've worked as a software engineer, the less I give black-and-white answers, and the more I understand why.

When a product team asks if it's possible to build a feature, the answer is never a simple yes or no. It depends on the timeline. It depends on what else we're working on. It depends on team bandwidth, technical debt, third-party dependencies, and a dozen other factors that aren't visible from the outside.

My friends who are learning to program often ask me: "What's the best programming language?" I'm always tempted to just say "machine code" and leave it at that. But the real answer is that "best" is meaningless without context. Best for what? Best for whom? I could say Python, but what if they're building an iOS app? I could say JavaScript, but what if they're writing data pipelines? The question assumes a universal answer exists. It doesn't.

A doctor doesn't say "exercise is always good" without asking about your heart condition. A lawyer doesn't say "you should sue" without reviewing the facts of the case. A structural engineer doesn't say "that wall can come down" without checking whether it's load-bearing. Expertise in any field means learning which questions to ask before answering. And understanding how much the answer can shift depending on the variables.

The more you learn and specialize, the more you see the variables that others miss. And the more you see those variables, the harder it becomes to answer a simple question simply. Because you know it's never actually simple.

I don't mind having a conversation with coworkers. What I mind is the interruption itself, especially when I'm in the middle of a task. Sometimes I'm debugging an issue in a legacy application, building a mental model of the workflow, reading a comment that describes an exception, following a function declaration, right when I'm on the verge of the next clue, I hear a voice: "Hey! What's going on? I haven't seen you in a while. What have you been up to?"

The conversation is never long. But when it's over, my thoughts are gone. Where was I? Right, the function declaration. But where was it being called? What was that exception the comment described? Where did I even see that comment? I have to retrace every step just to rebuild the mental state I was in before I can move forward again.

Working remotely helps, to a point. Interruptions via Slack can be muted until I'm ready to respond. But remote work isn't immune. You're still expected to be in meetings. As a lead, I'm frequently pulled into calls because "everything is on fire." Often, my presence isn't to put out the fire, it's to hold someone's hand. An hour later, I can barely remember what I was working on.

The cost of interruption falls entirely on the person being interrupted. You lose your place, your focus, and eventually your ability to finish anything on time. For the person doing the interrupting, though, it's often a positive experience. The manager who constantly pulls the team into status updates feels productive. They're in the loop, they're present, they're on top of things. They schedule daily standups, attend every scrum ceremony, and expect developers to translate their work-in-progress into business-friendly language on demand.

Meanwhile, the developer is spending their day sitting in calls, reassuring, explaining, and planning, but never actually building anything. When they push back, the manager doesn't cancel the meetings. Instead, he trims them from 30 minutes to 15. It feels like progress. But the length of the meeting was never the problem. Three meetings a day means three interruptions, regardless of how short they are.

Being constantly interrupted at work reminds me of being in a hospital. Doctors prescribe rest, but hospitals are among the worst places to actually get any. Before our kids were born, my wife spent close to a month in the hospital. I had a small corner of the room, a chair and a desk, where I'd work on my laptop by her side. Every 20 minutes, the door would swing open, a nurse would bustle in and out, and the door would be left wide open behind her.

It didn't matter that the doctor had ordered rest. Her sleep was interrupted every single time.

That's what interruption-driven development looks like in practice. The work requires uninterrupted effort to actually happen. You can have the right tools, the right team, the right intentions, and still produce nothing. The work environment itself is working against you.

My headphones might keep those eager to converse at bay. But what we really need is time to get work done without the constant interruption. It should be part of the software development lifecycle.