Hey folks!

Shame on me, I’ve been working damn hard last month, as well as doing hundreds of other things in between. Even now I’m walking from work to the gym, so sorry for not spamming your feed with numerous articles. I will be a better spammer eventually.

Today is part 2 of stupid mistakes made not by us programmers. They are fundamental, by design, and this time it’s not just bad naming. It’s about rituals we’re forced to do — or get punished if we refuse to.

Enabling “normal mode” in bash

By default, Bash works as a non-stoppable machine:

• Current command failed? Fuck it, go on to the next one.
• Current command produced an error? Fuck it, feed the garbage to the next command via pipe.
• Some variable is undefined? Fuck it, let’s assume it’s empty.

C’mon, the last thing you want your program to do is fail at some point, generate garbage, and continue working with that garbage. But that’s what bash does by default!

The ritual: every bash script must start with set -euo pipefail.

• -e makes bash stop if some command fails;
• -u forbids using unset variables;
• -o pipefail — pipeline fails if any command within it fails.

If you ever forget this ritual, shit will hit the fan, severely. For example:

• Cloudflare going down because garbage was piped down the pipeline
• Entire Kyoto University database wiped due to an undefined variable treated as an empty string

Dumb substitution

The root cause of many mistakes is “dumb substitution”. By that term I mean exactly what it sounds like: putting one string into a placeholder as-is. It backfires. Here are some cases.

SQL injections

SQL injections are a direct result of putting values straight into the query.

SELECT * FROM users WHERE id={USER_INPUT};

Substitute USER_INPUT with 123; ANY COMMAND and run whatever you want.

The ritual: use ORM or parameterized queries, otherwise you’re doomed.

C macros

Dumb simple macros:

#define SQR(x) x * x
int b = SQR(1 + 2);

This expands to:

int b = 1 + 2 * 1 + 2;

And suddenly your macro calculates God knows what.

The ritual: use parentheses around your macro, otherwise you’ll have a lot of fun debugging random values.

Secret key in sources

I love Django for many things, and one of them is that when you run a startproject command, it creates a new project and puts SECRET_KEY directly into your code. Like, you spend your entire career trying not to fuck things up, not to leak secrets, to isolate them; GitHub invents action secrets, AWS invents secret variables; but Django just says "screw it all" and puts your secret right into the code, forever. Thanks, mate!

> django-admin startproject myproject
> cat myproject/settings.py | grep -i secret
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'django-insecure-m&!$#k(56asdf_example_random_string_89123'

Thanks for starting it with django-insecure. You could also put delete-this-secret inside the key, everyone will definitely see it, right?

The ritual: create a project, replace SECRET_KEY = os.environ("DJANGO_SECRET_KEY"), otherwise your key is baked into your code.

Creating async tasks in Python

When you create an async task in Python with asyncio.create_task(), you probably expect the task to… run. Bold assumption. But Python has other ideas. If you don't keep a reference to the created task, it may get wiped by the garbage collector at any moment. "No reference in code" = "not needed". That's how computers think, not humans. Humans think that if a task was created, it should execute (feels like I’ve said that already).

The ritual: save the task somewhere. Happy debugging if you forget.

tasks = []
# ...
def func():
    task = asyncio.create_task(do_stuff())
    tasks.append(task)  # <-- this

The more you go through an engineer’s career, the more rituals you collect. The more rituals you collect, the more likely it is that you forget one of them. It’s not our fault that we forget things, it’s the fault of those who keep adding to that enormous ritual list.

If you want to check how many rituals I remember — and, more interestingly, how many I forget — hire me. Or sign a contract with SlashHash.dev if you’re into B2B stuff.

When building a house, you start with the foundation. It is important to make it solid for two reasons:

• if you make it weak, it will ruin everything you build on top of it, no matter how amazing it is
• fixing it would require an enormous amount of effort, if it’s even possible

The same applies to programming. When you want to write some code, you don’t start with metal and silicon. You use hardware and technologies already created by someone else, and that becomes your foundation. And the quality of this foundation affects everything built on top of it.

Recently I started noticing cracks in these foundations. Guys, they’re everywhere! And more importantly, they affect all those beautiful houses built on top. We write code, but it breaks because the foundation is weak.

It’s not our fault.

Lemme show you.

Let’s talk about stupid names in this part.

