DEV Community: Lucy

Developers don’t have a productivity problem. They have a memory problem.

Lucy — Mon, 13 Apr 2026 22:07:49 +0000

Every developer knows this feeling. You’re deep in a build, everything is going well, you’re in flow state… then suddenly you need something you’ve already written before. A snippet, an idea, a fix, a link, anything.

You know you’ve seen it somewhere. You just don’t know where. So you stop coding and start searching. Discord, Notion, old projects, random files, browser bookmarks. Tabs start to pile up, whilst your focus slowly disappears while you try and retrace you own steps.

And when you find it, the momentum is gone. I used to think this was an inevitable part of being a developer, but over time I realised something important: I wasn’t losing code, I was losing context. And that is a much bigger problem.

The real issue isn't writing code. Developers don’t usually struggle because they can’t build things. Most of the time, the actual coding isn’t the hard part. The real issue is everything around it: the fragments of information that never stay in one place. Snippets end up in Discord messages or random files. Ideas get dumped into notes apps, just to be forgotten, or useful links are buried in your browser history. Fixes live inside old projects you never think to open again.

We don’t have a skill issue: we have a fragmentation problem, which quietly is slowing everything down. Not obviously, but through small, constant interruptions that break focus and force you to rediscover things you’ve already solved before.

At some point, I did what most developers end up doing: I tried to fix my workflow, using Notion, Obsidian, GitHub Gists even bookmarks, folder systems and even “just being more organised”. They all worked at first. But they all broke for the exact same reason. They require you to put in effort at the exact moment you don’t have any.

When you’re in flow, you’re not thinking about organisation, you’re thinking about solving the problem that’s in front of you. So, everything gets dumped wherever it’s fastest to continue, eventually turning temporary storage into permanent chaos. So, you don’t end up with one perfect system, you end up with 10 half-broken ones.

The real shift occurred when I realised I didn’t need another notes app, with more structure, or stricter habits. I needed something that could work with the way developers actually think whilst working: something that could capture context without interrupting it. This is how DevFlow came about.

DevFlow is a developer-focused second brain that is designed around one simple principle: your work should have a memory layer. Not a separate system that you have to maintain, but something that sits quietly underneath everything you do, capturing what matters as you go.

DevFlow lets you save snippets, notes, ideas and links instantly without breaking your flow. Everything you capture is automatically organised by project, so your work stays grouped naturally, instead of scattered across multiple unrelated folders.

You can search everything you’ve saved in milliseconds, filter by project, and quickly retrieve anything you’ve written before. The goal isn’t to add another place to store things, it is to remove the friction between thinking something and saving it. Think of it like Notion, GitHub Gists and Recast combined, but rebuilt specifically for developers who want to stay in flow state.

Most tools assume that you have time to organise your thoughts properly. Developers don’t. Notion is powerful, but it’s too slow and structured for quick capture. Gists are useful but isolated. Notes apps are flexible, but can become messy very quickly.

The problem isn’t that these tools are bad, but that they aren’t designed for real-time thinking while coding. They sit outside of your workflow instead of in it.

This isn’t just about saving snippets, or organising notes, it is about protecting your flow state, removing the moment where you have to step back and ask “Where did I put that?” It is about ensuring ideas don’t disappear just because you had to focus on something else, because in development, the biggest loss isn’t bad code, it’s forgotten progress.

Right now, DevFlow is in its early stage. I’m building the MVP around a few core ideas: projects, instant capture, fast search, and a clean dashboard. But my long-term vision is much bigger.

DevFlow is moving towards becoming a full memory layer for developers, which includes semantic searching across everything you’ve ever saves, automatic tagging, deeper connections between ideas and integrations with tools like VSCode and browsers, so you can capture anything instantly.

I’m currently validating the idea and building the first version of DevFlow. If you’ve ever lost something you knew you saved, or felt like your workflow is more scattered than it should be, you probably understand why this matters.

I’m opening up early access as I build, so if you want to follow along or try it when it’s ready, you can join the waitlist here.

DevFlow

We don’t need more tools to store information, we need better systems for remembering it. That is what DevFlow is trying to become: a memory layer for developers so you can stay focused on building, not searching for what you already built.

