The biggest thing I lost wasn't code—it was the story of how I became an engineer.
If I could go back and give my younger self a single piece of advice, it probably wouldn't be to learn another programming language, contribute to open source earlier, or spend more time studying algorithms.
Those things certainly matter, and they've all helped shape my career in one way or another.
But looking back, none of them feel like the advice I needed most.
Instead, I would tell myself something much simpler.
Document the journey.
When I first started programming, I believed the important things would naturally stay with me. I assumed I would always remember the excitement of finishing my first real application, the nights spent chasing bugs that made absolutely no sense, the satisfaction of finally seeing a project come together, and the countless small lessons that slowly transformed me from someone who simply wrote code into someone who started thinking like an engineer.
I couldn't have been more wrong.
Time has an interesting way of preserving the highlights while quietly erasing everything in between. Years later, I can still remember the names of projects I built and the companies I worked with, but many of the moments that actually changed me have become blurry. I struggle to remember what I was thinking when I faced certain problems, what made me nervous before launching something for the first time, or why solving a seemingly simple bug once felt like such a huge accomplishment.
The milestones remained.
The journey slowly disappeared.
Waiting Until I Felt "Qualified"
Looking back, I don't think I avoided writing because I was too busy.
Like most developers, I could always find a few minutes to write a note, publish a short article, or record what I had learned that week. The real reason was much more subtle.
I convinced myself that I wasn't experienced enough.
Every time I considered writing about something I had learned, another voice would immediately appear in my head.
Who would want to read advice from someone who's still learning?
So I kept postponing it.
I told myself I would start documenting once I became a better engineer. Maybe after building larger systems. Maybe after getting more professional experience. Maybe after I had earned the confidence to call myself an expert.
The problem with that mindset is that every new milestone simply creates another reason to wait.
When I learned a new framework, I felt there was still another one I should master first.
When I finished one project, I believed the next one would be more impressive.
When I gained more experience, my standards for sharing became even higher.
The finish line kept moving.
And because it kept moving, the "right time" never actually arrived.
The Version of Me I'll Never Meet Again
Ironically, the version of myself I most wish I could revisit isn't the engineer I am today.
It's the beginner.
The person who approached every technology with endless curiosity, celebrated solving problems that now seem trivial, and experienced genuine excitement every time a new concept finally clicked.
Those early days were filled with questions.
Every project introduced something I had never seen before.
Every mistake taught me something valuable.
Every success felt enormous because everything was new.
Unfortunately, those memories exist mostly in fragments now.
I remember that they happened.
I just don't remember them as clearly as I wish I did.
Sometimes I wish I could open a notebook written by my younger self and read what I was thinking during those first months of learning.
What confused me?
What inspired me?
What challenges seemed impossible at the time?
Those questions no longer have complete answers because I never took the time to write them down.
Why I Admire Developers Who Learn in Public
One thing I genuinely admire today is seeing students and junior developers openly share what they're learning.
They publish small projects.
They write about bugs they solved.
They explain concepts they only recently understood.
They celebrate milestones that more experienced engineers might overlook.
Years ago, I probably would have thought they were sharing too early.
Today, I think they're doing something incredibly valuable.
They're preserving a version of themselves that will eventually disappear.
Five years from now, those posts won't simply be technical content.
They'll become a timeline of personal growth.
A record of mistakes.
A collection of breakthroughs.
Proof that they kept moving forward even when progress felt painfully slow.
In many ways, they're writing something for their future selves just as much as they're writing for everyone else.
Documentation Is More Than a Personal Brand
One of the biggest misconceptions about documenting your work is that it's only useful if you're trying to build an audience.
People often associate writing with personal branding, networking, or attracting recruiters.
Those are certainly worthwhile outcomes.
I've seen firsthand how sharing knowledge can open unexpected doors.
But I don't think those are the most meaningful reasons to document your journey.
The greatest value is much more personal.
Documentation preserves growth.
A GitHub repository isn't simply a collection of source code.
It's evidence that you kept building.
A technical article isn't just something published on the internet.
It's a snapshot of what fascinated you at a particular point in your career.
Even a short LinkedIn post becomes more than an update after enough time has passed.
It becomes a reminder of where your thinking was, what problems you were solving, and who you were becoming.
Progress is surprisingly difficult to notice while you're living through it.
Documentation allows you to see it years later.
The Story Is Still Being Written
One realization has become increasingly comforting to me.
It's never too late to begin.
None of us can go back and document yesterday.
The early projects that were never recorded will probably remain memories, and some of those memories will continue fading with time.
But today is still available.
So is tomorrow.
Whether it's a technical blog, a GitHub commit, a notebook filled with ideas, a personal journal, or simply sharing lessons on LinkedIn, every record becomes another chapter in a story that's still unfolding.
Years from now, those small pieces won't feel ordinary anymore.
They'll become reminders of how far you've come.
Conclusion
When people think about documenting their careers, they often focus on visibility.
Will recruiters see it?
Will it build a personal brand?
Will it create new opportunities?
Those questions matter.
But over time, I've realized they're not the questions that matter most.
The most important audience is often your future self.
One day you'll look back at the engineer you used to be and realize how much has changed. The technologies will be different. Your skills will have evolved. Problems that once seemed impossible will become routine.
What you'll miss aren't the polished achievements.
You'll miss the excitement of learning them for the first time.
That's why I wish I had started documenting earlier.
Not because I wanted more followers.
Not because I wanted more opportunities.
But because I would have loved the chance to meet the younger version of myself again.
And the only way to make sure my future self can meet the person I am today is to leave behind a trail worth following.
Building Software That Solves Real Problems
Writing is one way I share what I'm learning, but building software is where I spend most of my time.
I work with founders, startups, businesses, and organizations to design and develop scalable web applications, AI-powered solutions, cloud infrastructure, and custom software tailored to real business needs. Whether you're starting with an idea, modernizing an existing platform, or looking to integrate AI into your products, I'd be happy to help turn those ideas into something people can actually use.
You can learn more about my work or get in touch here:
Fastwork: https://fastwork.id/byob/7pFhYwWqZd?openExternalBrowser=1&source=byob
About Me
Most days you'll find me building software, exploring new technologies, experimenting with ideas, and writing about the lessons I pick up along the way.
I'm fascinated by software engineering, artificial intelligence, cloud computing, system design, and the process of turning ideas into products that solve real problems. This publication is where I share what I'm learning—not because I have all the answers, but because I believe the journey itself is worth documenting.
If you're building something interesting, whether it's a startup, a research project, a community initiative, or a business that needs technical expertise, feel free to reach out. I always enjoy connecting with people who are passionate about building meaningful things.