Naming things is important. If you name a place “Taumatawhakatangihangakoauauotamatea­turipukakapikimaungahoronukupokaiwhenuakitanatahu”, you make trouble for people trying to spell it. If you give two subway stations the same name, people will fail to meet all the time — I’ve seen it in real life. Naming things in a confusing way leads to mistakes.

Programming is no exception.

In Python, we have re.finditer() to find all occurrences of some pattern. We also have a somewhat similar re.findall() (what for? I have no clue!). Now you want to find a single occurrence — how do you do that? Well, take the first result of re.findall() or re.finditer(), right? No, you fool! Python has a separate function for that, and it's called… no, not re.find(). What’s wrong with you? It’s called re.search()!

To remember, here’s the rule:

• If you want to FIND one occurrence, use re.search
• If you want to SEARCH for many occurrences, use re.find

Easy-peasy!

Now you want to work with a database and instantiate PostgreSQL. Which databases are there by default? Yeah, as you would expect: postgres, template0, template1. Now try to guess what they are for. What if I named them default, frozen_template, and template? See, it’s much better with better names!

Aside from just choosing bad names, one can simply choose the same names. In Linux, there are useradd and adduser commands. They are different. I always prefer one of them, but I don’t remember which one! There are also groupadd and addgroup.

In addition to the name clash, useradd has flag clashes as well:

-g, --gid GROUP          name or ID of the primary group of the new account
-G, --groups GROUPS      list of supplementary groups of the new account
-m, --create-home        create the user's home directory
-M, --no-create-home     do not create the user's home directory
-p, --password PASSWORD  encrypted password of the new account
-P, --prefix PREFIX_DIR  prefix directory where are located the /etc/* files

Try not to confuse -p and -P: the password is not important, so it gets the “small letter p”, and the prefix is really important (you always change prefixes, right?), so it gets the “big letter P”. Maybe. And nobody really knows what will happen if you write useradd --create-home --no-create-home. Maybe the universe will collapse.

Want more similar names for different things? git checkout <branch> switches to the selected branch, while git checkout -- . resets all unstaged changes. Don’t ask, just remember.

On the opposite side, there is also the opportunity to take two similar things and name them as differently as possible! Just like in CSS:

justify-content: center; /* center horizontally */
align-items: center; /* center vertically */

Another example of similar things with different names? Sure — git is a champion here! git switch <branch> is the same as git checkout <branch>. Pick one depending on your mood.

The examples above mostly just slow developers down by confusing them. But can bad naming do something destructive? Sure thing!

In JavaScript, they have a method that checks whether a pattern matches, and they decided to name it test():

> const regexp = /1234/
> regexp.test("12345")
true

What if someone one day forgets that test() does not actually test the whole thing, but just the beginning? Well, that someone could expose the AWS JS SDK repository, because an account ID check would compare only the start, granting access not only to account 1234 but also to 12340, 12341, 12342, etc. Isn’t that nice?

Python also wanted to add some delightful confusion. strip("something") will strip the letters "s", "o", "m", "e", "t", "h", "i", "n", and "g" from the beginning and end of a string. "ethereum".strip("something") results in "reu", and I absolutely love how confusing that is! A classic example is url.strip("https://"), which looks harmless but behaves unpredictably.

One of my favorites is Bash’s &. Look:

• && is logical AND, letting you combine the results of two commands
• & runs a process in the background

Yeah, just one more symbol triggers completely different functionality! So instead of writing A && B — which runs A and then B — people write A & B, which launches A in the background and immediately launches B. I suspect everyone who’s ever written something in Bash has made this mistake. I sure did.

See the pattern? These errors happen because programmers make them, sure — but only because the mistakes were possible, practically handed to us by design! That’s why it’s called “Not Our Fault” — most of the time, we’re just conductors, delivering someone else’s chaos straight into production.

I can carry bad design straight into your project and make it explode! Oh, wait… something’s wrong. Ah, I got it backwards — I’ll actually make your project just work as intended, without unexpected outages. Boring, I know. But if you’re into boring, working things, I’m the person to hire, and SlashHash.dev is the company to call.

Not Our Fault. Part 1: Stupid Names was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I know some people who follow me (thanks, folks!) aren’t really into IT. Maybe some of you are curious about what programming actually is. And no, it’s not just about writing code — it’s much, much more. Let me show you in four short points.

