GeistHaus
log in · sign up

https://qword.net/feed.xml

atom
10 posts
Polling state
Status active
Last polled May 18, 2026 23:48 UTC
Next poll May 19, 2026 21:25 UTC
Poll interval 86400s
ETag W/"44d2cc137f0ded815f3d71d595637c73"

Posts

You should write deliberately bad tools
“One can waste years this way, systematically postponing precisely the things one cares about the most.”
Show full content

“One can waste years this way, systematically postponing precisely the things one cares about the most.”

Oliver Burkeman, Four Thousand Weeks: Time Management for Mortals

I’ve been recently reading a little bit about time management. Time management philosophy is divided into two camps:

  1. How can I get more done in each day? Show me the productivity hacks, calendar-juggling techniques, and methods to slay my to-do list.

  2. I’m going to die some day so my time is limited. How can I avoid squandering it on stuff that doesn’t matter?

Number 1 is the rise-and-grind hustle approach that’s you’ve likely heard of already. I’m not going to talk about it here. It’s the second approach that’s plenty more interesting –

I first read Seneca’s “On The Shortness of Life” when I was much younger, and I mostly read it for entertainment. I recently looked at Four Thousand Weeks by Oliver Burkeman, which is an important and very recommended read in it’s own right but I’ll let you in on the core idea: Life is probably about 4000 weeks long if you live until 80, and then there’s no more time after that. Whatever attention you give your financial spending, you should give at least twice as much to your time.

So, consider this interaction that I’ve seen in real life, several times:

Alice: Hey, could somebody fetch me the value for $VENDOR_API_KEY in production?

Bob: Yes, I sure can help you with that!

  • Bob navigates to the AWS console, where he is prompted to type in his password.
  • Bob types in his master password to unlock his password manager.
  • Bob’s password manager fills in his account credentials and he clicks login.
  • Bob then has to unlock his phone to accept his 2fa authentication from an app.
  • Bob, now signed into AWS, changes his account role to the appropriate one.
  • Bob navigates over to the AWS secrets manager, but has forgotten if the key is named $VENDOR_API_KEY or $API_KEY_VENDOR. Or is it $API-KEY-VENDOR?
  • Bob swaps over to Slack to copy the right name, then pastes it into the search.
  • Bob doesn’t find it. He thinks maybe Alice was mistaken about the excat name, so he does a few more searches and then does find that it’s named just a little differently.
  • Bob has the value now, but now needs to send it to Alice.
  • Bob fetches Alice’s SSH key off of github, and then encrypts the secret with age after first going through his shell history to figure out how he has done it before.
  • Bob pastes the encrypted secret to Alice over Slack. “Here you go, it was no problem at all!”

Bob is some sort of moron, but maybe it’s only apparent when written out like this. Time seems infinite when each day comes after the next, in the same manner that the Earth seems flat when observed a few metres at a time, and this task looks simple when thought of as one step at a time. It’s not really that simple.

Perhaps I was a little bit unfair to Bob and they’re not truly the sort of person to go up the wrong-direction escalator for about three minutes before realizing it, but I really do see stuff like this so often. Typing in your password three times before you can get anything done, juggling things in your clipboard, click-ops’ing your way through tasks – if you have to do something like this manually, you ought to kick yourself the third time.

Programming can be described as a lot of things, and one of those things is that it’s the replacement of human labour for compute. Bob writes features and makes buttons bluer day-in and day-out, but easily forgets that they can make computers do stuff for them. And with only 4000 weeks or so of life, it’s plenty nice to have computers do stuff for me.

So I kindly instructed Bob that it might make sense to write something to do these sorts of menial tasks on his behalf, and showed them this comic put together by XKCD:

XKCD comic