I Built A Full-Stack App in 7 Days: Here’s Day 1

Lucy — Mon, 06 Apr 2026 16:23:47 +0000

I decided to challenge myself in a way that I have been considering for a while now. Build a full-stack application in only 7 days, completely from scratch, to completely real and usable. Not just a tutorial project, a clone of something that already exists, but something that I have designed, created, and shipped by myself.

There’s something about coding projects like these that make them feel almost deceptively simple in the beginning. You think the hard part will be writing the code, but in reality, the hardest part is normally finishing them. Most people don’t fail because they can’t write the code… they fail because they never fully complete anything. They always stop somewhere between ‘idea’ and ‘almost done’.

So, I wanted to remove that entirely. I stuck to no over-planning, no perfect architecture diagrams, and no time wasted endlessly researching the ‘best possible’ stack. Just 7 days of building, documenting and continuing on forwards no matter what happens. This is Day 1.

Day 1 started almost exactly like you would expect. I was staring at my laptop’s blank screen, trying to decide what I was going to build. This part is always more difficult than people admit. Not because it is necessarily difficult to think of ideas, but because it feels like you have to have the perfect idea before you even begin.

However, I forced myself to follow one simple rule: if I couldn’t explain the project in one sentence, and why I wanted to build it in one more, then I wasn’t allowed to build it yet. That alone removed a lot of the noise. After cutting everything down, I ended up with a relatively simple direction: build a full-stack app that is actually useful, is small enough to build in one week, but also flexible enough that I can expand it later.

It was nothing revolutionary, just something real that I could actually build and improve on. So, once I had that clarity, I stopped planning and started building almost immediately.

For the first day, I didn’t focus on building features. I focused instead on setting up my foundations properly so I wouldn’t regret it later on down the line.

I chose a stack that prioritised both speed and simplicity: Next.js for both the frontend and backend, Supabase for authentication and database, and TailwindCSS for styling. I decided not to waste time deciding about tools; I just picked what let me move quickly.

I created the project, set up the basic structure, connected Supabase, and got the environment variables working. It doesn’t sound like a lot on paper, but this is the stage, when developing something new, that everything either goes smoothly or starts to become a mess later on.

There always happens to be a moment during the setup where things feel slightly messy and fragile, like one wrong configuration could break everything. But, after a bit of trial and error, I got it running cleanly.

That moment when the app finally boots without errors is always underrated. It is the point, where for the first time, the project stops being an idea, and begins to transform into something real.

My biggest win on Day 1 wasn’t building a feature, or writing some complex logic. It was simply getting everything to connect properly. The front-end loaded correctly. The backend responded. The connection to the database worked. There were no errors flooding my terminal.

It sounds basic, but these small confirmations mattered more than anything else early on to me. They were the things that gave me momentum. Without that, each of the next steps I took would have felt uncertain. Instead, everything felt possible.

Of course, my Day 1 wasn’t completely smooth. Even on Day 1, I ran into the usual setup issues: Environment variables wouldn’t load properly, there was some confusion over my Supabase setup, and some smaller decisions about folder structures that, looking back, I probably spent way too long thinking about. Nothing too major, just enough to slow things down only a little.

What I found most interesting was that most of these problems weren’t actually problems related to coding. They were setup problems. And setup problems always feel worse than they actually are, because they block everything else from moving forwards. Once I had that realisation, it became a lot easier to stay calm and focus on fixing things one by one, instead of overreacting and panicking.

Looking back at the first day, the main lesson I took from it wasn’t technical at all. It was all about my speed and momentum.

It reminded me that planning is only useful up to a certain point. After that, it becomes a delaying tactic cleverly disguised as productivity. Progress only really starts when you begin to build something that exists outside your head.

It also reinforced something that I have noticed before: that getting something running, even if it is in its most basic form, is far more important than making it perfect. Perfection can come later, but functionality has to come first.

Most importantly, it showed me that momentum is everything. Once the project is alive, even in a basic form, it becomes much easier to continue.

Day 2 is where things will start to get interesting.