So, as I said, writing code isn’t a big deal by itself. Especially now, when you can ask large language models to spit it out for you. The real deal is everything around it.

Taking responsibility

Developers don’t just deliver code. They deliver working, maintainable code that they are responsible for.

In the era of so-called “AI”, it’s very tempting to offload the writing part to LLMs. But responsibility isn’t something you can outsource. In the worst case, the model will just shrug and say something like, “Oh sorry, you’re right, I completely ruined your business with that code — let me rewrite it.”

Have you ever seen OpenClaw’s “sorry for deleting all your email, won’t happen again”? That pretty much sums it up. AI doesn’t really care. People do.

Another thing to remember: all these models are trained on code scraped from all over the internet. In a sense, they’re an average of that code. And wow, I’ve seen a lot of open-source projects with the structural integrity of a rotten potato. Django, Litellm, LangChain… you name it.

So here’s the funny part: we train models on piles of messy, unmaintainable code — and then act surprised when they produce messy, unmaintainable code.

Garbage in, garbage out. The old law of computing is undefeated.

No trust

I don’t trust AI-generated code. I don’t trust my coworkers’ code either — people make mistakes, and a couple of code reviews is usually enough to prove that.

Honestly, I don’t even fully trust my own code.

I’ve seen enough reviews on things I wrote to know that I mess up too. The real question isn’t “Do I make mistakes?” Of course I do. The real question is: “How many mistakes do I make per 100 lines of code, and how do I reduce that number?”

The same skepticism applies to new technologies. “New” doesn’t automatically mean “better.” Skepticism is a feature, not a bug.

Sure, I know FastAPI, Litestar, even Ravyn. But for a new project I’ll still pick Django. That beast has been around for decades, and it works. Not because it looks nice on a landing page — because it’s been tested in the wild.

Think of it like driving through the wilderness. I’d probably take an old, reliable Ford over a shiny new Tesla. Tesla is cool, no doubt about it. But when you’re in the middle of nowhere, you want something you know will start.

Maybe one day I’ll try something new. When I have enough optimism… and free time.

Trust no one — and you’ll end up building something reliable.

Fighting the unknown

The world of IT moves at a ridiculous pace. Stuff gets invented, updated, broken, and fixed — sometimes all four within the same month. If you work in this field, you’re basically signing up to learn forever.

And code doesn’t live in a vacuum. It needs infrastructure — the environment where it actually runs. And chances are, you’ll have to learn that too.

I’ve been programming for about 15 years, and the last time I learned something new was… yesterday.

This time it was about getting structured logs from my code into Loki, and then figuring out how to display those logs nicely next to charts in Grafana. Not really coding. Still had to learn it.

That’s the job. You keep fighting the unknown, one weird problem at a time.

Go beyond

As I mentioned earlier, programming is way more than just writing code. And it’s even more than dealing with infrastructure or learning new tools. A big part of the job is stepping back and looking at the bigger picture.

Have you heard of the infamous XY problem? That’s when a client has a problem, but thinks they already know the correct solution. So they come to a developer and ask for that specific solution to be implemented.

The novice path — and honestly the typical AI path — is simple: just do what you were told.

The professional path is different. You try to figure out the actual problem and then propose the best solution you can think of.

I’ve seen plenty of situations where a client asked for something inefficient simply because they didn’t see the whole picture. And to be fair, they’re not supposed to. That’s part of my job.

My responsibility is to zoom out and see the whole landscape of possibilities.

So you can probably guess that I’m not really afraid of AI taking my job — at least not anytime soon. AI mostly writes code, while for me writing code is just one small part of the job.

And I’m pretty sure the same idea applies to many other professions too:

• AI can generate music, but it still struggles to create something that genuinely gives you goosebumps.
• AI can act like a psychologist, but it rarely disagrees with you — which can trap people in a destructive validation loop.
• AI can help with legal work… right until it hallucinates a case instead of actually finding one.

We’re humans. When we do our jobs, there’s usually a lot happening beneath the surface. Judgment, responsibility, experience, context — the invisible stuff that never shows up in a prompt or an API call.

And that’s the invisible stuff that matters most.

You can’t see all the invisible stuff, but you can see the results. With SlashHash.dev, those results usually show up in just a few weeks.

