Looks like my most valuable software development & architecture skill of the past ~ten years is indeed only getting more valuable.

I love producing small, clean, self-contained examples. To understand various concepts better, to explain them better, and to ultimately pick which ones to use and which one to ditch.

And this skill is very, very well aligned with AI-assisted coding!

Because the AI can hack up most simple examples well, and it can tweak them almost perfectly and almost instantly. What it lacks is the sense of beauty.

Both in clarity — is the code aesthetically pleasing to read? And in durability — if we introduce this code to a team of fellow humans, will it proliferate through the codebase in a good way, or will it grow like a bad tumor?

Perhaps in 5+ years my full-time job will be trying out various patterns with and without AI, and labeling them — manually, with experts, with the general public, and with, well, other AIs.

And then maybe people like me will be designing programming languages for the 21st century — because we're long overdue.

I’m sincerely wondering: are there high-profile tech companies that explicitly focus on doing more work async?

It’s kind of trivial. “Let’s have a call about this” should be declared a sign of unprofessionalism — if not outright a banned phrase — for lack of, well, empathy and integrity.

There would be a culture of emails, and a culture of not expecting immediate answers. A culture of doing one’s own research, and a culture of asking for help politely, at the right time, with the right granularity when providing context.

There would be mid- to long-form documents, and a culture of keeping them up to date. Documents with collapsible sections that contain non-trivial yet essential details, for those who need to dig deeper.

There would be scheduled meetings, within the team and cross-team. Single-digit hours per week. Agreed upon by everybody.

And introducing a new meeting — unless it’s consensual right away — would require some formal “board approval.” Any and all direct or indirect pressure to make new meetings happen, or to somehow guilt others into joining unnecessary meetings, would be hunted down and promptly eliminated.

What’s not to love about this?

Just had my first experience with Github Copilot code reviewing my code.

TL;DR: It sucks.