Now that the foundation is in place, I will start to build actual features: real UI components, authentication flows and the first real pieces of functionality that turn my project from just a setup into something users could actually interact with.

Right now, I have the scaffolding. By Day 2, it starts to become a product.

If you enjoyed this post, make sure to subscribe so you can follow everything I’m building in real time.

Also, check out My SubStack, where I am turning this into a 7 part weekly series.

👉 lucybatten.substack.com

If you have any questions, connect with me on LinkedIn:

👉lucybatten

If you want to see how ideas turn into real apps (and what ends up happening along the way), check out the rest of the posts in this series.

More builds, more problems, and more fixes… coming every week.

Make Your CSS Look 10x More Professional with These 11 Underused Tricks You Might Be Missing

Lucy — Sat, 04 Apr 2026 13:28:43 +0000

I think a lot about CSS... not because I enjoy suffering, but because I enjoy when things finally look right.

CSS is one of those things that looks simple on the surface… until you try to build something that doesn’t look like it was designed in 2009.

But here’s the thing: most people only learn the basics: margin, padding, display: flex, then stop there.

And that’s exactly why a lot of websites feel… average.

If HTML is the skeleton of the web, CSS is the personality. It’s the difference between “this works” and “this actually looks like a real product.”

So let’s fix that.

Here are 11 CSS tricks that instantly make your projects feel more professional, more modern, and way less “tutorial-like”.

1. aspect-ratio: stop fighting image sizing

Instead of hacking around padding tricks, just define proportions.


.box {
  aspect-ratio: 16 / 9;
}

Perfect for cards, videos, and responsive layouts.

2. clamp(): responsive sizing without media queries

h1 {
  font-size: clamp(1.5rem, 4vw, 3rem);
}

It scales smoothly between a minimum and maximum value.

3. scroll-snap-type: make scrolling feel premium

.container {
  scroll-snap-type: x mandatory;
}

Great for carousels and full-screen sections.

4. backdrop-filter: instant glassmorphism

.glass {
  backdrop-filter: blur(10px);
}

Gives that frosted glass effect you see in modern UI.

5. :is(): cleaner selectors instantly

:is(h1, h2, h3) {
  margin-bottom: 1rem;
}

Less repetition, more readable CSS.

6. gap (with flexbox): stop using margins for everything

.container {
  display: flex;
  gap: 1rem;
}

Cleaner than manually spacing children.

7. object-fit: fix image distortion forever

img {
  object-fit: cover;
}

No more stretched or squished images.

8. position: sticky, gives underrated layout power

nav {
  position: sticky;
  top: 0;
}

Feels like JavaScript magic, but it’s pure CSS.

9. min() / max(): smarter responsive sizing

width: min(90%, 600px);

Prevents layouts from getting too big or too small.

10. will-change: smoother animations

.card {
  will-change: transform;
}

Helps the browser optimise animations ahead of time.

(Use sparingly... don’t spam it everywhere.)

11. accent-color: style native inputs instantly

input {
  accent-color: #6c5ce7;
}

Checkboxes, radios, and sliders finally match your design.

Most developers don’t lack creativity.

They just don’t know what CSS is already capable of.

These features don’t require libraries, frameworks, or hacks—they’re built into the browser.

And using them properly instantly separates “beginner-looking UI” from “this feels like a real product”.

🚀 Thanks for reading!

If you enjoyed this post, feel free to connect and follow me for more content on web development, CSS, and programming in general.

Stay consistent, keep building, and don’t be afraid to experiment with things you haven’t used before.

Let’s connect:

GitHub → https://github.com/lucyb0207
Substack → https://lucybatten.substack.com
X (Twitter) → https://x.com/lucyb0207
LinkedIn → https://linkedin.com/in/lucybatten
Website → https://lucyb0207.github.io

What I Would Do If I Had To Learn Programming Again

Lucy — Sat, 04 Apr 2026 09:21:04 +0000

If I had to learn programming again completely from scratch, I wouldn’t start with tutorials. Not because they are necessarily bad, but tutorials make everything feel much clearer than it actually is.