Oh, and here’s my CV — take a look!

It’s Not Just About Writing Code was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Happens all the time. You fill out an online quiz, and instead of showing the results it asks for your email. Or a scammer tells you to send money one last time (“it’s the final fee, I swear!”) before you can withdraw your earnings — which, of course, is never going to happen.

These are classic examples of a cognitive bias called the Concorde effect. You’ve already invested time or effort into something, and it feels painful to walk away. Even when quitting is the only logical move, that feeling pushes you to keep going just a little longer.

And honestly, that’s fine. All these little brain glitches are part of being human.

But sometimes those glitches work against us — quietly and automatically. I’ve noticed the same pattern in programming, so here are a few stories, starting small and getting bigger, where you can see it in action. Enjoy.

10 Minutes

During a time-limited screening test for a job, I got a simple task: write a regular expression for a (non-shortened) MAC address. For non-technical readers, here’s the translation: strings like 00:1A:2B:3C:4D:5E or 00:1B:63:84:45:E6, and I had to describe them with a rule.

My first attempt looked like this:

[0–9A-F]{2}:[0–9A-F]{2}:[0–9A-F]{2}:[0–9A-F]{2}:[0–9A-F]{2}:[0–9A-F]{2}

Just “two letters or digits, then a colon, then two letters or digits, then a colon, then two letters or digits, then a colon, then two letters or digits, then a colon, then two letters or digits, then a colon, then two letters or digits”.

Does it work? Yes. Is it painfully dumb? Also yes.

Then I started thinking: this is a senior developer position. I should probably demonstrate some elegance. Something clever.

The clever version would say: “two letters or digits followed by a colon, repeated 6 times — except the last time, when there’s no colon.” That “except the last time” part is where I got stuck. For humans it’s trivial. For computers — and especially regular expressions — exceptions are… exceptional. So I spent maybe 5–10 minutes googling and trying to come up with something short, beautiful, and suitably senior-looking.

Eventually I decided: screw it. Screw the research, screw the elegance. The answer is ugly, but it is an answer, and it works.

I passed the test.

Turns out elegance wasn’t the point. Instead of getting stuck polishing an almost-nice solution, I saved time for the rest of the tasks. I spent ten minutes and threw them in the trash — and that was actually the right decision.

But ten minutes is just ten minutes. Let’s scale this up a bit.

6 Hours

Once upon a time a client asked me to add a dozen new fields to his app. I’ll simplify the story a bit. It was a sports app with fields like football, basketball, tennis, and so on, and he wanted to expand the list.

It wasn’t the first time the client had asked for something like this, and hardcoding all those footballs and basketballs into the source code was starting to look pretty ugly — imagine fifteen of them scattered everywhere. It felt like the perfect moment to introduce EAV.

EAV is not the name of an ancient beast. It stands for Entity–Attribute–Value. Instead of an entity having a fixed set of fields like “football” and “basketball” and nothing else, it can have as many attributes as needed — created by the client, not by me. Instead of messaging “hey Alex, do some coding again,” he could just click a few buttons in the admin dashboard and instantly get whatever he wanted — even alien MMA fights or cockroach races. EAV is flexible and powerful, as long as you implement it properly. So I implemented it. Not a big deal.

Then another problem surfaced. The database had some internal machinery (a “database view”) that aggregated statistics, and it had football, basketball, and the rest hardcoded all over the place. Since those were going away, I had to refactor the view. Not a big deal.

Then I discovered that the JavaScript code powering the interactive parts of the site was broken because — you guessed it — it also had football and basketball everywhere. Fine. I fixed that too. Not a big deal.

Six hours later I was still fixing “not a big deal” problems. Each fix brought the system almost back to life, but something else always broke. Every time it felt like the final step, it wasn’t. There was always one more thing.

So I burned it.

It hurt after six hours of work, but I ran git checkout -- ., wiped out all the changes, and started over. No EAV, no refactoring — just alien MMA fights and cockroach races, exactly as the client asked. The code got a little uglier, but the task was done.

How many more hours would it have taken if I hadn’t stopped? Nobody knows.

2 Months

We once built an app from scratch that started as a tiny automation script. At the time I told the client, “Let’s run it on AWS Lambda — it’ll cost basically $0.” Perfect.