You may have seen this table before – the implications of it are actually rather surprising. Firstly, clip all values by 20% assuming that you’ll only stay at a company for roughly four years instead of five, when most stock vest handcuffs come off. Also note that these are absolute lengths of time and not work-hours. Really study it and think about each value here.

  • The most surprising thing in my opinion is that you’re permitted to spend more than six months working on shaving off minutes from a CI pipeline that runs 50 builds a day.

  • The most common “rule” I’ve memorized from this is that tasks of ~5 minutes permit at least ~one work-day to eliminate, when done at least monthly.

  • Not all time is equal. Five minutes of active click-ops is not the same as waiting for a build for five minutes. There is a second dimension that I like to call “agony” that’s also important.

This should be at least a little convincing, but “writing a tool is a project in of itself!”, cries Bob. XKCD is again poignant on this issue:

XKCD comic

Bob takes your advice, and says “this would be a good opportunity to learn Rust or Haskell!” Cracking their knuckles, they download rustup, set up cargo, research into what IDE plugins there are – or install GHC and do the same–

No, no NO NO! This isn’t the time to learn a language – especially not one that requires you to be precise with what you mean, or to really enjoy the task. OK, you can make some affordances, but the goal here is to maximize your free time and that likely means avoiding any brilliant languages and picking those that align with writing the shittiest thing that is going to work, profiting as much as you can from open-source code others have written, and moving on with your life. The only difference between a script and a program is that scripts are deliberately bad.

“Oh,” Bob moans. “I’ll need an API key for this service, and they don’t have an SDK in Python so I’ll have to write one to make the API calls-“

No. Get Selenium or Playwright. Automate some clicking. Ask a GPT to rewrite some CURLs into real request code. Move on.

“But,” Bob says, “I need to put this user and password into somewhere. I’ll set up Hashicorp Vault, put in the keys–”

No. Put it in a text file and throw it in /tmp.

“Okay, sometimes this thing crashes if it’s ran too long. I’ll take a heap dump, measure the memory–”

Come on. Just restart it every hour with a cron. Next.

For myself, I have a collection of embarrasingly bad tools that are unshareable and won’t really work for others. They handle all sorts of things that are otherwise papercuts, and it makes me smile when I run them and they do things for me. It doesn’t matter that they’re bad. It’s almost the point. I save my best work and energy for my actual projects.

Life is only so long. I haven’t thought so far as what I’d really like to do with my limited time in my life, but I know that clicking around in dashboards and consoles isn’t it.

https://www.qword.net/2024/04/07/you-should-write-bad-tools
The use and abuse of the dev branch pattern
Have you ever wanted to make local changes to a repository for your own benefit, but don’t want to send them remotely? Maybe you’ve once wanted to:
Show full content

Have you ever wanted to make local changes to a repository for your own benefit, but don’t want to send them remotely? Maybe you’ve once wanted to:

  • Work around scripts insisting that you have a tool like yarn installed globally, but you correctly recognize that as being stupid and need to wrap it?
  • Add some Dockerfiles for more productive development on your end, but only want to keep them to your machine?
  • Append some extra helpful commands to a package.json to quickly rebuild or test things?
  • Change some invocation flags (e.g. configs, heap size, local web server ports) to make stuff work better on your own system?
  • Patch out the execution of long-running tests locally, and leave them to the CI instead?
  • Nix-ify the development environment so that installing the build tools won’t conflict with anything else on your system?
  • Develop on OSX but the rest of the team is on Linux so your build scripts need adjusting?
  • Make literally any kind of suit-tailored change for your own setup?

You’ve probably had to do such things before and ended up with a small mess of untracked files, changes that you need to be ‘careful not to accidentally stage’, and loose-leaf changes scattered in places.

We can do much better. You can productively accomplish all this and more with a pattern I like to use and abuse: the dev branch.

Overview

The idea is simple. We’ll make a new branch called dev, configure git to not push commits from it anywhere, put all our custom tailorings in it, and then learn how to use it as our new base of operations when writing pull requests.

Oh, yeah, if you’re not using git then I don’t know what to tell you. Stop reading here, I guess.

