The Second Project

There is a point in every side project where you finish building the thing and begin building the explanation of the thing. You need screenshots, a concise description, a list of technologies, a link that still works, and a thumbnail that does not look like it was captured through a car window. If you are feeling particularly ambitious, it needs a case study with a problem, an approach, a result, and a lesson that suggests you emerged from the experience as a wiser and more employable person.

In May, I expanded this site’s existing project system with individual case-study pages, richer metadata, hero images, and links from the project cards. I had built software, and then I built a smaller software product whose purpose was to prove that I had built software. Not too sure how I feel about that.

Everything Becomes a Case Study

The case studies on this site follow a reassuring structure:

1. Overview
2. The Problem
3. Technical Approach
4. Results & Impact
5. What I Learned

This is a useful structure. It is also (recruiters look away) not how any of the projects happened.

Real projects begin with something like, “I wonder if this would work,” followed by two days of confident implementation, one week of dependency problems, a complete rewrite, and the gradual discovery of what the original problem actually was.

But nobody wants forty thousand lines of build output, a chronological list of abandoned approaches, and the seven commits named “fix.” Communication requires structure, ad the problem only begins when the simplified version becomes a different reality.

Lossy Compression, Now With Rounded Corners

A project card clamps the description to two lines. It displays three technology badges and hides the rest behind a small “plus” counter. The homepage crowns one project “Featured” by taking the first entry it finds with a boolean set, as if the project won an election. This is, as I’m told, good UI practice. Attention is finite, and a portfolio that treats every detail as equally important communicates nothing.

The difficulty is deciding what can be preserved. If I say I built an offline-first synchronization system, there should be code that synchronizes data offline. If I say I investigated a hardware-performance hypothesis, the results should exist even when the hypothesis failed.

There is a phrase I have started using in my head while editing project copy: the employable truth.

The employable truth is not a lie. It is a flattering accurate version of events. I do not need to mention every false start. I can foreground the strongest technical decision. I can replace “spent six hours fighting a build tool” with “designed a cross-platform build pipeline,” provided a cross-platform build pipeline is what eventually emerged from the fight. The goal is not to include the whole truth. The goal is to make every included sentence true.

Impact Inflation and Other Performance Optimizations

Portfolios have developed a dialect.

Nothing is merely made; it is engineered. Nothing is used; it is deployed. A small improvement an optimization, a database update a zero-downtime migration. Every single number is followed by a plus.

I understand why. Concrete results are more persuasive, but precise language increases the burden of proof. Numbers do not magically become trustworthy because they contain decimal places. A good portfolio does not need to expose every mistake, but it should remain compatible with the evidence.

Negative Results Still Count

Fornax is probably the most honest project on this site because its central idea did not win. I built it to test whether pulsing a heavy vector workload could preserve enough CPU frequency to improve overall throughput. For raw performance, continuous execution remained better because the extra compute time mattered more than the clock-speed penalty.

This is not the ending a portfolio writer would choose for maximum satisfaction, but it is a better ending because it is true.

The project still required systems programming, measurement, cross-platform work, and enough hardware knowledge to make the CPU hot in an academically interesting way. The failed hypothesis is evidence that the benchmark was allowed to answer the question.

The Portfolio Has Bugs Too

This portfolio recently claimed that the x86 testing in Fornax happened on two different processors.

One table contained a typo in the processor model; the actual processor was an i9-11900K. This is the least metaphorical section of the essay. The mistake existed in both the long blog post and the shorter case study because public narratives are software too: facts are duplicated, copies drift, and a confident string can remain wrong for a surprisingly long time.

I corrected all three references and pushed the change. The portfolio is now slightly more accurate.

The mistake was, without a doubt, embarrassing. Hardware identity is not a cosmetic detail in a post about processor behavior. But a correction is not evidence that the project is fraudulent. It is evidence that the narrative remains maintained (The cope is unreal).

Make the Brochure, Keep the Receipts

I am not going to stop making project cards.

The rounded rectangles will remain. The technology badges will continue reducing months of engineering decisions to three colorful nouns. That structure is useful; people have places to be.

A portfolio will always be selective, because selection is the entire point. I hope the person you imagine in your head as you look at it is me.