7 comments. One legit, fixed the typo of ${1?: -> ${1:?. Other six are just "this will not work because paths blah blah blah", while in reality I've triple-checked the code myself, and one thing I definitely am sure of is that it works under five different setups.

I stand by my position: it's not impossible that humans will be useful as those meat bags with brains who actually care to understand what is going on behind the scenes. While the value of "making changes" to the code will continue hitting rock bottom.

Is there a quick way to have Linux support MacOS keyboard shortcuts?

I'm a Mac user now, but I still love linux. My keyboard is wireless. With one keystroke it goes from one laptop to another and back.

It'd be great to use the Cmd+C / Cmd+V, as well as Cmd+Enter, Cmd+L, etc. on Linux. Ideally, without even having to flip the physical Win/Mac switch on the keyboard.

Realistically, I can use any Linux these days. Everything is in Docker anyway. So if Ubuntu/Debian is not great for this purpose, I'm willing to give something else a shot. It's the New Year's week after all, might as well cheer the nerd in me up.

So just some zero-configuration reliably working way to have Mac shortcuts work on Linux would be great. I've tried manual mapping, but it's more painful and more fragile than I anticipated. Although if there is a tool or a script or a Github repo for Ubuntu that does the trick, I'd give it a try beforehand.

What do folks like me do these days?

I stopped myself from writing a long post on Docker, but here's the most interesting part.

First, docker leaks containers.

Consider this inc.sh:

#!/bin/sh
echo $(( $(cat /tmp/n.txt 2>/dev/null) + 1 )) | tee /tmp/m.txt && mv /tmp/m.txt /tmp/n.txt

If you run it locally multiple times it'd print one, two, three, etc.

Now consider this Dockerfile:

FROM alpine
COPY ./inc.sh /inc.sh
ENTRYPOINT ["/inc.sh"]

If you run this command multiple times, it will always print 1:
docker run $(docker build -q .)

It will also always print 1 if you do docker build -t dima . once, followed by docker run dima repeatedly.

Each of these runs yields a new container! It will not show in docker ps or docker container ls, but it will in docker container ls -a.

Alas, the universes of images and containers are easy to confuse.

Behold: docker run --name dima dima

This runs this new container and calls it dima. Now there's dima the image and dima the container.

You can't do docker run --name dima dima again because the container called dima already exists, even though it has terminated a long time ago.

You can re-run it though, just docker start dima.

Second, docker leaks volumes.

Now, add VOLUME /tmp to the end of the Dockerfile, and re-do the container:

docker container rm dima; docker run --name dima dima

Now run docker start dima several times. And say docker logs dima. Or just run docker start -i dima.

The number will keep increasing.

Because for the very container called dima there now exists a volume!

And if instead of docker start dima you run docker run dima, it will always print 1. And now we know why: because for each of these runs, a new volume is created. And leaked.

The takeaway from this point is that the universe of running-and-stopped containers exists separately from the universe of built-and-possibly-tagged images.

And then it's "trivial" to wrap one's head around. Because docker run takes an image, and docker start takes a container.

Third, docker compose silently re-uses containers.

Consider this docker-compose.yml:

services:
dima:
build: .

The third line might as well read image: dima.

Now run docker compose up several times. The number will keep going up!

Because while docker run creates a new container every time, docker compose will create containers once.

The "universe of docker compose container names" also exists. It is the same as the universe of docker containers, but with "tricky" naming. The default is the parent directory of docker-compose.yml, followed by a minus sign, followed by the name of the service, followed by a minus sign, followed by the index, starting from 1.

Running docker compose down will actually wipe the volume. But who does docker compose down for one-off pipelines, right?

You could also do docker compose run dima. But you would not if your compose topology consists of several containers. Because up is the way to go.

Fourth, and this is bizarre, volumes are not pruned.

Try this:

docker compose up && docker volume prune -f && docker compose up

The command to prune volumes does not prune them!

And there exists no simple way prune all containers tied to a volume. Here's the "shortest" way:

for i in $(docker ps -a -q --filter volume=$VOLUME); do docker container stop $i; docker container rm -f $i; done; docker volume rm $VOLUME

This "one-liner" is literally at the beginning of my scripts that are meant to be fast, self-contained, and reproducible.

PS: docker compose up does not rebuild containers by default. So, unless you truly want to run the older version, docker compose up --build is a safe default.

PS2: Yes, this is why the use of VOLUME is discouraged in Dockerfile-s. But quite a few containers do have VOLUME-s, for instance, the posgres container. So it keeps data between runs; what's worse, it keeps table schemas too. What a wonderful footgun: your app's DB init code is broken but you're blissfully unaware!

If you've learned something today, my half an hour of typing this was not wasted. You're welcome.

On a completely unrelated note, Veritasium's IQ Test video features Derek looking through a Russian textbook.

The top section of which appears to be the handwriting of a nine years old, likely some exercise homework. Although the hand does not look Derek's, hinting at a simpler explanation.

What's not to love about this? Because surely, with this followers count, we are 100% destined to notice it.

PS: And, on another video of Veritasium today, YouTube was showing me a mental health hotline. Perhaps my browsing history does paint me as a prick when I'm feeling unwell for a day, and choose to watch something mildly educational and fun instead of good old Starcraft.

#Russian

Спасибо @apakhmv, рассказал про Web3. Ещё в прошлом году, а сейчас отлично смонтировали: https://t.iss.one/tfeat/156

По-моему получилось офигенно.

While I dislike Python (and prefer Rust, hehe), one thing it teaches you is that the old "enterprise-grade" Java-world "skillz" are long obsolete.

Because stuff should really a) be short, simple, and descriptive, and b) "just work" (c).

Seriously, I sincerely believe good software engineering taste is that short and clean code with fewer dependencies is generally what we need.

Cargo kicks ass in most aspects here. Python, especially with uv — which is a Rust tool by itself! — is surprisingly okay.