Make a new branch off of main, and call it dev.
$ git checkout main
$ git checkout -b dev

This branch will be what we use all the time now. We’re almost never going to spend time on main. The dev branch is where we hang out now. Especially on the weekends, or if it’s raining.

Set up pre-commit githooks

We’re going to be adding our bespoke, tailor-made commits to this branch and we don’t want to share them with anybody else. We’ll use git hooks to prevent accidental sharing.

Inside the .git/hooks/ folder, there should be a pre-push.sample example of a pre-push hook. If you don’t have it, you can find it on github here.

Copy it without the .sample:

$ cp .git/hooks/pre-push.sample .git/hooks/pre-push

The example shows how to prevent pushing of commits that start with “WIP”. We’re going to edit it to prevent pushing commits that contain “nocommit” anywhere in the message. Apply this patch:

@@ -19,6 +19,9 @@
 # This sample shows how to prevent push of commits where the log message starts
 # with "WIP" (work in progress).
 
+
+echo "Checking for 'nocommit' commits"
+
 remote="$1"
 url="$2"
 
@@ -40,11 +43,11 @@
                        range="$remote_oid..$local_oid"
                fi
 
-               # Check for WIP commit
-               commit=$(git rev-list -n 1 --grep '^WIP' "$range")
+               # Check for NOCOMMIT commits
+               commit=$(git rev-list -n 1 --grep '.*nocommit.*' "$range")
                if test -n "$commit"
                then
-                       echo >&2 "Found WIP commit in $local_ref, not pushing"
+                       echo >&2 "Found NOCOMMIT commit in $local_ref, not pushing"
                        exit 1
                fi
        fi

By putting it into a file and using it like this:

$ patch .git/hooks/pre-push < patchfile
Test the push hook

We’re now going to make an ‘empty’ commit, and try to push it. It should fail. If it succeeds – no harm done, nobody is going to really notice anything.

$ git commit -m "sentinel - nocommit - sentinel" --allow-empty
$ git push origin dev

Git should refuse to push this. If so, then it worked. If it did push just fine, delete the remote branch, debug it and try again.

Be very careful about making sure the hook is present. It is not stored in git itself, but only on your local filesystem. Take care if you move your dev branch to another machine and push.

Make all the tailorings you want

This “sentinel commit” will refuse to be pushed. That also means that any commits you make on this branch afterwards will also be refused. You can now make whatever tailorings you’d like, and commit them safely onto dev. They don’t need to contain the magic nocommit keyword from our pre-push hook. Only the sentinel commit does, and we’ve taken care of that.

Go ahead and change those port numbers or build commands. Add whatever scripts or Dockerfiles you like. Nix-ify the entire build. Go wild. Commit it all.

How to get work done

The dev branch is now your base of operations. You will no longer create topic branches off of main, but will do so off of dev.

$ git checkout dev
$ git checkout -b my-new-feature
# do some work
$ ./run-my-secret-tests.sh
$ git commit -avm "fix thingy"
$ git push # uh oh, how do i push this up? fuck

The workflow is almost the same, but you’ll find git won’t let you push your work up at the end. It contains all your tailorings, plus the feature!

To get stuff done, we’ll have to become a little bit familiar with git rebase. Here’s the magic trick:

$ git rebase dev --onto main

This will take my-new-feature, slice off all the commits since the last tailoring you made on dev, and slide them over onto main. Think of it like lifting it off the dev stuff and plopping it down on main.

This branch is now ready to push, with nobody the wiser.

Pulling down other people’s branches

My colleague just pushed up their own fixes-huge-bug. I want to get all my tailorings back while I look at the branch. How do I do it?

Another dash of rebase:

$ git checkout fixes-huge-bug
$ git rebase dev
# browse through the code however you like now

This will put all our tailorings underneath the commits of fixes-huge-bug.

When I said the dev branch will be our base of operations, I wasn’t kidding.

