Hello, imick.io

I have been writing software for years, almost all of it inside private codebases for businesses that paid me to ship features for their customers. The work was real. None of it is visible.

If you searched my name before I started my "public" journey, even with about ten years of professional experience behind me, you would have found nothing. Maybe a dead X account. That is it.

Part of correcting that is starting fresh on GitHub too. I created a separate account some time ago and never really used it. From here on, that is where my public work lives.

This site is me correcting that. It is where I publish the code snippets I keep reaching for, articles on what I am learning and what I think, and courses on the things I know well enough to teach.

It is also where I ship the products I am building to fix daily struggles for individuals and businesses, and where the portfolio of work coming out of my agency lives.

Why I waited

You get a job. You start delivering for that job. You tell yourself you "have" to start building in public, and you never take the time. You are delivering, learning new tech, working out, seeing friends and family. The portfolio stays the thing you keep meaning to do and never get to.

The years I spent heads-down on closed-source projects, behind NDAs and private repos, compounded into knowledge nobody else could see. Every project I shipped ended up inside someone else's product. Every problem I solved stayed inside one company.

Building a public persona matters for anyone serious about their career. A recruiter cannot infer competence from a resume anymore. AI can produce a polished one for anyone, and someone who knows a fraction of what you do can out-shine you with two prompts and better formatting, even when you have been doing the work for years.

I am at the point now where the bottleneck is not skill, it is exposure. The work is good. The work is invisible. The fix is to publish, and the time to have started was years ago.

What I got wrong about learning

I have been learning in isolation. Reading docs, building side projects, taking apart libraries, watching talks, prototyping, throwing things away. All on my own machine.

None of it written down anywhere a future me, or anyone else, could find.

That is a tax I have been paying for years without noticing. Learning is faster when you write it down. Writing is sharper when other people can push back on it. A blog post forces you to clarify your own understanding and put it where you cannot quietly walk it back. Even if nobody reads it, the act of writing it is how the learning actually sticks.

So the policy from here on is simple. If I learn something worth keeping, I publish a short version of it. Snippet, post, note, whatever fits. The cost of writing it up is the price of actually learning it instead of half-learning it.

Why this matters more in 2026

A lot of the work that used to make a developer hireable, knowing the syntax, remembering the API, wiring the boilerplate, is now done in seconds by a model.

What is left is everything else. As a developer or product engineer now, you have to be a strong generalist. Databases, frontend frameworks, backend, deployment, analytics, knowing how to wire a new project end to end and understand what you are doing while you do it. You have to know how to use the models, and the list keeps growing as agentic tools evolve. On top of all that, you need taste and judgment. Knowing why one approach is going to bite you in three months and another one will not.

That kind of judgment is hard to demonstrate on a resume. It is easy to demonstrate on a blog. A handful of posts about real decisions, with the reasoning shown, says more than any list of frameworks ever did.

Personal brand used to be a nice-to-have for developers. Now it is one of the few things that makes you worth hiring over a model.

This is post one. There will be a lot more.