Eleven exhibits, last time. A career that kept refusing to fit inside a single box — trainer, restaurant owner, postal worker, developer, school aide, developer again — and a closing question I didn't have an answer to: whose problem was that, mine or the box's.
I still don't have a clean answer. But I didn't stop while I was waiting for one. The same refusal to fit a category, applied to code instead of a resume, produced eight more exhibits. Here's what came out of that.
Exhibit 12 — The Graph
Exhibit 11 ends with me still standing in a classroom, four days a week, helping a kid who isn't mine focus on work that isn't mine either. That's not a metaphor. That's the actual schedule.
The other three days, I build.
At some point I tried to explain this to a recruiter using a normal CV — the linear kind, one line per job, chronological, tidy. It read like someone who couldn't hold a job. Trainer, restaurant owner, postal worker, school aide, developer, back to developer, always developer underneath — but a timeline doesn't show "underneath." It only shows sequence.
So I stopped writing a timeline and built a graph instead. Nodes for skills, nodes for roles, edges for what actually connects them — the same instinct that made me question a CMS or an ORM, applied to my own career. Turns out the incoherent-looking CV was a rendering problem, not a content problem. The data was fine. The visualization was lying.
I don't know yet if a graph reads better to a hiring manager than eleven bullet points. I know it reads truer to me.
The classroom aide job covers part of the month. The graph is what I actually am. I'm still working out how to make those two facts stop contradicting each other.
(The full breakdown — nodes, edges, why a graph beats a timeline — is in Beyond the Linear CV.)
Here's the same instinct, aimed at code instead of a career.
Exhibit 13 — AJC Bridge
I wanted to keep writing on WordPress. Not because it's good — because it's the interface I already know, the one where the friction is zero. But I didn't want the output to live only on WordPress hosting, with WordPress's weight, for an audience that doesn't care what CMS produced the page.
Not a migration. A bridge.
So I built one. A plugin that hooks into WordPress's publish action and pushes the content out to Hugo, Astro, or Jekyll — whichever the destination site runs. Write once, in the tool I already know, ship everywhere the audience actually reads.
The interesting part wasn't the code. WordPress publishing to a static site generator is a solved problem in a dozen half-working ways. The interesting part was resisting the obvious move: dropping WordPress entirely and calling it progress.
It wasn't the problem. It was infrastructure I was fluent in, carrying content I cared about, slowed down by a hosting model that didn't match what I actually needed. The enemy people usually name — "WordPress is bloated," "just use a static site" — was never the real constraint. The constraint was the idea that fluency doesn't count, that the "modern" tool always wins by default.
I entered it in a GitHub Copilot CLI challenge. Top 7%, runner-up, top 25 out of 400+. Not because the idea was original — because most entries solved a technical problem and this one kept a personal workflow instead of throwing it away.
Same instinct as the graph, pointed at my own publishing habits instead of my own career: don't ask what's fashionable to replace. Ask what's actually broken.
(Full writeup: Actually Static: When WordPress Stops Being the Enemy.)
Exhibit 14 — The Memory dev.to Doesn't Give You
dev.to's built-in stats tell you views, reactions, comments — per post, right now. They don't tell you what happened three months ago unless you screenshot it yourself. They don't tell you which article is still quietly gaining readers a year later, or which comment thread turned into something worth following up on. The platform has no memory. It only has a present tense.
I wanted to know my own history. So I started small — local scripts, SQLite, pulling my stats on a schedule and just... keeping them. No plan beyond "don't lose this data."
Small worked until it didn't. Once I wanted to actually query the history — trends, comparisons, which posts age well — SQLite on my laptop stopped being enough. So I rebuilt it as a real stack: FastAPI, PostgreSQL with pgvector, the whole thing containerized and running on my own VPS. I tried Superset for the dashboards first. Dropped it — the learning curve cost more than the output was worth for what I actually needed to see. Streamlit did the same job faster, for less. Built most of it working alongside GitHub Copilot CLI, treating the agent less like autocomplete and more like a second pair of hands on the parts I already knew how to spec but didn't want to type twice.
None of this was commissioned. Nobody asked for a dev.to analytics platform. I built it because a platform that forgets your own history by design is a platform you have to out-remember yourself.
Same instinct again: don't accept the tool's amnesia as a fact of life. Build the layer underneath it. And don't keep a tool just because you already invested in it — Superset taught me that too.
(The build, start to finish: From Local SQLite Scripts to a Cloud Platform with GitHub Copilot CLI.)
Exhibit 15 — The Polish Botnet
The dev.to analytics platform runs on Cloud Run. One month, the bill jumped. Not a little — enough to notice immediately, enough to make me stop and actually read the logs instead of assuming a traffic spike I should be happy about.
It wasn't traffic. It was a botnet, most of it tracing back to Poland, hammering endpoints that had no business being hit that often. Nothing exotic — no breach, no data loss — just noise dressed up as load, quietly billing me for the privilege of being scanned.
The fix wasn't a bigger instance or a rate limiter slapped on top. It was going back to what was actually being exposed, closing what didn't need to be public, and making the rest cost the attacker more than it cost me to ignore. Bill dropped 96%.
The boring lesson: most cost problems people solve by scaling up are actually security problems they haven't looked at yet. Same with most "obsolete" systems people solve by rewriting — half the time the fix is smaller and closer than the rewrite everyone reaches for first.
By now the pattern is automatic: notice the gap between what you assumed was happening and what's actually happening, then close that gap before you touch anything else.
(Full logs and numbers: How I Cut My Cloud Run Bill by 96% by Stopping a Polish Botnet.)
Exhibit 16 — WordPress to Hugo, and Then Further
I wrote up a WordPress-to-Hugo migration as a lightning-fast rebuild: strip the CMS, keep the content, ship something that loads in milliseconds instead of seconds. That article did fine. What it didn't cover is that I kept going after I published it.
A one-off migration script is fine for one site. I didn't understand that it wasn't a script, it was the start of a pipeline, until the second blog. By the third, the pattern was undeniable: different content structures, different plugin quirks, different things that needed mapping instead of just copying. So the script became a pipeline for real — content extraction, image handling, redirect mapping, the parts that don't show up in a "look how fast this loads now" screenshot but are the actual work.
The interesting version of a project is never the one you publish. It's the one that kept getting used after the applause stopped, quietly turning into infrastructure because the alternative was solving the same problem from scratch every time someone asked. The first fix is a demo. The real fix is what's still running six months later.
(Both migrations, written up separately: WordPress to Hugo and, once the pipeline grew up, From WordPress to Astro: Three Days to Reclaim Control. Neither article covers what happened after the second and third client — this is that part.)
Exhibit 17 — GCF Pro
Training organizations in France operate under Qualiopi certification — a compliance framework that dictates how they manage funding, administrative records, and audit trails. Most run this on tools built for something else entirely: generic CRMs bent sideways, spreadsheets held together by habit, or software priced for enterprises with none of the actual compliance logic built in.
I built GCF Pro as the tool I kept seeing training organizations wish they had — self-hosted, PHP, no ORM, no framework heavier than the problem, sold as a license instead of a subscription because these organizations don't want their compliance data living on someone else's SaaS pricing decisions. On-premise wasn't a limitation I accepted. It was the actual requirement, once I understood what "audit trail" means to someone whose certification depends on it.
~28,000 Qualiopi-certified organizations exist in France. That's not a hypothesis, it's a filtered list. What I don't have yet is proof that a list is a market.
(The product lives at gcfpro.fr. Documentation at doc.gcfpro.fr.)
Exhibit 18 — Prospection CRM, and the Extension That Watches With Me
Cold outreach at scale needs a database. Mine started as one — scraped from public Qualiopi records, enriched, campaign-tracked, CNIL-compliant by design because I'd rather build that constraint in than bolt it on later.
The database wasn't the interesting part. The interesting part is what happens when I'm just browsing, not prospecting on purpose. I built a Chrome extension: when I land on a site that looks like a prospect, one click reads the current page and its legal notice — company name, SIRET, phone, the manager's name — and queues a scan of the essentials, security headers, PHP version, performance, the same diagnostic I run at scale, but triggered by nothing more than me looking at a page.
It collapses the gap between noticing something and acting on it. No copy-paste, no switching tabs to a form, no "I'll add this later" that never happens. The tool doesn't wait for me to decide I'm working. It assumes I always am, a little, and gets out of the way.
Exhibit 19 — S&R CRM
A client needed maintenance-contract tracking for heating and plumbing technicians — which building has which equipment, which contract covers it, when the next service is due. The instinct most tools have is to attach a contract to a customer. That's wrong for this industry: customers move, buildings don't. A boiler doesn't care who owns the house this year.
So contracts follow buildings, not occupants. It sounds like a small modeling decision. It's the difference between a system that quietly breaks every time someone sells a house, and one that doesn't.
What started as one client's fix is turning into a standalone product — ScheduleX for the calendar side, Mazer for the interface, the same PHP-native backend as everything else here. Still mid-transformation. I don't yet know if the building-not-occupant model is obvious to anyone outside this one industry, or if it's the whole pitch.
The Verdict
Eight exhibits — a bridge, a memory layer, a graph, a lower bill, a migration pipeline, a compliance tool, a browser extension that thinks alongside me, a CRM that models the world correctly instead of conveniently. Different problems, same reflex, every time: look at what's actually broken before you believe the story about what's supposed to replace it.
Line them up next to the first eleven and something becomes obvious that wasn't obvious to me while I was living it. The career that looked scattered on a resume — trainer, restaurant, post office, developer, school aide — and the projects that look scattered on a portfolio — an ERP, a browser extension, a CV visualization, a cloud bill — are the same shape. Neither is a list of unrelated things I happened to do. Both are what happens when someone keeps asking "what's actually broken here" instead of "what's the standard answer here," across every domain that crosses their path, on a schedule nobody hired them to keep.
I know how to do that. I've never worked out how to say what that is, in three words, on a business card, to someone who has thirty seconds and needs a category before they'll listen further.
So here's the actual question — and it's not a figure of speech: reading through this list, is there something here you'd actually pay for? And if so, what would you call it? I'm not fishing for validation. I'm asking because I've lost the ability to see my own work from the outside, and neither the first eleven exhibits nor these eight taught me how. But there's a second question underneath the first one, and it's the one I actually need answered: not just "which of these has a price," but what does someone who does all of this look like from where you're standing? Is there a name for that? Because from in here, it just looks like the same person solving whatever's in front of them, and I can't tell anymore if that's a portfolio or just a personality.
Top comments (68)
Great read, as usual! BTW this attacker from Poland - it wasn't me 😂😂😂
Are you really sure about that? 😁
Haha you never know, maybe I'm JS dev on a day and dev stats hacker at night 😂
I wouldn't even be surprised—the harmless young woman was actually a formidable hacker known by the code name... oh, but I can't remember your code name anymore—please remind me! 😁
My lawyer adviced me not to tell, but I'll tell you in secret: Acid Burn 😂
Acid Burn... now everything makes sense. 😂 I knew there was something suspicious about that "harmless" JS developer. The investigation continues. Exhibit 20 has been opened. 😁
lol
non-linear paths tend to expose how arbitrary the boxes are. I spent way too long explaining the zigzags before realizing that was what made people nervous, not the gaps themselves.
I think you've put your finger on something important. A non-linear path isn't necessarily confusing by itself—it becomes confusing when it's forced into a format that expects a straight line.
That's exactly the kind of assumption I wanted to question. Thanks for adding your own experience to the discussion.
That framing makes sense, but I'd push back slightly — some zigzags are genuinely confusing to explain because the decisions weren't rational in the first place. You didn't pick the path; the path picked you. No format fixes that, you just own it.
That's a fair point. Not every zigzag hides a grand strategy—sometimes it's just life unfolding in ways you couldn't have planned.
Maybe that's another limitation of linear narratives: they encourage us to invent a perfectly rational story after the fact, when reality was often much messier. Thanks for that perspective.
Agreed. The post-hoc rationalization instinct is strong — and I notice it most in incident write-ups. The clean narrative we write after rarely matches the actual "tried this, that broke, stumbled into the fix" sequence. Messy is usually more honest.
That's a great analogy. We don't just simplify events—we often retrofit causality. Once we know the outcome, the messy exploration quietly disappears from the story.
Ironically, the messy version is often the one that teaches the most.
yeah and I think the clean version warps future decision-making a bit - we start pattern-matching to the simplified narrative rather than the actual sequence of judgment calls we made. the messy version is where the real learning lived.
That's a great insight. We don't just rewrite the past—we accidentally rewrite our future heuristics.
The polished narrative is easier to consume, but the messy one is where judgment, uncertainty, and learning actually happened. That's probably why I keep gravitating toward evidence over storytelling, even when I'm telling a story. 😄
Future heuristics is the right frame for where the real damage shows up. You keep making confident-looking calls that are miscalibrated because the original mess — where calibration actually happened — got overwritten by the clean story.
I like the calibration angle. It's not just that we remember the story differently—we end up training ourselves on a version of events that never actually happened.
In a way, the uncertainty wasn't noise; it was part of the data. Strip it away, and the lesson becomes easier to retell but harder to reuse. Thanks, this has been a genuinely thought-provoking exchange.
the uncertainty-as-data point is the sharp one. most PM post-mortems I see strip the uncertainty to make the narrative legible — and that is exactly when the lesson stops working. you are retelling a story about a decision made in fog using a map drawn after the fog cleared
"A map drawn after the fog cleared" is a fantastic way to describe it.
Perhaps the real artifact worth preserving isn't just the decision path, but the uncertainty surrounding each decision. Otherwise we're training people for clear weather when the next incident will happen in fog again. Thanks for such a thought-provoking exchange.
I really enjoy this series because every exhibit ends up reinforcing the same underlying trait instead of just adding another project to a portfolio.
What stood out to me wasn't any individual exhibit, it was the pattern. Whether you're redesigning a CV, building a CRM, or reducing cloud costs, your instinct is always to stop and ask "what's actually broken?" before reaching for the fashionable solution. That's a surprisingly rare way to approach problems. 😮💨
Reading this also reminded me that portfolios don't always tell the story they're supposed to. Looking at someone's projects individually often makes them seem scattered, but once you understand the thinking behind them, they suddenly become very cohesive.
As for your question at the end... from where I'm standing, I'd describe you less as a web developer and more as a systems thinker. The code just happens to be your medium.
Looking forward to the next exhibit. 😄
Thank you, Aryan. I think you captured something I've been trying to articulate for quite a while.
What often looks like a collection of unrelated projects starts to make sense once you stop looking at the technologies and start looking at the questions behind them. The tools change. The underlying way of thinking doesn't.
And I really like your phrase, "the code just happens to be the medium." I might borrow that one. 🙂 Thanks for such a thoughtful reading.
I like the recurring theme of questioning what is actually broken before replacing it. The examples are very different, but that mindset connects all of them. It also made me think that a career can be better represented as a graph of skills and decisions rather than a straight timeline.
That's a great extension of the idea. We love timelines because they're simple, but they flatten everything into "before" and "after." A graph preserves the relationships that actually explain why things happened. I hadn't thought about applying it to careers, but I think you're onto something there. Thanks!
I read your piece and kept thinking about this line from an unexpected source — Oppose Bookism (1930) by Mao Zedong. The entire Evidence Locker reads like a modern application of it.
A CV is bookism. A title is bookism. A keyword list on a resume — bookism. What you call "evidence" is exactly what Mao meant by investigation: not what you claim about yourself, but what the situation reveals when you actually look at it.
Exhibit 12 (the self-bias example) — that's On Practice: "If you want to know the taste of a pear, you must change the pear by eating it yourself." You couldn't know your own bias pattern until you sat with the evidence long enough to see it reflected.
And Nazar's observation about "questioning the model before the solution" — that's On Contradiction. The primary contradiction isn't the CV, the interview, the title. It's the rendering model that maps those onto "value." Fix the model, not the symptom.
The whole piece boils down to one move: take back the power to define yourself from a classification system that was never built for you in the first place.
Unboxable indeed.
That's an unexpected comparison—and a thought-provoking one. I hadn't connected the article to those texts, but the common thread of "investigation before conclusion" certainly fits.
Your point about the rendering model resonates in particular. We keep improving the artifacts that describe us, while rarely questioning the model that turns them into judgments. Thanks for taking the idea a step further.
Ha, fair point — the rendering model was yours before I borrowed it. Exhibit 14 is probably the cleanest example in the whole locker: you didn't patch dev.to's stats page, you built a different layer under it. Same move every time — don't fix the output, change what produces it.
And honestly the Oppose Bookism connection only works because your piece laid it out clearly enough that someone else could spot it. I just happened to have read that text at the right time.
That's a very good way to put it. "Don't fix the output, change what produces it" might actually be the shortest summary of the whole locker.
And you're right about Exhibit 14: the interesting part was not finding a way to make the existing metric look better, but questioning whether the metric was measuring the right thing in the first place.
I also appreciate the Oppose Bookism connection—not because it was the original source of the idea, but because it shows how a concept can travel across completely different domains. Thanks for adding that layer to the discussion.
It takes a good container for an old idea to feel new again — your locker was exactly that. Looking forward to the next exhibit. 😄
I like that: a good container for an old idea. 😄 Maybe that's the real purpose of the locker—not to discover completely new truths, but to make hidden connections easier to see.
Thanks for adding several unexpected clues to the case. The next exhibit is officially under pressure now. 😉
Thank you for sharing such an excellent post. I really enjoyed reading it.
I’m a Python Full-Stack Engineer with over 10 years of experience designing and building scalable software solutions for clients across a variety of industries. Along the way, I’ve learned that successful projects depend not only on strong technical execution but also on creating real business value.
With my recent contract completed, I’m exploring new opportunities to collaborate with professionals who value innovation, practical problem-solving, and long-term partnerships. I enjoy discussing ideas that combine technical excellence with sound business strategy, creating outcomes that benefit everyone involved.
I believe every connection has the potential to become something meaningful. If you're interested in exchanging ideas, exploring opportunities, or simply connecting with someone who enjoys building impactful technology, I'd be happy to hear from you.
Wishing you success in your future endeavors, and I look forward to connecting.
Thank you! I'm glad you enjoyed it. I also agree that creating business value matters just as much as technical execution—that was one of the underlying ideas behind the article. Best of luck with your next opportunity, and I hope you find a team that values both perspectives.
Thanks. Would you like to take some time to talk each other? Let's discuss further. okay?
Okay, but in a private space (LinkedIn / mail). Contact me, I'll answer.
Hi. Pascal. I sent msg to your gmail.
Check and answer.
Best
Are you interested in earning additional income in cooperation with my team? It will not interfere with your current work. Please contact me if you are interested.
Exhibit 19 quietly answers the question you end on. "Contracts follow buildings, not occupants" is the same move as the rest of the locker, just at its clearest: the CV was a rendering problem, the cloud bill was a security problem, and each time the fix was remodeling the thing instead of accepting its default frame. So the common thread reads less like a portfolio and more like a habit of questioning the model before touching the solution. If you forced me to put it on a business card, I'd go as plain as "I find what's actually broken." Whether a filtered list of 28,000 organizations is a market I can't tell you, but the person who noticed that boilers outlive homeowners seems well equipped to find out.
I really appreciate this reading. "A habit of questioning the model before touching the solution" captures the underlying pattern better than I probably did myself.
And "I find what's actually broken" is wonderfully simple. Whether it fits on a business card is another question—but it certainly feels closer to the common thread than any technology label I've ever tried to use.
Thanks for taking the time to connect the exhibits instead of reading them as isolated stories. That was exactly the challenge behind writing the piece.
The evidence locker framing is useful because careers rarely make sense as a clean title sequence while you are living them. The pattern usually appears later, in the artifacts: what problems you kept getting pulled into, what people trusted you with, and which weird combinations kept producing value.
I really like the phrase "the pattern appears later, in the artifacts."
While we're living a career, it often feels like a series of disconnected decisions. Looking back through the evidence, though, you start seeing recurring questions, recurring constraints, and recurring ways of thinking.
Maybe that's why I ended up calling it a locker rather than a portfolio. I wasn't trying to list achievements—I was trying to preserve enough evidence for the pattern to emerge. Thanks for that insight.
That distinction between locker and portfolio makes sense. A portfolio is optimized for presentation; a locker is optimized for recovery of context. The second one is often more honest because it keeps the messy trail that explains how the pattern formed.
That's a wonderful way to frame it.
A portfolio is meant to persuade. A locker is meant to preserve. If the pattern is real, it should emerge from the evidence rather than from the story we polished afterwards.
I hadn't drawn that distinction so explicitly before. Thanks for adding it.
Yes, that is exactly the value of the locker metaphor. A portfolio can become performance; a locker can stay evidence. The healthier career story is often discovered by sorting through what kept recurring, not by forcing every old decision to look intentional in hindsight.
Exactly. I think that's the subtle difference: a coherent story doesn't have to mean a perfectly planned story.
The danger of hindsight is that we turn every choice into a deliberate step toward a destination that may not have existed at the time. The interesting patterns often appear in the repetition—the problems we keep returning to, the roles we naturally take, and the constraints we keep trying to solve.
Thanks for helping sharpen the distinction between a story we construct and a pattern we discover.
Hey Pascal,
I read it.
The part that landed for me was the refusal to accept the default frame as inevitable. The CV was a rendering problem, not a content problem; the tool limitation was not necessarily the real boundary. That instinct is close to the one that led me to Power House.
As of the public v0.3.24 release, Power House is a deterministic verification and provenance system for portable computational identities. It gives immutable create, fork, merge, verify, replay, and equivalence paths over .pha artifacts and Rootprint graphs. The SFCS path moves supported source and VM execution into deterministic computational-fractal graphs, with RV32I replay/proof surfaces, public and private proof profiles, and packaging through Rootprint and Memory Capsules. SLBIT stays separate as a meaning/observability layer: it can explain verified state, but it does not decide proof identity.
The core bet is simple: computation should not merely produce results that someone has to trust later. It should carry identity, replay, provenance, and observable meaning from the beginning.
I’m not saying the refusal to accept broken defaults is unique to this project. A lot of people who spend enough time inside constrained systems end up building the missing layer. What matters is whether the thing still works under real constraints.
If any of this connects with problems you’re working on, I’m open to talking properly. If not, no issue.
Best,
Julian
Thanks, Julian. I really like your formulation that "the CV was a rendering problem, not a content problem." That's probably a more concise way of expressing what I was trying to get at.
I also agree with your observation about constrained systems. Spending enough time inside one often makes the missing layer impossible to ignore. Whether that layer survives contact with reality is the real test.
I'll take a closer look at Power House—I'm always interested in approaches that challenge the default representation rather than just optimizing it.
I’ve read your “Evidence Locker” idea several times now – it really is a powerful antidote to tribal knowledge and chaotic legacy systems. While thinking about it, I couldn’t help but compare it to the “knowledge graph / ontology” approaches we see in platforms like Palantir’s semantic layer.
It seems to me that your Evidence Locker leans more toward ex‑post observability forensics – collecting runtime evidence to help humans debug and understand what already happened. In contrast, an ontology is more ex‑ante – it’s about business semantic modelling that drives real‑time decisions.
In your practical experience, do these two approaches ever intersect? Should we feed the objective data (logs, traces, etc.) from the Evidence Locker back into the ontology to keep the model updated, or do you think these two architectures should remain completely separate in production? I’d love to hear your thoughts on where you draw the line.
That's a fascinating question. Personally, I don't see the Evidence Locker as competing with an ontology or a semantic layer—they solve different problems.
To me, the locker sits one level below both. An ontology tells us how we believe the world is structured. The Evidence Locker preserves what the world actually exposed under real conditions.
Ideally, they should inform each other. Evidence can reveal where the ontology no longer matches reality, while the ontology provides the vocabulary to interpret evidence. But I wouldn't let one automatically rewrite the other. Models should evolve because evidence challenges them—not because every new observation is assumed to be true by default.
So I'd draw the line at feedback rather than self-modification. Evidence should question the model. The model should explain the evidence. The conversation between the two is where the interesting part begins.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more