Updating the dev branch

Your dev branch will have been made against a “snapshot” of main at the time it was put together. Work on main carries on, and we wish to have those changes incorporated. How do we do it?

Captain rebase to the rescue:

$ git checkout main
$ git pull # get latest stuff
$ git checkout dev
$ git rebase main
# dev is now sitting atop the latest main

This will take our tailorings and slide the newest main underneath. This could have merge conflicts, for instance if you’ve modified a local server port for yourself and then somebody did it for real in main.

You’ll need to just resolve them if they happen.

Once this is done, you may wish to update topic branches that you’ve made off dev too:

$ git checkout my-great-fix
$ git rebase dev

Again, this slides in the newest tailorings made on top of the newest main happenings, underneath the commits for my-great-fix.

Adding more tailorings later

You’re working on a feature, and you realize you want to add another change for yourself which would be really handy while writing this feature. How do you do it?

$ git checkout dev
# add some more custom stuff for ourselves
$ git commit -vm "added another great local thing"
$ git checkout - # dash goes back to the branch we were just on
$ git rebase dev

With this we can go back to our dev branch, add the additional tailoring, and then come back to our feature branch and slide in the latest dev work underneath. You’ll need to rebase each feature branch you have locally, in order to get the freshest tailorings incorporated into it.

Summary

This is the dev branch pattern. I use it / abuse it literally all the time. Very few repositories go by without me wanting to make some sorts of adjustments for myself.

I hope this trick helps you be a more productive engineer. Please use and abuse it.

https://www.qword.net/2023/10/22/the-use-and-abuse-of-the-dev-branch
Calculus rules everything around me
Word up, know what I’m sayin’? Calculus rules everything around me, C.R.E.A.M.
Show full content

Word up, know what I’m sayin’? Calculus rules everything around me, C.R.E.A.M.

– Wu-Tang Clan, “C.R.E.A.M” (but not actually).

When I was maybe about seven or eight years old, my Dad decided he would regularly sit down with me after school and try to teach me additional math. He would teach me concepts that were a little bit ahead of the curve in school. One day I just couldn’t focus, felt like it was too hard, and had enough.

“I hate math! Why do I need any of this?! I’ll get by with just adding and subtracting stuff, that will be enough!” – Young, stupid qword

I still remember exactly how sad he was to hear me say that, and he was rather silent for the rest of the day. He was an electrical engineer, and used math all the time for his job. Math was what helped him lift his immediate family out of poverty when growing up, and make a better life for them.

I didn’t understand this when growing up, and I think many others in grade school didn’t either. I remember it often being insisted that it would be “important for my future,” but I didn’t know what a “future” was, and “you’ll understand when you’re older” was so common a hand-wave that grown-ups would say that it didn’t have any meaning at all.

I once stayed up all night playing Metal Gear Solid on the PlayStation 2 all the way until 7am, when my dad woke up and lost his shit for me being up all night. I told him that I think I wanted to learn math again because they say you need it to make video games, and like games so that sounded cool. He forgave me and decided not to turn the PlayStation off (we couldn’t afford a memory card at the time, so it’d stay running all the time to not lose progress).

I returned to doing math lessons with my dad, but they tapered off pretty quickly as he got busier with his work. My grades in math took a back-seat all the way until high school, and around then my prefrontal cortex started clicking together and it dawned on me that getting rich is important because money lets you make a better and more comfortable life for yourself. A good school leads to good money and my math grades need to be good enough to get in - so at the very least it was a means to an end, and that’s probably what everyone meant by “it’s important for your future.” I’m maybe thankful that so many other kids in my school didn’t care about math, because it makes knowing it that much more valuable.

I was at least good enough to start a computer science career, and good enough to graduate with the degree. I thought that would probably have been the last use of math that would’ve happened in my life.

Except it absolutely wasn’t.

