Most engineering portfolios are a scroll: a headline, three cards, a contact form. Mine boots. You get a kernel log, a display manager, and a choice of three sessions — a Plasma-style desktop, a tiling window manager, or a bare console. It is a joke that got out of hand, and then it turned into the most honest thing on the site.

Here is the reasoning, because the reasoning is the point.

A portfolio should be a work sample, not a description of one

I spend my days on things that are hard to show: a test framework validating traffic-sign recognition for cars that are not on sale yet, a matching engine behind an exchange, a migration from a monolith to gRPC services. All of it is under NDA, behind a VPN, or simply not screenshot-able. The industry answer is to write bullet points about it and hope the reader believes you.

So I built something I could hand over. Not a demo of the domain — a demo of the engineering. If you want to know whether I can structure a non-trivial system, decompose state, and keep it maintainable, you can read every line of this one. There is no bundler between you and the source.

The constraints were the interesting part

I gave myself three rules: no frameworks, no dependencies, no build step. Not because dependencies are bad — I use them daily — but because constraints expose whether you actually understand a problem or have only learned an abstraction over it.

You cannot reach for a UI library, so you learn what a window manager really does. Drag is easy. What is not easy is what happens when you drag a maximised window: KDE un-maximises it under the cursor, preserving the horizontal ratio, so the window appears to shrink into your hand rather than jumping. That is four lines of code and it is the difference between "a div you can move" and "a window".

// Dragging a maximised window un-maximises it under the cursor.
const ratio = (e.clientX - win.x) / win.w;
toggleMaximize(win);
win.x = clamp(e.clientX - win.w * ratio, 0, layer.clientWidth - 80);

Where it got genuinely hard

Three places, all of them familiar from backend work.

State ownership. Three shells — desktop, tiling, console — share one window manager. The temptation is to let each shell keep its own window list. That is how you get two sources of truth and a bug you cannot reproduce. Instead there is one piece of state, and shells subscribe to an event bus. Mounting a shell returns a teardown function that unregisters every listener it added. Session switching is then just teardown, mount, relayout — and it works the first time, which is the only real test of whether your ownership model was right.

Layout as a pure function. Early on, layout was scattered: the drag handler set positions, the tiling code set positions, the resize handler set positions. Fullscreen mode broke, because the next relayout pass helpfully undid it. The fix was to make relayout() the only thing that writes geometry, deriving everything from window state. Fullscreen stopped being an imperative act and became a flag that layout reads. This is the same lesson as keeping business logic out of your HTTP handler, wearing a different hat.

Coordinate systems. The resize bug I am least proud of:

// Wrong: the spread shadows the pointer origin.
const start = { x: e.clientX, y: e.clientY, ...win };

win.x overwrites the pointer's x, so every delta was measured against the window's left edge instead of where the mouse went down. Windows jumped on first drag. Two variables with the same name and different meanings, in a language that will happily let you conflate them. In C++ the type system usually catches that shape of mistake for me; here nothing did, which was a useful reminder of what I get from a compiler and how much attention I have to supply myself without one.

What this has to do with backends

Everything, as it turns out. A window manager is a scheduler with a spatial component. A shell is a parser and a dispatch table. The filesystem is a tree with resolution rules and a permission model. Sessions are process lifecycles. Swap the nouns and it is the same work I do in C++ every day: decide who owns which state, make the transformation pure, and be honest about coordinate systems and units.

The performance instinct transfers too. Every layout pass reads getBoundingClientRect() once and batches writes, because interleaving reads and writes to the DOM forces synchronous reflow — the browser's version of cache thrashing. I did not need a profiler to know that, in the same way I no longer need one to know that a hot loop should not allocate. You develop a mechanical sympathy for the machine underneath, and it is not really language-specific.

Was it worth it?

About 4,000 lines, eleven applications, three sessions, zero dependencies. It loads in well under a second, it has no tracking, and it will still run in five years because there is nothing in it to rot — no lockfile, no transitive CVE, no framework major version waiting to break it. That last property is not a party trick. It is the same argument I make when a client asks whether we really need another abstraction layer.

And it does the thing a portfolio is supposed to do. You did not read a claim that I care about correctness and detail. You dragged a window to the edge of the screen and it snapped to half, and now you know.

Try it: boot AlexcppOS. Press ? for shortcuts, or type help in the terminal. If you have a system that needs to be faster or a monolith that needs taking apart, tell me about it.