Then the client realized he needed to store some data, so I said, “Let’s add DynamoDB. Still basically $0, and it’ll do the job.” Great.

Then he needed a user interface. So we added that too.

At some point I had to admit that if we kept piling features onto our poor little automation script, it would turn into an unmaintainable monster. It wasn’t a small script anymore, and we needed a different architecture — and different tools — to handle what the app had become.

The client was perfectly reasonable about it. We threw away the Lambda function, DynamoDB, and everything else we had accumulated over two months, and rewrote the whole thing.

It felt like a step backward. I had to rebuild functionality that was already working. But that step back let us move much faster afterward.

Sometimes you have to drop ballast to fly higher.

2 Years

American startup. We were working on advanced text processing and recognition. Today problems like that can be solved in seconds by modern LLMs, but back then it was closer to rocket science — unexplored territory.

Natural language processing. Machine learning. Scraping and normalization. Hyperparameter tuning. Custom algorithms. We tried everything we could think of to make it work.

It didn’t.

Some parts worked, technically speaking, but the overall quality was too low. It wasn’t enough to capture the market. And this went on for two long years.

One day I told my employer: this just doesn’t work. Unless you have some secret technology or a hidden genius waiting in the wings, we’re not going to make it. We’ve tried too much already.

For me, “we’ve tried too much” was a verdict. For him, it was an anchor. And I understand — it’s incredibly hard to abandon a project you’ve poured years of time and money into and start something completely different. He couldn’t do it.

So I left the company. Later I heard the project kept going. Did it succeed? I seriously doubt it. And I’m glad I got off that sinking ship.

Even if it somehow stayed afloat, it would have been wiped out anyway by the tsunami called LLMs.

See the pattern?

When you move through the labyrinth called life, sometimes you hit a dead end. And the moment you see it, be honest with yourself and admit what it means: dead ends lead nowhere, no matter how long the road was. Accept the loss.

Burn whatever you built before, and start over.

Want me to burn your project? Hire me.

Just kidding — I won’t burn it. I’ll make it shine. I turn startup ideas into reality fast. If you want to get in touch, check out SlashHash.dev or my CV.

Burn It and Start Over was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been working as an independent contractor for over a dozen years. Naturally, a lot of those projects were startups.

A biomedical monitoring web app. A gig organization portal for musicians and singers. Massive data analytics for the US real estate market.

A good chunk of them failed.

After seeing this movie enough times, I started noticing a pattern. The startups that crashed and burned had something in common.

But lemme tell you a story first.

There was this cool guy who wanted to build an app to teach people how to play poker — and actually win. The “win” part is important. Anyone can memorize the rules. Consistently making money is where things get interesting.

He’d built a really smart math engine that could look at a table situation and suggest what kind of move would make sense. Not a cheating tool — nothing shady running under the table. This was meant for learning and training. You’d study hands, explore scenarios, understand why one decision beats another. Think gym for your poker brain.

I can’t share the details because of an NDA, but the key point is this: he had a clear goal, and the idea was strong. There’s always a crowd of players who want to level up, and this app aimed straight at that niche — more focused and practical than the existing options.

On paper? Beautiful startup.

So he hired a backend team (I was one of them), a frontend/app team, and a project manager. The engine was on.

I don’t know much about what the frontend folks were doing day to day. I just know they designed screens in Figma and turned them into some shiny modern frontend framework, complete with all the bells and whistles. Or whistles and giggles. Either way, they had plenty on their plate.

I didn’t see much of the frontend world, but I knew our backend inside out.

First thing we built? A monstrously large subscription system. Recurring payments sound simple until you actually try to implement them. Then you discover that “subscription” is a polite word for a hydra.

• It can be recurring or one-time
• It can have a trial period
• It can apply discounts based on weird conditions
• It can be paused, resumed, canceled, partially refunded, fully refunded, retroactively adjusted, and probably judged by a higher court

This is not a “couple of evenings with pizza” feature. This is a full-blown subsystem.

We made it a unified layer over multiple payment providers: Google in-app purchases, App Store purchases, and some Stripe-like service. Having one clean interface for all of them is great. Being the person who has to build that abstraction is… not so great.

And because life wasn’t complicated enough, every payment provider has its own “unique” logic. Unique as in: completely different from every other provider on Earth. Different event flows, different validation rules, different edge cases. My job was to translate that zoo into one coherent system. I suffered.