Did not expect myself to say this, but having to deal with TeamCity configuration via .teamcity/* give me shivers. It's been hours, and I can't make "Hello, world!" work. On my own TeamCity instance.

I remember the times when I argued how bad Github's Yaml-based Actions config is. Well, sure, strong typing would be great there — have you considered Cargo and Rust?

But boy, using JVM and gradle to run "workflows" so that I'm getting dozens of unreadable "Kotlin compilation errors" while all I need is to run echo 'Hello, world!'? Call me crazy, but my take here is that the crazy side here is the one that accepts how convoluted this whole thing is.

Challenge accepted. I'll do it. But it's painful af so far.

This post carries a trivial message, but I learned the hard way that its implications are not at all obvious.

The trivial message is: Fixing LLM hallucinations is fundamentally no different from fixing similar failure modes in the human brain.

Corollary: The human brain has basic, low-level failure modes that trace back to a few misfiring neurons.

Here's my mental model. I do not claim it is correct, only that it maps reality reasonably well.

Humans share a tiny set of deeply hard-coded concepts: “good,” “fair,” “just,” “divine,” “love,” “duty,” “pleasure,” “dignity,” “loyalty,” “sanctity,” “disgust,” and a few more. They fit on two hands.

But modern civilization is far too complex and contradictory. Worse, countless actors today are aggressively “prompt-engineering” every human being for their own agendas. The cost of experimentation is near zero and the payoff enormous, so state and non-state actors have no reason not to try to “[re-]program” us. This mass-scale “civilizational programming” has reached heights unthinkable a decade or two ago. And it works.

Many things follow from this model; I will outline one minor and one major.

Minor: Remember that every person’s political and moral views reflect the nonstop nonsense they ingest. Reasonable people can debate the degree of personal responsibility to resist propaganda. But one thing is clear: most people simply repeat talking points without applying any critical scrutiny.

This is not new; what is new is the scale. Our echo chambers and propaganda engines now produce large populations who appear completely deranged—advocating agendas detached from their own lived reality and even harming themselves and their families. Activism can be noble; self-sacrifice for something worthless is emotional deficiency, not virtue.

Major: This applies to you as well — perhaps less than to most if you are reading this, but the logic stands.

No one is immune to stimuli aimed at the inner neurons of “happiness,” “safety,” “self-actualization,” etc. The only viable strategy, if sanity is a priority, is to consciously pick your echo chambers and aggressively filter emotionally charged content.

You also need resistance mechanisms — real ones, not coping mechanisms.

For example, I often find myself caring too much about the emotional state of the average human. It arguably damages my personal life. My rational brain knows exactly what restores balance: recognizing how unsalvageable many people are. Walking past a row of slot machines in Vegas and seeing hundreds of empty eyes pouring millions of dollars into pure uselessness forces me to internalize a basic truth: I cannot meaningfully extend compassion to everyone.

(Yes, gambling addiction is a real disease, and regulations exist for a reason. But most people at those machines are not addicts — they are just “regular humans,” as a friend succinctly puts it. Acknowledging that fact helps me care less emotionally, which is one of many mental tricks I utilize to stay sane.)

The takeaway is: There is nothing wrong or shameful in maintaining an arsenal of mental tricks. To live one’s own life in our increasingly hostile informational environment, we will need stronger internal tools. Begin building them early on, if only to Live Long and Prosper!

The more I’m thinking of where the world is going the more I’m convinced its trajectory is almost exclusively determined by the answer to one question.

Is unconstrained communication the property of the Universe, or is it a social construct?

If it’s the universal property, that would simply mean that any and all at-scale censorship and speech control mechanisms will fail. We can assume they are all ephemeral and temporary, like the Prohibition. Humankind may well eventually give up alcohol altogether, but we appear to have collectively agreed that trying to out right ban it deals more harm than good.

If it’s a social construct, we have to declare that the days of free Internet are gone for good as of some ten years ago. Orwell then just happened to predict the future by generalizing a few observations well.

I know I personally would prefer to live in the world of free communication. Just imagine mesh networks work at any reasonable distance, below any reasonable signal-to-noise ratio, completely undetectable, except the very entity to which / to whom this particular piece of communication is directed.

Yes, I get it, such a world presents major challenges — from tearing apart the social fabric, all the way to literal military risks h heard of before. But if we manage to sustain our civilization, we’d be up to a great start, to conquer the Solar System and beyond.

And yes, I also get it that if the goal is purely to create a “safe and flourishing” world, collectively agreeing that free and unconstrained communication was just a fluke may well be the best first step.

Thankfully, we don’t have to decide any time soon. Various experiments, from European regulations to swarms of self-flying drones, are underway as we speak. We may well have time to course-correct at multiple bifurcation points if and as needed.

But I have to confess declaring free communication dead is something I would feel quite bitter about. And in quite a few corners of the world it can and should be pronounced dead today.

It’s remarkable how many solid language-design choices emerge once you commit to treating types as a zero-overhead runtime abstraction.