My Two Cents: Reflections on 30 Days of Daily Coding

Mahamudul Hasan — Mon, 26 May 2025 07:00:20 +0000

On the 17th of April, 2025, I made a decision that has, in many ways, redefined how I look at growth, commitment, and software development.

I promised myself one thing: Code every single day for 365 days.

No exceptions. No rest days. No room for excuses.

It’s been more than 30 days since I made that promise. And I’ve kept it.

This post is an attempt to capture everything I’ve done, built, experienced, and most importantly, learned so far. It’s not just a highlight reel; it’s a reflection — raw, honest, and completely me.

The Beginning: Getting Warmed Up

As of writing this article, I’m building Nebula — my full-stack note-taking application. But the journey didn’t start with Nebula. That came later. At the start, I focused on smaller projects — simple ideas that I could build quickly to get back into the rhythm of writing code daily.

The first couple of days were interesting. I built a random quote generator and a basic clone of Coolors.co — a color palette generator. These were built with plain HTML, CSS, and vanilla JavaScript. And while I did enjoy the simplicity, something felt missing. As I moved through these early projects, I found myself constantly thinking:

“I really wish I was using React and Tailwind.”

That longing became more obvious when I started mimicking Tailwind classes manually in CSS. I was literally writing class names like .flex-items-center and assigning those to HTML elements. That’s when I realized just how much I had grown used to and fond of the superpowers of React and Tailwind. I missed the component-based architecture, the state management, the flexibility, and the expressive syntax that made building UI in React so much more intuitive and efficient.

So even though those first few projects served their purpose, they made one thing abundantly clear: going back to vanilla JS felt like writing with my non-dominant hand.

The Shift: A Taste of Real Projects

Things started to get more interesting around Day 3 when I built a markdown previewer. I used marked.js for the heavy lifting, and while I didn’t write every line of logic myself, I enjoyed building the interface and controlling how the rendered markdown looked and felt. It was the first time during this journey that I worked on something that felt a little less trivial and a little more “real.”

Then came Skye — a weather app I had been meaning to build for a long time. I had always put it off. So when I finally sat down and started working on it around Day 4, I felt a mix of satisfaction and relief. I used the Open Meteo API to fetch live weather data and spent a few days building, refining, and polishing the app. It wasn’t massive, but it was fulfilling.

The Dip: Not Every Day Is Fun

And then there was Taskly. (Very creative name, I know.)

I started this basic task management app on Day 8. The idea sounded exciting at first, but as I got into it, the excitement faded quickly. I realized pretty early that I just wasn’t enjoying it. It felt repetitive, uninspired — even boring. But I built it anyway.

That was the lesson: you won’t be head-over-heels in love with every single project you build. And that’s okay. What matters is showing up. The streak matters more than the thrill. Some days you build out of joy, some days out of discipline. Day 8 was the latter.

Nebula: My Most Loved Project So Far

On Day 9, everything changed.

That’s the day I started building Nebula — a full-stack note-taking app that quickly became the most meaningful project in this entire journey.

The name Nebula is inspired by my love for the universe. I’ve always been drawn to space, astronomy, and the cosmos. Carl Sagan and Neil deGrasse Tyson have been two of my biggest inspirations when it comes to science communication.

Nebula wasn’t just another side project. I had a clear vision — I wanted it to be something substantial, something I could be proud of. I envisioned Nebula as a polished, full-stack application that could not only be a personal tool for me but also serve as a standout piece for my portfolio. I wanted it to be meaningful, to have a purpose beyond just coding for the sake of coding.

I’ve always used tools like OneNote for my university notes, but I’ve never truly enjoyed them. I wanted something that felt lighter, faster, and more tailored to how I work. So I built it. Nebula became both my passion project and my productivity tool.

The Cost of Caring

What I didn’t realize when I started building Nebula is just how deep the rabbit hole would go.

The more serious I got about the app’s quality, the more effort and time it demanded. There were nights when I genuinely felt stressed while implementing a new feature. Not because it was impossible — but because I wanted it to be good.

This reinforced something I already knew — the triangle of cost, quality, and time. You can’t maximize all three. If you want high quality and you’re not willing to compromise on that (which I wasn’t), you’ll end up paying in terms of time and, in my case, mental cost.

I found myself staying up late, obsessing over bugs and UI tweaks. My brain would tell me to sleep, but my fingers wouldn’t leave the keyboard. My soul kept whispering:

“Just finish this one last thing…”

That contradiction — being mentally exhausted but still driven to keep going — was something I had never experienced so intensely before. It made me question something:

Was I actually stressed, or was I just weird?

The very thing that was stressing me — working through bugs, improving performance — was the same thing that kept me hooked. It made me realize that “stress” in development doesn’t always come from burnout. Sometimes, it comes from caring a little too much about getting something right.

Hard Lessons

Nebula taught me more than just technical skills. It forced me to confront the lessons my software engineering degree had already introduced, but in a way that felt real.

One of the biggest ones was planning. Or rather — under-planning.

I thought I had planned Nebula just enough to avoid overthinking. I didn’t want to fall into the trap of analysis paralysis. But it turned out I should’ve planned more. My components started to grow too large. My logic wasn’t as decoupled as I’d hoped. I ended up with modular code — but not modular enough. There was clearly another level of separation and architecture I could have reached.

Technical debt crept in slowly. And then all at once. That exponential growth is no joke.

Now I understand that you can’t always know when you’ve planned “enough.” There’s no obvious line between useful planning and overthinking. But when the debt does creep in — the most important thing is to acknowledge it. Document it. Refactor with intention. Avoid the temptation to pretend everything is fine.

Docs, Performance, and the AI Debate

Another major takeaway was how critical documentation is. Not just your own — but third-party libraries too.

Reading TipTap’s docs helped me fix a nasty performance issue in Nebula. The editor was re-rendering on every single transaction, which caused the frame rate to drop to 25fps — it was painful to use. But after some digging, I found a hook that let me optimize the editor’s behavior. Problem solved. Performance jumped.

I also learned how valuable de-bouncing is when working with events and state updates. Little things like this — things that don’t sound exciting — they’re the backbone of a responsive and smooth user experience.

And yes, I’ll admit it: I used AI throughout this journey. I used it to generate snippets, suggest improvements, and catch bugs, and most importantly, learn new things. It saved me time on repetitive tasks — like writing query selectors or reformatting logic.

But I never let it write code I didn’t understand. That, to me, is where the line is. AI is a tool — not a developer. And we should treat it that way. Let it speed you up, but never let it disconnect you from your own code.

The Thing I Regret Most

I didn’t comment my code.

Not enough, at least.

I knew what I was doing was wrong. I knew future-me would probably be lost in some of those files. But in the moment, I kept telling myself:

“The code is self-explanatory.”

Yeah… maybe. Maybe not.

I hope I’ll be able to understand what I’ve written when I revisit this app months from now.

The Road Ahead

Nebula is mostly complete now. There are a few more features I want to add, and some UI polish I’d like to finish. But it’s usable. It’s functional. And more importantly — it’s mine. I built it with care, frustration, joy, and a lot of caffeine.

It’s something I can proudly show on my resume, share with others, and use for myself. That’s all I wanted when I started. And now, I’m almost there.

Note: This article was originally shared on LinkedIn as part of a personal challenge to code daily for 365 days.

DEV Community: Mahamudul Hasan