When you’re following a tutorial, it feels like you understand what’s happening. Your code you write works, and everything makes sense in that moment. however, as soon as the tutorial is gone and you try to do something on your own, that understanding instantly disappears.

I didn’t realise this at first. i thought my confusion meant I needed to learn more, by watching more tutorials, reading more documentation and going through more courses. However, overtime, I began to notice that I wasn’t actually struggling because I didn’t know enough. I was struggling because I wasn’t actually thinking.

If I had to start again, I would’ve began to build things much, much earlier. I wouldn’t have started just because I ‘felt’ ready, or because I had ‘learned enough’. I would have started as soon as I had learned the basics, even if everything felt messy.

Because actually building something yourself forces you to think in a different kind of way. You aren’t just mindlessly following steps anymore, you are aking decisions. You are trying things, breaking things, fixing things, and beginning to realise why things work the way they do.

A lot of the time, you won’t fell productive. In fact, most of the time you will feel slow, confused, frustrated. But that is where the real learning happens.

Also, I would focus far less on syntax and more on structure.

When you begin to learn programming, it becomes easy to just think programming is about remembering how to write things, such as keywords, syntax and how you structure a function. It feels like that is what is needed to fully understand programming.

But, in reality, that syntax is the easiest part. You can just look it up.

What’s a lot harder, and also more important, is being able to understand how things connect. For example, how different parts of projects relate to one another, or how data moves through a system, or how changing one line of code will affect something somewhere else in the program. This is the part of programming that feels confusing or complicated, not because the code is impossible to read, but because the structure isn’t immediately visible.

If I had to start again, I would also stop trying to avoid feeling lost.

That feeling shows up right from the start, and it never really disappears, it just changes slightly as you progress. At the beginning, you feel lost because everything is new to you. As you improve, you feel just as lost because what you’re working on is so big, you can’t fully comprehend everything at once.

In both cases, the instinctive reaction is exactly the same: get out of that feeling as fast as you can, by searching frantically for another explanation, another tutorial, anything that makes it feel easy again.

But that moment when things aren’t automatically clear is usually the moment when your understanding is just about to shift. If you stay in that moment for long enough, something begins to click. Not instantly, but gradually.

I would also be a lot more intentional about what I build.

A lot of advice for beginners focuses on building projects, which I agree is good, but they often leave out something important. Not all projects teach you things in the same way, or even focus on the same skills. Building something just for the sake of building it often doesn’t make things stick.

The times where I learnt the most came from trying to solve something that actually frustrated me. Something that didn’t make sense, or that slowed me down, that I genuinely wanted to fix. When you care about the problem you are solving, you approach it differently. You become more patient, and go deeper, meaning you don’t just move on when something breaks, you try to understand why and fix it yourself.

This is the process that teaches you a lot more than following something that you know will end up working.

If I had to start again, I would also share what I was doing much earlier.

Not because I expected people to pay attention to what I was doing, but because it forces you to understand what you are doing properly. When you try to explain something to someone else, even in simple terms, you are able to realise what you do and don’t understand very quickly.

Sometimes you think something makes sense or you understand something until you try to put it into words, and that gap in knowledge shows you exactly where you need to focus. Over time, sharing will also bring in new perspectives. Other people are more likely to notice what you missed, or explain something in a way that makes it click faster. It also makes it feel less isolating and more collaborative.

Looking back, learning programming actually isn’t at all about learning programming.

It is about learning how to deal with confusion, how to continue trying even if things don’t quite make sense yet, and how to build something even if you aren’t sure if you are doing it ‘right’. If I had to start again, I wouldn’t try and learn absolutely everything.

I would just start. I’d pick something that feels frustrating enough to care about, and try to understand it just a fraction better each day. And that would be enough.

Thank you for reading! If you enjoyed my writing:

Subscribe for more articles like this

View my coding journey → My GitHub

Connect with Me → My LinkedIn My X (Twitter)

My Website → lucyb0207.github.io

ToxicAI: An AI That Emotionally Damages Developers 💀

Lucy — Fri, 03 Apr 2026 18:48:29 +0000

This is a submission for the DEV April Fools Challenge

What I Built

ToxicAI is an AI-powered code reviewer that doesn’t help you improve... it judges you.

