I didn't want a portfolio
There are those late-June evenings that seem made on purpose to be improvised.
The ones where the heat isn’t stifling yet, the beach is almost empty, and mass tourism hasn’t arrived yet.
The suggestion came just like that, without overthinking it.
“Pizza on the beach?”
It’s hard to say no to an invitation like that.
A little further along, a couple was packing up their things. They were about to leave. We invited them to stay with us. They looked at each other, smiled, and accepted.
After all, pizza and the sea are a combination everyone can agree on.
The evening flows between chatting, laughter, and the sound of the waves.
At some point I make one of my usual jokes.
Silence.
Only one person laughs.
The woman from the couple.
“Yes, that was a nerdy joke…” she says, smiling. “I’m used to your kind of language.”
That’s how I find out she works as a Project Manager for a major banking group.
From there, the conversation takes a completely different turn.
How do you actually prove what you can do?
Between one bit of chat and another, you inevitably end up talking about work. It happens often when you meet someone for the first time.
Talking about mine, I found myself in the situation that, probably, a great many developers find themselves in.
I can tell you what I do.
I can say I develop web applications.
I can list the languages I know, the frameworks I work with, the years of experience I’ve built up.
PHP.
SQL.
Laravel.
JavaScript.
More than ten years of experience.
All true.
But how much of all this can actually be proven?
And it was in that moment that I saw myself on the other side of the table.
Over the years I’ve also taken part in technical interviews to select new developers.
Résumés arrive full of known technologies, frameworks used, and methodologies mastered.
Then the interview begins.
And that’s where you find out the difference between having written something on a CV and having truly understood it.
Every now and then, though, someone shows up who has something more.
A personal project.
A public repository.
Code you can actually read.
A way of thinking you can observe even before asking a single technical question.
And me?
What would I show?
I didn’t want a portfolio. I wanted to tell how I think.
It was in that moment that I realized something was missing.
Not the classic portfolio.
In fact, I’ve always found those pretty uninteresting.
A long list of skills, percentages of language proficiency, and colored bars claiming 95% knowledge of JavaScript.
How do you even measure 95% of JavaScript?
What I’m really interested in telling isn’t the list of technologies I know.
I’m interested in telling how I approach a problem.
Why I choose one architecture over another.
Why, during a meeting, I end up arguing more about the paradigm than the framework.
How I reason when I design something.
How I make technical decisions.
Because, in the end, a language can be learned.
A way of thinking is built over years.
That’s how this space was born
If you’re reading this article, it means that conversation, born almost by chance over a pizza on the beach, had a concrete consequence.
This blog.
A space where I’ll write about software development, architecture, work experiences, ideas, mistakes, experiments, and everything that keeps sparking my curiosity as a developer.
You won’t find step-by-step tutorials.
Nor rankings of the best frameworks.
Much more often you’ll find questions.
Decisions.
Trade-offs.
Because I believe these are the things that truly tell the story of a developer’s work.
Soon the project I’m building on GitHub will arrive too: TrailLog.
It won’t just be a code repository.
Every important decision will be documented.
Every significant phase will be accompanied by articles telling the context, the alternatives considered, and the reason behind the choice.
The code will show the result.
The blog will tell the reasoning.
Because, in the end, the best résumé a developer can have isn’t a PDF.
It’s what they build.
P.S.
The nerdy joke?
That one, at least for today, stays between us.