Tell me you don’t understand software without literally using those words!!!

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

// Output the k! permutations of A in which the first k elements are permuted in all ways.
// To get all permutations of A, use k := length of A.
//
// If k > length of A, will try to access A out of bounds.
// If k <= 0 there will be no output (empty array has no permutations)
procedure permutations(k : integer, A : array of any):
    if k = 1 then
        output(A)
    else
        // permutations with last element fixed
        permutations(k - 1, A)
        // permutations with last element swapped out
        for i := 0; i < k-1; i += 1 do
            if k is even then
                swap(A[i], A[k-1])
            else
                swap(A[0], A[k-1])
            end if
            permutations(k - 1, A)
        end for
    end if

The key to using LLMs effectively is to make sure you already have a solid understanding of what you are aiming to buildbefore you start. You always have to be explicit regarding what you want done at a structural level. The more scaffolding youprovide up front the less room the agent has to go outside your design. A corollary to this observation is that you do haveto understand the domain to make effective use of LLMs. If you are not equipped to evaluate whether the code it producedsolves the problem in a correct way, then you basically end up at a casino pulling a lever on a slot machine and hoping fora decent solution to fall out. LLMs are good at filling in the gaps and doing boilerplate, but you still have to do design andarchitecture the same way you always did.

One solution is to try and care the exact right amount: be invested in work a bit, but also have hobbies and a family and whatever else gives you perspective about your work problems. If you have a rich and healthy personal life, it’s hard to find yourself yelling at somebody about React state management. However, this is a tricky balance to maintain over time.

Polylith is a software architecture that applies functional thinking at the system scale. It helps us build simple, maintainable, testable, and scalable systems.

To print a comma-separated list, a concise idiom is to optionally print the comma first, before the element:

Why not slow down?

Why does it have to be frenetic? Why not just slow down? I suppose you could, but I don’t recommend it. It’s just such a miserable experience to spend your day close-reading LLM output: carefully chewing and savoring each morsel of slop. It’s far less unpleasant to skim through quickly and pick out the useful nuggets of content.

Couldn’t you simply do more of the work by hand? It’s unfortunately true that tech is high-pressure these days. If you’ve got the time and space to work more slowly, that’s great! But when your company gives you a “solve this task ten times more quickly” button, you are heavily incentivized to use it as much as possible, or risk being outcompeted by your peers.

Damn...

Type safety and ergonomics, with full interop.

• Enums and pattern matching

• Error handling with ?

• Nil safety

• Clear error messages

Discover a friendly language for scalable, type-safe systems. Gleam comes with compiler, build tool, formatter, editor integrations, and package manager all built in.

BEAM, cute understandable syntax

A description of some of the recent changes to do allocations on the stack instead of the heap.

Don’t avoid writing something down just because you think it’s obvious. The thing you think is obvious now might recede into your subconscious in an hour; get it written down while you can! And don’t avoid writing something down because you think it’s dangerous to say and everyone already knows it. For people new to the area, reading your words can help them feel like they’re not losing their minds. Finally, once you write down the obvious thing, it allows you to go on and draw out the parts that are less obvious, in a way that you couldn’t do if you try to just skip straight to the subtleties.

This is status-driven orchestration, and it is the most popular way in the industry to build a finite-state machine while loudly insisting you are doing nothing of the sort. The denial is the interesting part. Everyone agrees that explicit state machines are good in the abstract—the way everyone agrees that flossing is good—and then goes home and writes another cond/1 that branches on a string.

Writing clojure code by hand on a Remarkable, it gets executed

In the debrief, BG shared some advice for actually getting good at Clojure: work through the problems on 4clojure using only the official documentation (not ClojureDocs, which include examples!) and the Clojure source code.

4Clojure is a collection of programming problems that teach you the standard library, each problem building on the one before it, kind of in the spirit of The Little Schemer. The reason to go through it looking at source code rather than examples is to force you to reason from first principles (the implementation) rather than from someone’s ideas of how code is written.

Demonstrating the basics of logic programming with data from the Pokémon games.

Меня просто нечеловечески бесит, когда разработчики оправдывают собственную некомпетентность мантрой «бизнесу надо». Если программист любой степени квалификации, от стажёра — до принципала — использует в качестве аргумента в любой дискуссии фразу «бизнесу надо» — знайте, перед вами тупой самозванец, гоните его в шею.

Пример, как можно сделать свой режим в Емаксе, привязать его к конкретным файлам и назначить свои шорткаты только для этого режима.

Clean Code doesn't work—not because the principles are wrong, but because the real world is dirty, chaotic, unpredictable, and asynchronous. The best code I’ve ever seen violated a good half of Clean Code’s commandments.

If a developer claims the badge of mid-level-plus but doesn’t feel at ease in at least the five principal paradigms—they are a pompous fool, and you should show them the door.

Little language inspired by Rust that compiles to Go.

Some degree of ownership over the code you write is inevitable and probably healthy. You should care about the things you build! But that doesn’t mean you have any actual ownership. The codebase you spend time on at work is the company’s codebase, and they can do whatever they want with it. You should communicate the risks and consequences of decisions, but ultimately it’s not your call.

An overview of what makes modern CSS so awesome.

The 2025 Go Developer Survey results, focused on developer sentiment towards Go, use cases, challenges, and developer environments.

Platypus is a developer tool that creates native Mac applications from command line scripts such as shell scripts or Python, Perl, Ruby, Tcl, JavaScript and PHP programs. This is done by wrapping the script in a macOS application bundle along with an app binary that runs the script.

Following are the main red flags in test assignments that should be avoided:

• The assignment was read and understood in full.

• All parts are implemented.

• Industry-standard tools and frameworks are used.

• The code is split into small, readable functions.

• Variables have descriptive names.

• Complex parts have comments.

• Errors are handled, error messages are easy to follow.

• Source files are organized reasonably.

• The web interface looks nice.

• There are tests.

Avoid these AI giveaways and spread the word!

I've written a number of little scripts over the years, many of which I use every day. Here's a little collection.

The safest and most reliable way to deal with feature flags is to hardcode them

This is the first result to break the O(m+ n log n) time bound of Dijkstra’s algorithm on sparse graphs, showing that Dijkstra’s algorithm is not optimal for SSSP.

The more time you spend designing systems, the more paranoid you get about things going wrong

Occasionally, you will see the opportunity to completely remove the worrying part of the system, which for me is one of the most satisfying things you can do as a software engineer. Removing things that cause your team stress has compounding benefits to your team, to the systems you work on, and to your engineering org in general