When you paste your code, you will receive brutally honest roasts, developer metrics and a final verdict that feels slightly personal.

Instead of being useful, it evaluates your code like a disappointed senior developer who has lost patience with humanity.

You can choose a personality (brutal, passive, or overly supportive) and adjust the intensity from light teasing to full emotional damage.

The result is a completely useless but highly entertaining tool that turns bad code into entertainment.

Demo

toxic-ai-code-reviewer.vercel.app

Code

lucyb0207 / toxic-ai-code-reviewer

An AI-powered code reviewer that provides brutally honest and completely useless feedback.

💀 ToxicAI Code Reviewer

An AI-powered code reviewer that delivers brutally honest, emotionally damaging, and completely unnecessary feedback.

Built for the DEV April Fools Challenge.

What It Does

Paste your code → get instantly judged by an AI that behaves like a senior developer who has lost patience with humanity.

ToxicAI analyses your code and responds with:

a brutal roast
fake developer metrics
a dramatic final verdict

All completely useless. All completely intentional.

Features

AI Code Roasting (Gemini-powered)
Brutality Intensity Slider (Soft → Emotional Damage)
Personality Modes:
- Brutal
- Passive-Aggressive
- Overly Supportive (somehow worse)
Fake Developer Metrics:
- Vibe Score
- Ego Risk Level
- Stack Overflow Dependency
Dramatic Loading System (“AI is judging your life choices…”)
One-click Copy Roast
Structured Output:
- Roast
- Metrics
- Verdict Line

Tech Stack

React (Vite)
TypeScript
Gemini 2.5 Flash API

Why This Exists

This project solves absolutely nothing.

It exists purely to:

demonstrate AI integration
emotionally evaluate developers for…

View on GitHub

How I Built It

ToxicAI is built as a React app using Vite and TypeScript for fast development and performance.

The core AI functionality is powered by the Google Gemini 2.5 Flash API, which generates both the code roasts and structured fake developer metrics.

The app sends user-submitted code along with a dynamically generated prompt that changes based on:

Personality mode
Intensity level

The response is parsed and displayed in a formatted output panel, including:

AI-generated roast
Vibe Score
Ego Risk Level
Stack Overflow Dependency
Final Verdict

The focus of the build was on prompt engineering, response structuring, and creating a humorous AI interaction rather than traditional code analysis.

Prize Category

Best Google AI Usage:

This project makes direct use of the Google Gemini API to generate dynamic, personality-driven code roasts and developer metrics in real time.

It uses Gemini to act as a sarcastic code reviewer that adapts tone and intensity based off of user input.

The integration goes beyond simple text generation by:

dynamically adjusting prompts based on personality mode
controlling response tone via intensity scaling
structuring outputs into roast + metrics + verdict format

It showcases how generative AI can be used not just for utility, but for interactive, entertaining, and highly opinionated user experiences.

I built a Developer Tool at 16 (CodeAtlas)

Lucy — Thu, 02 Apr 2026 17:58:46 +0000

I built a developer tool at 16, and it didn’t start as anything impressive or serious. It started simply because I was frustrated - which I didn’t even realise at first, as I just assumed it was all just part of programming.

Every time I opened a new codebase, especially anything larger than a school project, it felt like I was reading something that was barely understandable for most humans. Files depended on other files, functions called things that were buried deep in completely different folders, and I would be constantly jumping between tabs trying to properly visualise how everything worked together.

It wasn’t that I couldn’t understand the code. It was that it took way to long to understand what should be a simple task, and i felt like I was rebuilding a mental image of what the codebase looked like every time I reopened a project. After a while, I began to wonder: there has to be a better way to do this.

That’s where I got the idea to build CodeAtlas. I didn’t consider it to be a startup or even a project that I could share with other people at the time. It was more like a challenge I had set for myself: what if I could find a way to visualise a codebase instead of just seeing files and folders?

At the start, I built the simplest version I could have possibly thought of. It was just a script that scanned a repository, checked the import statements and tried to draw lines between files. No fancy interface, or real structure behind it, I was just trying to see if the idea made sense outside of my brain.

