Hello, World

July 1, 2026•7 min read

personalengineeringfull-stack

Why I'm Starting This

I've been a software engineer for over three years now — working across front-end, back-end, and everything in between. I've built e-commerce dashboards, inventory management systems, microservices, and personal projects like Iokeep (a note-taking app) and Proactive (a task manager).

This blog is my attempt to learn in public. I'll write about what I'm building, what I'm struggling with, and what I'm figuring out. No polished tutorials, no "thought leadership" — just honest notes from the journey.

The Gap Between Knowing and Explaining

There's a difference between being able to build something and being able to explain how you built it. The first is engineering. The second is understanding. I've noticed that when I try to explain a concept to a teammate or write a design doc, I often discover gaps in my own mental model. Writing forces me to fill those gaps.

This blog is a forcing function. If I can't write about something clearly, I probably don't understand it well enough yet.

Short-form content has its place, but it rewards hot takes over depth. I want a space where I can revisit a topic over time, update a post when I learn more, and build a body of work that reflects my actual thinking — not just what performs well in an algorithm.

What to Expect

I'll mostly write about:

Full-stack development — React, Next.js, Node.js, and the glue that holds them together
Project breakdowns — what I built, why I built it that way, and what I'd do differently
Learning notes — when I dive into something new, I'll share what I find

The Stack I Work With Daily

My current role at Molar Intelligence involves a mix of technologies. On the front-end, I work primarily with React and TypeScript, building complex dashboards and user interfaces that need to handle real-time data and complex state management. On the back-end, I work with Node.js and Python microservices, often dealing with data pipelines and API design.

The tools aren't what matter most, though. The patterns are what transfer: how to structure a codebase so it doesn't collapse under its own weight, how to design APIs that teams actually want to use, how to ship features without breaking everything else.

What I Won't Write About

I won't write about things I haven't actually used in production. Tutorials that rehash documentation aren't useful — there are already thousands of those. I'll stick to real experiences, real bugs, real trade-offs.

Who This Is For

Honestly? Mostly for me. Writing forces me to think clearly. But if you're also an engineer trying to get better at your craft — whether you're just starting out or a few years in — maybe you'll find something useful here too.

If something resonates — or if you see me getting something wrong — reach out. I'm always happy to learn from people who know more than I do.

The Kind of Engineer I Want to Be

I think a lot about what makes a good engineer — not just a productive one. Here's where I've landed, at least for now.

Depth Over Breadth

The industry rewards breadth early on. Learn React, then Vue, then Svelte. Learn Express, then Fastify, then Hono. But I've found that the engineers I respect most go deep on fundamentals. They understand how the browser event loop works, not just how to use useEffect. They can explain TCP congestion control, not just how to call an API.

I'm trying to be more like that. Fewer frameworks, more fundamentals.

Systems Thinking

The best engineers I've worked with don't just fix the bug in front of them — they ask why the bug was possible in the first place. Was the code unclear? Was the type system not catching it? Was the review process missing something? They treat every bug as a system failure, not a one-off mistake.

I want to think that way. It's harder than it sounds.

Communication Is Part of the Job

I used to think that if I wrote good code, that was enough. It's not. Design docs, RFCs, code reviews, post-mortems — these are all engineering artifacts. The code is the product, but the communication is how the team builds it together.

Writing this blog is part of practicing that. If I can explain my thinking clearly here, I'll be better at explaining it in a design doc or a pull request.

What I'm Working On Now

Beyond my day job, I have a few projects that are taking up most of my free time.

Iokeep v3

Iokeep is a personal note-taking app I've been building for over two years. The first version was a simple CRUD app with a WYSIWYG editor. The second version added real-time collaboration and markdown support. The third version — which I'm working on now — is a full rewrite focused on performance and offline-first architecture.

I'm using IndexedDB for local storage, CRDTs for conflict resolution, and a sync engine that handles intermittent connectivity gracefully. It's been the hardest thing I've built, and the most educational.

Proactive

Proactive is a task manager I built to solve a specific problem: I wanted a tool that combined a daily planner with a habit tracker. Most task managers are either too simple or too complex. Proactive sits in the middle — opinionated enough to be useful, flexible enough to adapt to how I actually work.

It's built with React, Tailwind, and a Go backend. I'm currently rethinking the data model to support recurring tasks with proper timezone handling — a problem that seems simple until you try to implement it.

Learning in Public

I've been inspired by developers who share their learning process openly. Not just the successes, but the dead ends and the wrong turns.

Why It Matters

When you only see the final result — the polished library, the clean architecture, the successful launch — it's easy to think those things came easily. They didn't. Every project I've built has gone through phases where I was convinced it was garbage, where I almost gave up, where I spent three days debugging something that turned out to be a one-line fix.

Sharing that process is important. It normalizes the struggle. It reminds people — and me — that building software is hard for everyone.

What I'm Afraid Of

Writing publicly is scary. What if I say something wrong? What if someone more experienced reads it and thinks I'm an idiot? What if I write something that ages poorly?

The answer, I think, is that those things will probably happen. And that's fine. If I'm wrong, I'll learn. If someone corrects me, I'll update. If a post ages poorly, it'll be a record of where I was at that point in time. Growth isn't linear, and a blog should reflect that.

The Road Ahead

I don't have a content calendar or a publishing schedule. I'll write when I have something to say. Some months might have multiple posts, some might have none. That's intentional.

What I do know is that I want this blog to be useful — to me, first, and maybe to others. If even one person reads a post and thinks "yeah, I've been there too" or "that's a helpful way to think about it," that's a win.

Thanks for reading. More soon.

title: "Hello, World" date: "2026-07-01" tags: ["personal", "engineering", "full-stack"] excerpt: "Starting this blog to share what I'm learning as a full-stack developer. Here's what to expect."