On top of that, we used Firebase alongside our regular database. Why? Because the expectation was tens of thousands of users. And 10 users and 10,000 users are two different universes. With 10 users, bad architecture politely whispers. With 10,000, it explodes like a dying star.

So we tried to offload as much as possible into Firebase as a fast-access layer in front of the main database. Setting it up felt like reverse-engineering alien technology. The available operations were oddly limited, the patterns were… unconventional. It took effort to make it behave as a proper first line of defense. But eventually, we made it work.

And “eventually” is the key word here.

In a regular long-term project, long coding sprints are fine. You polish, you refactor, you build infrastructure. Startups don’t live in that luxury. They have limited time and limited money. The rule is simple: build a minimal viable product, launch it, gather feedback. Then improve, launch again, gather feedback. Repeat.

Small steps toward a big goal. Not a heroic jump straight to the finish line.

That project chose the jump. We spent a lot of time and a lot of money polishing everything. Infrastructure solid. Payments flawless. Architecture ready for tens of thousands of users. We were prepared for a crowd.

Day X arrived.

No thousands. Not even hundreds. A few dozen.

The app worked. Technically, it was fine. It just… didn’t matter. Nobody noticed.

And that, by itself, is not a tragedy. Startups flop quietly all the time. Maybe the marketing missed the mark. Maybe the demand wasn’t really there. Maybe the world just shrugged. That’s part of the game.

The real problem is timing.

If you discover there’s no traction after a week with a rough prototype, you pivot. You adjust. You survive.

If you discover it after months of development, with a “perfect” product and an empty bank account, that’s not feedback. That’s a postmortem.

That’s how startups die.

Perfection is a luxury item, startups can’t afford it. You don’t begin with marble columns and gold trim. You begin with something slightly ugly that works. You test it in the wild. You let reality punch it in the face.

Start imperfectly.

Ad time.

Even though my paycheck doesn’t depend on a project’s success — I get paid either way — it still feels wrong when months of code quietly fade into irrelevance. Watching something you built with care become “well… never mind” is not exactly motivating.

So now I work with a team that does things differently. We focus on delivering solid, high-quality MVPs in weeks, not months. Something real. Something testable. Something that meets reality early, not after the budget is gone.

If that sounds like the smarter path, talk to us at SlashHash.dev.

Or hire me as a contractor.

When I get moping, I drop everything and write my own game engine. It’s a thankless task, but I like it.

At the very beginning I had a simple plan: whoosh, whoosh, get a pot, throw in all sorts of libraries for graphics, physics and sounds, add a network library to taste, mix everything with some messaging system, and it’s done. A 15 minute adventure.

And here I am five years later.

Well, to be honest, I barely spent any time actually developing, because I kept tripping over all sorts of bugs that drove me mad: serialization didn’t work with inheritance, threads refused to share memory properly, language updates broke compatibility… I could write a whole trilogy about fighting with a game engine. All of this demotivates me, because I want to finally get down to business instead of fiddling with bytes.

This isn’t my video, but it very accurately captures how I have development going on:

On the other hand, when you finally solve these problems, you feel like a god — like the undisputed king of life — and suddenly you want to program again. For a brief moment, it even feels as if that was the last obstacle. Ha. Naive.

But I like it. It’s a bit like mountain climbers choosing to suffer their way up a peak when they could just go to a bar with friends and have a beer. Whatever makes you happy.

I want to talk about one such “obstacle”.

There’s a physics engine called ODE — Open Dynamics Engine. It seems to have emerged sometime in the Paleolithic era. Dinosaurs probably wrote it, and all that remains of the documentation are a few scratches on stone tablets. Still, it works, it’s easy to use, and it comes with C headers. That meant I could write a Nim wrapper and plug it straight into my engine (there’s very little of production-ready libraries in Nim, so the canonical approach is simple: take some C library, learn how to call it, and then proudly tell everyone you wrote a cool program in Nim).

At first, everything went smoothly. I added a few cubes to the scene and rendered them. The physics engine lived in perfect harmony with the graphics engine: when the renderer showed me walking up to a cube and pushing it, the cube actually flew off and started rotating.

In short, everything was going exactly according to plan.

Of course, if you don’t plan to make Minecraft, you may need something more interesting than a cube. ODE has a special Trimesh class that just allows you to make complex geometry. In fact, you can create any body from a set of triangles. Something like this:

