Eleven exhibits, last time. A career that kept refusing to fit inside a single box — trainer, restaurant owner, postal worker, developer, school ai...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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. 😁
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.
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
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.
The Polish botnet one got me 😅 "assume it's traffic you should be happy about" then immediately checking logs instead cos that's such a specific kind of paranoia and I respect it.
Also not gonna lie, "the tool doesn't wait for me to decide I'm working, it assumes I always am" lives in my head now.
Don't think you need three words for this btw. Sounds less like a job title and more like a personality that occasionally invoices people for it
😂 That last line genuinely made me laugh.
Maybe that's why I struggled with the "three words" question—I've been looking for a job title, while everyone in the comments keeps describing a way of thinking instead.
Also... yes, I absolutely checked the logs. Some habits are stronger than optimism. 😄
Enjoying this series 😃
Thanks! That means a lot to me!
🙏
Careers aren't always linear; they're networks of experiences and skills that build on each other. A timeline can make a journey look scattered, while a graph reveals the connections and patterns underneath. Sometimes the problem isn't the career, it's the way we're expected to present it.
I couldn't agree more. We often spend years trying to "fix" our careers, when the real limitation is the representation we're expected to fit into.
A timeline is convenient, but it compresses relationships into chronology. A graph may be messier, yet it explains why things connect instead of simply when they happened. Thanks for putting it so clearly.
Pascal if Sylwia's actually behind this the piece just wrote its own sequel. But real talk . you've been catching my assumptions before I catch them myself since I showed up here and Exhibit 12 is just you doing it to yourself this time. Graph don't lie.
OG behavior. Case on Sylwia stays open though.😂
Touché. 😄 The graph doesn't lie—but it doesn't stop the investigator from jumping to conclusions either. I'll mark Exhibit 12 as "self-inflicted bias detected." Sylwia's file remains... under review.
Being a generalist who refuses to fit into a single box is actually a massive advantage when building full-stack products, since you end up understanding the entire pipeline from database schema to frontend UX. I noticed this exact dynamic when building PubliFlow, where juggling Next.js, Supabase, and Tailwind meant I had to wear every hat to get the architecture right. It really makes you appreciate how diverse skill sets come together to create a cohesive developer experience. Have you found that your varied background makes it easier to spot edge cases that pure specialists might miss?
That's a great question. I wouldn't say a generalist sees everything better than a specialist—deep expertise is irreplaceable. But moving between domains does change the questions you ask.
When you have touched databases, backend code, infrastructure, UX, business constraints, and user workflows, you tend to notice the boundaries where things break: the assumptions between teams, the missing context, or the edge cases that live between layers.
For me, the advantage has never been knowing everything. It's being able to connect things that are usually considered separately. Thanks for sharing your PubliFlow experience—that's exactly the kind of pattern I was trying to capture.
Spotting those boundary failures is exactly where cross-domain context pays off, since most critical bugs actually originate in the handoffs between teams rather than the code itself. It makes me wonder how we can better design our development processes to capture that missing context before it cascades into a larger production issue.
I think you're touching on something fundamental: boundaries are where information gets lost.
The challenge is that most processes optimize for handoffs ("I gave my part to the next person") rather than preserving the context behind the decision ("why was it designed this way?").
Maybe the missing piece isn't more documentation, but better preservation of the evidence and reasoning behind important decisions. Otherwise every team inherits the output without the context that produced it.
That's one of the reasons I like the locker metaphor: it is less about storing answers and more about keeping enough context to reconstruct how we got there.
Optimizing for handoffs over continuity is exactly why we keep reinventing the same solutions. Treating decisions as disposable artifacts instead of preserving the underlying evidence creates a massive blind spot for future maintainers. If we built our tooling to capture the reasoning automatically alongside the code, do you think teams would adopt it without feeling bogged down?
I think adoption would depend on one thing: whether the tooling captures context as a by-product of the work, rather than asking people to document it afterwards.
Most engineers don't dislike documentation—they dislike writing the same knowledge twice. If the evidence naturally accumulates from commits, discussions, decisions, and runtime observations, then reviewing and curating it becomes much more realistic than recreating it from memory weeks later.
To me, that's the difference between collecting evidence and writing history. One happens while you're working; the other happens after the details have already started to fade.