The first time it actually worked, even though it was messy and broken, it flt weirdly different from what I had built before. It felt useful, like something people would actually want to use.

But this version was far from useful. It constantly broke, especially on anything that was even slightly complex. Bigger projects took an eternity to load and created chaotic webs where everything overlapped and it was impossible to tell what was going on.

Still, instead of starting over, I continued to improve it, bit by bit. I worked on improving the accuracy of detection, I added features like search bars and code viewers, and over time, it began to feel more and more like something that could actually help people understand real-world codebases.

The turning point wasn’t when I added a new feature, or I finally got something to work. It was when I showed my project to someone else for the first time. I expected them to comment on the visuals of the graph, or how interesting it looked, but instead, they came back to me and said this had helped them onboard new developers to their codebases.

That moment stuck with me more than anything else whilst creating this project.

This was when I realised I wasn’t simply drawing lines between files, but I was helping people reduce the complexity of repositories into something more abstract that people can actually understand and hold in their mind.

After this moment, I started thinking about CodeAtlas differently.Every change I made form then on wasn’t about making it more visually appealing, it was about making understanding faster. I started rebuilding parts that didn’t scale properly. I change how relationships were displayed.

And like most projects that begin to get real, i eventually ran into the part that nobody talks about enough: it is easy to continue improving a project forever, but it is much harder to actually finish it.

I always had an ongoing list of features that I could add, and improvements that would make it feel slightly more complete. But I stopped waiting for it to feel finished and I uploaded it to GitHub. It wasn’t perfect, and it still isn’t. But people could use it, load real repositories and actually get something useful out of it.

Looking back now, what I built hasn’t just been a developer tool for visualising dependencies. It has changed how I see code entirely: I don’t just see files anymore, I see relationships, structure, and how it all connects together under the surface.

And, weirdly, CodeAtlas wasn’t just something that helps me to build repositories better. It taught me how to see code from a different perspective.

Thanks for reading.

I’m curious... what’s the most confusing part of a codebase for you when you join a new project?

Drop it in the comments. I’ll read through them and it might shape what I build next.

Try CodeAtlas → GitHub
More writing → Substack
Follow the build → X (Twitter)

I Tried to Learn Coding Fast. It Almost Made Me Quit.

Lucy — Fri, 27 Mar 2026 21:46:11 +0000

For the longest time, I treated coding like a race I was already behind in. Every day, I’d fall into the same loop: searching for the fastest way to learn, the best roadmap, the most in-demand language. I convinced myself that if I could just find the perfect path, everything would click. So I jumped from Python to JavaScript, from web development to algorithms, from one course to another. Each new start felt exciting, like I’d finally cracked the system. But after a few days, the excitement faded, things got difficult, and I’d move on again — thinking the problem was the path, not my approach.

After a few months of this, I had nothing real to show for it. I wasn’t a complete beginner anymore, but I wasn’t competent either. I had fragments of knowledge — syntax here, concepts there — but no ability to actually build something on my own. That was the most frustrating part. I could follow along with tutorials and understand what was happening, but the moment I tried to create something from scratch, I’d freeze. It felt like staring at a blank page with no idea how to begin. That’s when the doubt started creeping in: maybe coding just wasn’t for me.

The turning point wasn’t dramatic. There was no breakthrough moment, no sudden surge of motivation. I just got tired of restarting. Instead of searching for another roadmap or switching languages again, I made one simple decision: I was going to build something small and actually finish it. Not something impressive, not something I could show off — just something complete. I picked a basic project, a simple to-do list app, and committed to working on it every day until it was done. That was the only rule.

At first, it was uncomfortable in a way tutorials never were. There was no step-by-step guide telling me what to do next. I had to figure things out on my own, and that meant getting stuck constantly. I’d spend 20 minutes trying to fix a single error. I’d search things I felt like I “should” already know. It was slow, messy, and honestly a bit discouraging. But something different was happening this time: I wasn’t quitting when it got hard. I was staying with the problem until I found a way through, even if that meant taking small, imperfect steps forward.