The machine is stupid, so you can’t just tell it “draw a rock.” You have to say, “here are some vertices, connect them like this, and we’ll call the result a rock”. Naturally, I didn’t take any chances and decided to start with a simple triangle instead of a rock, just to make sure everything worked correctly.

I created the triangle, it successfully rendered on the stage, I started walking around the world… and discovered that the triangle was not where it was drawn, but somewhere else!

That’s how that stupid invisible wall came to existence.

In fact, I could walk around the scene, and somewhere I came to the very triangle that actually should have been where it was drawn. I expected something like that, because, as I’ve already written somewhere, only three times in my life I’ve written code that worked the first time. I must have mixed up a coordinate somewhere — maybe I have passed Y instead of X, or vice versa, or something like that. You know programmers!

I couldn’t draw this triangle, because the coordinates were correct, the graphics engine drew everything correctly, but the physics engine somehow misinterpreted my correct data. So I started walking around the world and trying to determine the outline of this invisible wall. Eventually I found it (it was weird enough), and I decided to move the triangle around a bit to see how it affected this wall.

It would seem that if I just got the coordinates mixed up somewhere, then moving the triangle would move this wall a little. But no way! The wall disappeared and appeared completely randomly, jumping far away from even the slightest change of coordinates, and I couldn’t understand why.

And that’s when I remembered one silly scene from some movie! A woman with superpowers turned invisible and decided to hide in the rain. That’s a great plan. That’s f***in’ ingenious, if I understand it correctly. It’s a Swiss f***in’ watch.

I thought that was my case, so I decided to rain on my wall to see it. I didn’t have any rain, but I had cubes, so I created 50 of them and started throwing them down. When they touched the wall, they stuck to it and I could see its outline. And when you can see something, debugging is much easier!

Well… It was a good attempt to figure out what law makes a wall appear where it appears, but it didn’t do anything for me. Even seeing this wall, I couldn’t find any pattern.

If you need somewhere to find losers like me, the best place to find them is the internet. And I found him — the only person who went through this and wrote about it. Can you believe that in 2006, some dude in Germany had his butt burning just like mine does now!

So… it turns out that the physics engine expects three-dimensional points from you, but you have to pass them as a four-dimensional vector, you just have to put garbage in the fourth coordinate, like this: [x1, y1, z1, 0, x2, y2, z2, 0, ...]. How am I supposed to understand that const dReal* Vertices are four-dimensional vertices?

That’s why I love opensource — you can always get to the roots of everything. I looked into the source code, and this is what I found.

In 2003 Russel Smith came in and added all this functionality with trimesh collisions, including the line I was interested in:

typedef dReal dVector3[4];

void dGeomTriMeshDataBuildSimple(
    dTriMeshDataID g, 
    const dVector3* Vertices,  // okay
    int VertexCount, 
    const int* Indices, 
    int IndexCount,
);

Everything is clear here, because the definition clearly states that dVector3 is a four-dimensional vector (there is some charm in this logic).

And then Erwin Coumans comes in a couple of months later and rewrites it so that the type is not clear anymore:

void dGeomTriMeshDataBuildSimple(
    dTriMeshDataID g, 
    const dReal* Vertices,  // wait, wat?
    int VertexCount, 
    const int* Indices,
    int IndexCount,
);

And just imagine, 20 years later, this change finds some dude (me) who writes in a different programming language altogether, and makes that dude burn in a futile attempt to figure out why the fuck it doesn’t work.

I rewrite the code with the fourth coordinate added and everything starts working.

Finally.

In general, this post was intended to be entertaining, like “look, Alex is suffering again, hahaha”. But I think it raises a rather deep issue: as soon as you post code, it starts its long journey through time. No one knows when or who will read it — maybe you or a colleague in a couple months, maybe thousands of independent developers in a couple years, maybe some guy with a burning production environment.

You get a kind of butterfly effect, like with this invisible wall. So the next time you sit down to write code, imagine that some developer will be reading it twenty years from now, and try to make that person’s life a little easier. After all, one day that someone might be you.

By the way, I do software development for a living. If you feel like dumping an irresponsible amount of my expertise onto your project, SlashHash.dev is where that happens. Or check out my CV and just hire me.