I honestly and truly use a lot of math, every day. And I don’t mean the “well I program computers and programming is math so I’m doing math ha ha“-argument (which is legitimate) - I use math both at work outside of programming, and in my daily life so often that I don’t even notice, and I think not knowing enough of it is a serious handicap. I’ll even give you a few examples:

  • Lottery tickets are dumb as fuck. Never buy them. You will not win. (But also have the sensibility to not insult people you know who do buy them).

  • How much and when should I drink coffee?

    I was recently watching an interview with Matthew Walker, neuroscientist and author of Why We Sleep. Matthew himself is completely decaffeinated, and does not drink any caffeine whatsoever as it affects sleep quality for the worse. He says that if you were to have a coffee though, then do it no later than 14 hours before you’re going to bed.

    If the half-life of caffeine in adults is 5 hours, how much caffeine is in your body 14 hours later?

    After 5 hours, half of a cup of coffee would be in your blood. After 10, it’d be a quarter. 15 would be an eighth, which is overshooting 14 just by a little bit. The exact answer is to throw 2^(-14/5) into Wolfram Alpha, which gives 0.14, so about 14 percent of that coffee is still in me. That’s not too far from an eighth, so I’m going to modify his advice and say at least 12 hours is likely fine - it’s the first 10 hours that dump most of the caffeine.

    What if I can power through the morning without coffee, but once I hit the afternoon I really just want a bit of a pick-me-up - but then I have to go to bed in nine hours. Could I make a cup of coffee but pour some of it out so that I’d not have too much caffeine in my blood later, trying to catch up to the 14-hour rule? How much do I need to pour out?

    Turns out that dumping exactly half will put me on track if I have about nine hours until bed. 2^((-9/5)) * 1/2 = 2^(-14/5).

    (Yes, I do actually do this. I’m trying to cut back first and then totally quit.)

  • Do not watch stock prices second-to-second.

    If you have some stock that will average a 15% annual return, but with 10% of volatility - what’s the chance that you’re in the green (greater than 0% return) by the year end?

    It’s 93%. Pretty good. I think you’re going to make some money.

    How about per month? With a normal distribution, mean for a month = 15 / 12, stdev for a month = 10 / sqrt(12), and you grab the z-score for the mean / stdev = ~0.43, it’s about 67%.

    What’s the chance that it’s in the green on any given day that you look (260 trading days a year)? 54%.

    Per trading hour? 51.3%.

    Per trading second? 50.02%. You’re almost flipping coins at this point, and red hurts a lot more than green pleases. So don’t look at it so often. You’re going to get a heart attack.

    This is from Fooled by Randomness. Great book.

  • A large pizza is always a better deal than the medium.

    (I’ve never seen this to be false, but run the numbers yourself with your local pizza place).

    A standard medium here is 12”, and a large is 14”. How much more area does a large have compared to a medium? 14^2 / 12^2 = ~1.36. A large pizza is almost a third bigger than a medium (but it sure doesn’t sound like it because two extra inches of diameter doesn’t seem like much)! If the large is more than 36% more expensive, then it’s a losing deal, but otherwise it’s better value. Of course, you may not actually want that much pizza or want to spent that much in total so there’s other things to consider.

  • Trying to get cheap gas.

    There’s a gas station around me that has the best pricing, but isn’t open all the time. I try to calculate exactly how much volume to purchase at a more expensive but 24/7-establishment so that I can cover all the driving I need to do until the cheaper place is open the next day. My car at the time didn’t do any fancy calculations on my behalf or estimate mileage, so I’d do it myself and always be pleased when I nail it. My current car now does do estimations which is tons easier, but not as fun :(

And those are just the most recent examples in real life that I can pull off the top of my head. At my day job, way more:

  • De Morgan’s laws:

    if not (a or b) is the same as if (not a) and (not b) and also if not (a and b) is the same as if (not a) or (not b).

    This occasionally can make if-s easier to read, and is known as De Morgan’s laws.

    You can also “force” a structure where this is applicable by not-ing twice. I use this trick every once in a while on more involved Boolean logic. I’ve seen a lot of juniors not know this!

  • The birthday paradox.

    This one is surprising. If you have 23 people in a room and every birthday of the year is equally likely, the likelihood any two people share a birthday is roughly 50%. This is probably higher in real life, because birthdays are not equally likely in practice.

    We need to calculate a unique, random id per user for some purpose. If these ID are numbers, how many digits do we need such that the likelihood of a collision and re-roll is low?

    With six digits, when generating 1178 ids there’ll be a 50% chance that one of them will collide with another. Seven digits will take 3724 ids, and ten digits will take 117742 ids.

  • Job processing rates.

    We have a queue of stuff to do, that can be done in parallel on multiple machines. With one machine processing the whole queue, it’ll take all day to finish. With 100 machines, it’ll be done in a half-hour but the compute cost would be pretty expensive. We have six hours to complete it all - whats the optimal number of machines to pay the least for compute?

    This one was the most fun to model, and involved a lot of calculus and optimization.

  • Oh yeah, I also write a lot of code so there’s that too. Sometimes I get to do some algorithmic stuff, like work with graphs.

Pretty much, you ought to take math seriously. It lets you solve a lot of actual problems, and I think not knowing (enough of) it causes problems. My friend’s wife struggles to be able to calculate sales tax for things, and things like interest rates and mortgages are firmly beyond her - I think life takes advantage of her for this.

This post is dedicated to my Dad, who aggressively tried to teach me a number of things I couldn’t appreciate until much later.

https://www.qword.net/2023/06/11/calc-rules-everything
Maybe you should store passwords in plaintext.
“Never, ever, think about something else when you should be thinking about the power of incentives.” – Charlie Munger, American billionaire investor.
Show full content

“Never, ever, think about something else when you should be thinking about the power of incentives.” – Charlie Munger, American billionaire investor.

Okay, you probably shouldn’t store passwords in plaintext, but I’ve met a few who do. They don’t store their own passwords in plaintext and they use a password manager for those things, but they don’t hesitate to store credentials at work in plaintext.

Huh? That’s obviously horrible. What gives?

These people are either a little bit unusual, or maybe normal people are the unusual ones. And they don’t just store work passwords in plaintext, there’s other things as well. I first caught wind of their thinking when having just a gentle conversation about work stuff:

Me: “Yeah, so I saw that our login endpoint had a big security vulnerability. I found it, raised it as a big issue and got a few people together across teams to drive a fix. We had a good celebration over that.”

Them: “Huh? Why did you do that?”

Me: “What do you mean? I found an important problem and drove a fix for it. I think that was really good to do.”

Them: “Oh. Yeah, I mean, I guess. But what did you get out of it? Did they give you a bonus?”

Me: “N..o.. I didn’t get anything, but-“

Them: “So you did a bunch of extra work for nothing then? You’re a chump.”

Are they right? Talking some more with people like this, I’ve come up with a list of opinions they have about their work:

  1. One person is aware of almost 100k/mo in unnecessary spend on AWS. They don’t bother to care about it or fix it. They reason that they’ll be punished for fixing it by having to JIRA the issue, bring it into the sprint, discuss it in standup, and not be rewarded with any fraction of those savings financially. Worse yet, it may take longer than expected to fix and they may be punished for it on their performance review. They’ve known about this issue for almost eight months.

  2. Another person simply doesn’t care about shipping code with bugs, and maybe even tries to. They get to shirk actual development duties by fixing their own broken code instead, and the fixes are celebrated. Not only that, but their management thinks that their work must be tricky because of the bugs that appear. “I get paid the same whatever it is that I work on, so I’m going to try to keep my work relaxed and easy.” They considered pretending to have very young children so they can opt out of the team’s on-call rotation that gives no extra pay, but thought that was going too far.

  3. A third literally has about a hundred diffs stacked up that repair innocuous compiler warnings, and they send one or two of them out when they don’t feel like doing their regular work and claim they “stumbled on some issues and fixed them.” They say they figured this out after their last raise was below inflation, and say their new goal is to be “perfectly mediocre.” They’re now working on a plan to quit their job for a “sudden emergency leave” and then negotiate their rejoining at a proper salary increase in a month. They don’t care too much if that doesn’t work out, because they have a second full-time job.

  4. Oh yeah, and all of these people store work credentials in plaintext and don’t care about writing secure code. “A security breach isn’t my problem and avoiding one doesn’t get me anything.”

Now, I would personally feel shame if I did these things. I pride myself on writing good code, on fixing bugs, on shipping things correctly and on time. Seeing bad code frustrates me, and working with bad engineers frustrates me even more. This group of people seem to have been like that at some point in time, and then turned to “misbehaving” in this manner.

“You don’t get rewarded for being extra. You don’t get any money when you save costs. You’re going to get a raise below inflation. You’re stupid for caring the way that you do. The business’ downside risk is not yours, and it’s profits are not yours either.”

I’m not sure I can really come up with a good counter-argument to this, and maybe normal people are all the weird ones for not behaving like this. They’re right in that the incentive structure to perform well.. is missing if you think about it. One person pointed out that the vulnerability I found internally granted me a bonus of $0, whereas if an external researcher found it they’d have been paid a bounty easily in the tens of thousands of dollars. They’re right, and that does sting a little bit.

Is there some way to correct this? How do you reward good behaviour here, and discourage “misbehavior” like this? Not being rewarded with money seems to be the common theme here, but financial incentives are tricky to get correct as evidenced by this Dilbert comic:

Dilbert Comic Strip

Steve Levitt, American economist and co-author of Freakonomics says to not even bother with financial incentives in this 15-year-old video (4:56 long):

“I think the real answer, the real answer […] this is going to sound weird or bad – is to cajole or trick your employees into thinking that what they’re doing is important.”

Doesn’t that … actually sound weird and bad? I’ve been thinking about this for a while, and maybe I really am a chump but it seems like the system says we should all store our passwords in plaintext too.

https://www.qword.net/2023/04/30/maybe-you-should-store-passwords-in-plaintext
LSD: Not even once. Really.
Taking LSD was a profound experience, one of the most important things in my life. […] – Steve Jobs, co-founder of Apple
Show full content

Taking LSD was a profound experience, one of the most important things in my life. […] – Steve Jobs, co-founder of Apple

LSD is a hallucinogenic drug, promoted a lot in tech circles for both recreation and the expanse of creativity it grants you. In recent years it’s been getting a good name, with many of my tech peers encouraging me to try it, some of the “greats”, like Steve Jobs endorsing it, and all manner of reddit anecdata about how it (or psilocybin) had changed their lives for the better, and renewed therapeutic research interests being approved for the drug.

I had dabbled a bit before with psilocybin, and don’t think it changed my life in any real manner other than showing me what mental illness is. I was mostly non-functional, wrapped up in blankets in my bed after eating three grams of the stuff, moving between fits of laughter and heavy bouts of anxiety while having my heart race at a million bpm the whole while. Coming back down to earth, puking all over the place, and remembering what my name was again, was the best part as it meant it was now all over.

So, enter LSD. I had a reasonable idea of what I might expect, having done psilocybin once or twice before. I went on a small retreat with a few friends, and we shared a few tabs. About 160 µg later and it was similar to psilocybin: see-sawing between euphoria and dread, heart rate turned to 11, but now with cool visual effects.

About six hours later, and it would be over. For most people.

It turns out that if you’re very unlucky, you’ll have strong negative side effects that may fuck you up for the rest of your life.

That’s me. I was very unlucky.


Before we go further, have a look at the image below:

Red blue noise

Have you ever seen this? Take a look around you right now, maybe in a dark corner, or on a flat-colored wall. Look carefully. Do you see it?

Maybe you don’t, or maybe it’s not so animated. Do you maybe see something like this instead, on a ‘cream colored’ wall?

Cream wall noise

Maybe you see it now. Or maybe you don’t. It’s kinda like TV static, and the “dots” may be monochrome or colored, “moving” fast or slow or not at all. You might find it more noticeable in the dark, or in the bright. Or maybe only if you focus on it. Or, you might just not have it and that’s fine too.

This is called Visual Snow. I’ve polled many people I know who have and haven’t tried drugs. On both sides, some have had it “since forever,” and others have no idea what I’m talking about. For those I know who do have it, it’s pretty delicate and doesn’t really cause problems. It’s unclear what visual snow exactly is, and what causes it.


Halfway through my trip, about 4 hours in, visual snow started appearing on everything.

It ramped up slowly, and at it’s final form it was crisp, sharp, colorful, full of motion, and a total distraction. All of the time. Always. Everywhere. I was panicking and just asking everybody:

“Do you all see this too ?!”

“Oh yeah, I have that. Don’t worry, you learn to live with it.”

“LEARN TO LIVE WITH IT?! No way! WTF!”

On top of that, the loudest tinnitus you could imagine. I have a rather quiet tinnitus that I’ve had since forever, and it really only bothers me at night. This was a second tone, high pitched, loud, and with some ringing in it. Closing my eyes left me with afterimages, and trying to read in the dark would basically blind me for real.

So let’s sum up. There were a number of ways I was fucked up:

  • First, the visual snow. Frightening and painted over everything.
  • Loud tinnitus.
  • I couldn’t drink coffee anymore. I like coffee. But even a few sips would cause me to get very jittery and terrified over nothing in particular.
  • “Depersonalization.” I felt like I was experiencing life through a movie-theatre screen, and I was “trapped behind it” and unable to escape.
  • Continuous anxiety about literally nothing. I felt like a student who didn’t do their homework, and was dreading their teacher calling on them - for 24 hours a day.
  • Being really “suggestible.” I could think about things and they would appear as hallucinations in the corners of my vision. I could tell they weren’t real though, so it wasn’t exactly psychosis.
  • Oh yeah, I had to continue to hold down a job: coding, working with people, and pretending that I wasn’t brain-damaged and terrified.

All of this added up to serious anxiety (read: right proper suicide and estate planning). I was pretty much convinced that I was going blind and deaf, that my life was over, and that one tiny tiny piece of paper can just fuck someone over permanently. Trying to find solace on the internet, I learned that this entire umbrella of problems was called “HPPD”, Hallucinogen Persisting Perception disorder.

I also learned that it might never go away for some, but you might have a good shot if you cold-turkey quit all recreational drugs. So I quit everything, including alcohol and caffeine.


I’m happy to say that today is roughly a year since that happened, and I’m basically 100% recovered. It took months, with good days and bad days, and now I’m just left with delicate visual snow that I’m pretty sure I’ve had since I was a kid, and is mostly ignorable unless I’m looking for it. Every other issue is gone, and I enjoy coffee on the regular again (and alcohol on the very occasional basis). I’ve quit every other recreational drug, and have given them all away, so I’ll be staying far away.

It’s unclear how things turned out this way, but I think it’s certain that LSD has very real and unpredictable risks for some people. Reading reddit anecdata about how LSD has changed people’s lives for the better - and the army of comments that dogpile on, agreeing - makes me upset at their naiveity and harmful promotion, and I wish to just post this entire story right underneath them and scream from the rooftops about how a single dose can ruin you. If anything, I got lucky with my bad luck, and fully recovered. Some don’t, and have issues for the rest of their lives.

And I didn’t even learn anything cool from the trip. Fuck you, Jobs.

https://www.qword.net/2023/04/23/lsd-not-even-once-really