Craft
What a technical portfolio is actually for
A grid of screenshots with a list of technologies underneath answers a question nobody asked. Here is the question they are actually asking.
01The reader has one question
Whoever is reading — a hiring manager, a potential client, another engineer — is trying to answer one thing: if I hand this person a hard, ambiguous problem, what happens? Nothing about a technology list addresses that. Everyone has used Postgres. The question is what you did when the query got slow.
02Show judgement, not output
- The constraint you were under. Work with no constraints is a toy, and reads like one.
- The option you rejected, named specifically, and why.
- What the choice cost. This is the single highest-signal thing you can write.
- What broke and what you did about it. Nobody believes the project that went smoothly.
- What you would do differently. It shows the learning did not stop at shipping.
03Make it an archive, not a brochure
A brochure is written once, gets stale, and quietly stops being true. An archive gets added to. Tips, experiments, lessons, a changelog — each individually small, and collectively the thing a brochure can never be: evidence of continuous practice, with dates on it.
That is the bet this whole site makes. Fewer polished slabs, more small, dated, honest entries. It is also much easier to maintain, which is the only reason any of it will still be here in three years.