That’s when I realised why tutorials had been holding me back. They gave me the illusion of progress without forcing me to think deeply. When you follow a tutorial, you’re not really solving problems — you’re just replicating solutions. It feels productive because you’re typing code and seeing results, but you’re not building the mental frameworks needed to handle things on your own. When I started working on my own project, even something as simple as structuring the code or deciding where to start became a challenge. But those challenges were exactly what I needed.

To keep myself consistent, I made the process almost ridiculously manageable. I set a rule: I would code for at least 30 minutes every day, no matter what. It didn’t matter how tired I was, how busy the day had been, or whether I felt like it. The goal wasn’t to have perfect sessions or make huge progress — it was just to show up. Some days, I’d go far beyond 30 minutes because I got into the flow. Other days, I’d do the bare minimum and stop. But the key difference was that I never broke the chain.

Over time, the results started to compound in a way that felt almost invisible at first. I didn’t suddenly become an amazing developer, but things that used to confuse me started to make sense. Errors became less intimidating because I’d dealt with similar ones before. I stopped panicking when something didn’t work and started approaching problems more methodically. Most importantly, I began to trust myself — not because I knew everything, but because I knew I could figure things out if I gave myself enough time.

After a few months, I noticed a shift that’s hard to explain but easy to feel. I no longer saw myself as someone trying to learn coding. I was just someone who coded. That identity change made everything easier. I didn’t need to rely on motivation or wait for the perfect time to start. It became part of my routine, something I did without overthinking. And once that happened, progress stopped feeling forced and started feeling natural.

Looking back, the biggest mistake I made wasn’t choosing the wrong language or following the wrong roadmap — it was constantly restarting. Every time you restart, you reset the discomfort, the confusion, and the early-stage struggle. You never stay in one place long enough to push through it. Real progress comes from sitting with that discomfort and working through it, even when it feels slow and unproductive.

If you’re in that phase right now — jumping between tutorials, feeling stuck, wondering if you’re cut out for this — try simplifying everything. Pick one language. Pick one small project. Work on it every day, even if it’s just for 30 minutes. Don’t worry about doing it perfectly or efficiently. Just focus on finishing. Because finishing something, no matter how small, does more for your growth than consuming hours of content ever will.

Coding isn’t about finding the fastest path. It’s about staying on one path long enough for it to actually take you somewhere. And once you understand that, everything starts to change.

Building CodeAtlas: A Public Dev Journey (Hosting, Apps, and Scaling Challenges)

Lucy — Wed, 25 Mar 2026 14:48:59 +0000

I’ve been working on a project called CodeAtlas, something I’m building from scratch while learning, improving, and sharing the process publicly. The goal is simple: build useful software, ship it consistently, and document everything as I go.

Right now, I’m still early in the journey, but I’m at a point where I can build and iterate quickly. The main challenge isn’t coding anymore — it’s the resources needed to keep everything running smoothly.

Things like hosting costs, app deployment fees, certifications, and learning resources all add up. I also rely on certain tools that help me build faster and improve the quality of what I’m making. That’s the part that’s currently limiting how fast I can move.

CodeAtlas itself is a project focused on organising and visualising code and ideas in a more structured way. The idea is to make development feel more intuitive by linking concepts together, almost like building a “map” of a codebase or system. It’s still evolving, and I’m shaping it step by step as I build it.

I’m also building in public for a reason. I want to improve my skills, learn how real-world software is developed and shipped, and stay consistent with long-term projects. Every update, bug fix, and feature is part of that learning process.

If you want to support what I’m building, you can do so here:
👉 Buy Me A Coffee

Any support goes directly into hosting, app releases, certifications, and tools that help me keep building. Even small contributions genuinely make a difference and allow me to focus more time on development.

If you want to explore the project or follow development, here’s the GitHub repo:
👉 CodeAtlas

I’m actively updating it as I build, so feel free to star it or follow along.

I’d also really appreciate feedback. If you’re reading this, I’d love to know what you think — what would make a tool like CodeAtlas actually useful for you? What features would you want to see? I’m actively shaping the project based on input from people who are interested in it.

Thanks for taking the time to read this. I’ll be sharing more updates as I continue building — both the progress and the challenges along the way.