DEV Community: Timi

what are you working on? sounds familiar

Timi — Sun, 16 Aug 2026 22:12:18 +0000

Timi

Aug 16

What are you working on? #01

#devjournal #development #career #productivity

3 min read

What are you working on? #01

Timi — Sun, 16 Aug 2026 21:51:07 +0000

What are you working on?

I hear these words in my day-to-day.

And sometimes, when I hear them, there’s this little brain freeze that happens because my brain is probably trying to put into words the amount of things that have wandered through my head in the last 24 hours. 😂

So I thought, okay, let me try something.

I want to take some of those wandering thoughts, explorations, things I'm trying out and things I'm learning, and put them into writing.

This is going to be a series where I come and talk about what I'm working on — software engineering, product, work, people, faith, relationships, rest, and whatever else happens to be taking up space in my head at the moment.

So, what am I working on?

I recently started writing backend code, and there’s a bit of a backstory to that.

I built this frontend commerce store years ago where people can come and shop for furniture. At the time, I used a backend-as-a-service to handle the backend side of the application.

Now, I’m coming back to that same system and writing the backend myself with NestJS. I wanted to go beyond just consuming a backend and actually understand what is happening behind the scenes.

The learning process is a bit stretching at the moment because I’m getting familiar with a lot of new concepts. Tiring and frustrating? Yes. But the feeling when I finally understand the reason behind something is always refreshing. That has been really rewarding lately.

I'm also in the middle of launching a mobile application at my workplace, going through system design classes, figuring out how to get the best out of my engineers (AI sub-agents, by the way 😅), and occasionally imagining that dream job where you get to build products that serve millions of people and work with really brilliant minds.

Also, I discovered the productivity rush that comes with using large monitors. 😂

Then there's learning how to rest while also trying to close out all the open loops in my head.

Building reading habits.

Figuring out what to prioritize and, perhaps more importantly, what to drop.

Learning how to build healthier mindsets about life in general.

And sometimes, honestly, maybe all I'm working on is getting some rest or laughing about something ridiculous that happened during the week.

That's kind of the point.

I don't want this to be a series where I come here every week with a perfectly packaged lesson or pretend I've figured everything out.

I just want to document some of the things I'm thinking about and trying out as I go.

I also want to get better at something I've been thinking about for a while: when I see something I want to do, I want to find the closest point of execution instead of waiting for permission to move.

Sometimes we know what we want to do, but somehow convince ourselves that we need to go three levels up, get approval, find the perfect plan, or wait until we're completely ready.

Meanwhile, the closest point of execution might literally be the person sitting on the same floor as us.

Or, in this case, it might just be opening a blank page and starting to write.

So yeah.

Me starting this series is my point of execution.

Let's see how it goes over the next couple of weeks.

And I'd genuinely love to hear from you too.

What are you working on right now?

It could be software engineering or whatever field you're in. It could be something you're building. It could be something you're learning, something you're trying to figure out, something you're trying to let go of, or maybe just something funny that happened this week.

Drop it in the comments. Let's talk.

Also, yes, the last time I said I was writing something, it didn't ship. 😂 Long story.

But we're here now.

Let's try this.

Amen.

Good stuff

Timi — Sun, 09 Aug 2026 01:20:16 +0000

Shwetha

Aug 6

Fixing your site's metadata: a practical checklist

#webdev #seo #metadata

6 min read

Picked up backend last week, I think I like what I am seeing

Timi — Thu, 23 Jul 2026 13:58:18 +0000

Good read

Timi — Tue, 16 Jun 2026 15:26:01 +0000

Tawanda Nyahuye

Jun 16

Luck == Opportunity Meets Preparation

#productivity #career #learning #analytics

9 min read

Building with AI

Timi — Fri, 22 May 2026 21:31:35 +0000

Timi

May 22

Keep Your Taste

#ai #programming #learning

3 min read

Keep Your Taste

Timi — Fri, 22 May 2026 21:25:58 +0000

I know I said I was going to keep writing about concepts I use every day as a frontend engineer. Previously, I wrote about things like SPA routing, client-side vs server-side rendering, CDNs and all that good stuff. Life happened, a month went by, and honestly my workflow changed so much that it felt wrong to just jump back in without talking about it first.

Not that I stopped learning or building, far from it actually, but the way I approach features and fixes now is very different from what it used to be, mostly because of AI tools like Claude Code.

These days, I spend more time supervising code than actually typing every line myself.

At first, that feeling messed with me a little bit. It almost felt like I was cheating the process somehow. Like, if I’m no longer manually implementing every single thing, what exactly is my role now?

But after a lot of reflection, I’m starting to understand that engineering was never just about repetitive implementation. We were primarily created to think. To make decisions. To identify tradeoffs. To know why something should exist and what approach makes the most sense.

One thing AI does brilliantly though is helping ideas move from zero to one very quickly.

Previously, you could have an idea, think deeply about it, maybe even start building it, then life happens. Work happens. Priorities change. Maybe you just lack discipline (sarrry sarrry 😭) and the project just ends up in the dump of unfinished side projects.

I think a lot of engineers can relate to that.

I got an idea a few months ago that was very personal to me. I started actively taking notes during church services and events, but I noticed I rarely went back to read them. Sometimes the next time I opened a note was the next Sunday.

Discipline issue? Maybe. But I started thinking the real problem was visibility. It’s easy to forget things you never see again.

So I built something. A reminder based mobile app that resurfaces my notes intentionally throughout the week.

And building it was the first time I really felt what AI in a workflow actually means.

I had the idea, I knew the problem, AI helped me move fast on implementation. It gave me a solid template to work with. But decent wasn’t enough. My experience with UX meant I could look at what it gave me and immediately know what felt off. Certain flows weren’t natural. Some interactions didn’t match how users actually behave. So I made the adjustments, not because AI did a bad job, but because I already had a standard in my head.

That’s when I really started understanding taste.

And honestly the code AI produces is very decent my bro 😭

Decent enough that if you’re not careful, you stop thinking deeply about the decisions being made. Sometimes I catch myself just accepting changes quickly without really sitting down to understand if it’s actually the best approach.

But a colleague told me something recently that stuck. He said one thing AI will not take away from engineers is taste.

For me, taste is feeding your mind well enough to make sound judgments. Experiencing enough to know what good actually looks like. Because AI can generate templates but taste is what takes things from generic to actually good.

There has to be a standard in your head already, otherwise AI becomes the standard, and that guy can give some very generic stuff 😭

And honestly staying open minded is not a bad thing. It exposes you to a lot. The good stuff, the bad stuff, all of it. And that’s actually how taste gets built. You have to see what doesn’t work to know what does. So when AI puts something in front of you, you already know.

Thinking gives you something to drive towards. Leave your mind completely open and you will accept anything. That’s what taste protects you from.

So yeah, let’s keep building our taste, keep building things, and keep growing into better builders.

Till I come across something again… see you soon. Byeee 👋

It's a good day to learn more about CDNs

Timi — Mon, 23 Mar 2026 10:24:47 +0000

Timi

Mar 17

Understanding CDNs (Content Delivery Networks)

#performance #webdev #cdn #frontend

5 min read

How CDNs have improved how we get data from the internet

Timi — Thu, 19 Mar 2026 08:09:38 +0000

Timi

Mar 17

Understanding CDNs (Content Delivery Networks)

#performance #webdev #cdn #frontend

5 min read

Understanding CDNs

Timi — Tue, 17 Mar 2026 07:54:04 +0000

Timi

Mar 17

Understanding CDNs (Content Delivery Networks)

#performance #webdev #cdn #frontend

5 min read

Understanding CDNs (Content Delivery Networks)

Timi — Tue, 17 Mar 2026 07:53:40 +0000

I said I'd be writing about concepts I've frequently come across but never really stopped to properly understand. Today it's CDNs(Content Delivery Networks)

This one is interesting because it's not just something I've seen in everyday SPAs. I keep running it across tools and services I actually work with, and at some point I had to sit down and figure out what exactly is going on here.

So what is even a CDN?

At a high level, it's a system that makes sure your content gets to users faster, no matter where in the world they're requesting from.

Here's the version I had in my head before digging in:

It has something to do with caching. Data is being served from the edge of a network. Some technologies take advantage of CDNs to deliver their content faster

That's... not wrong. But it was pretty vague. Let me break it down properly.

The problem CDNs Solve

Let's say you deploy a web app and your server is sitting somewhere in the United States, Frankfurt, or wherever Vercel spins things up.

Now a user in Lagos, Nigeria opens your app.

Without a CDN, their request has to travel all the way from Lagos, across the Atlantic, to that server in the US, back across the Atlantic, back to Lagos. Every single time.

That round trip adds latency. And Latency is just the time it takes for data to travel from point A to point B and back again.

WITHOUT CDN

Now here's the part that really made me wonder, If it's all over the internet, why does distance matter?

It matters because the Internet is not magic. It runs on physical infrastructure: fiber optic cables, routers, submarine cables under the ocean, data centers. And even though signals travel as the speed of light through those cables, light still takes time to cross an ocean. Add in routers, the hops between networks, the processing at each stop and it all adds up.

Milliseconds, yes. But milliseconds matter when you're trying to build software that feels fast.

How a CDN fixes this

CDN providers have servers distributed all over the world, what are called edge servers. Instead of every request going back to your main server(the origin server),users get served from the closest edge server to them.

WITH CDN

Here's how it actually plays out. A user in Lagos, Nigeria requests your website. Instead of that request flying across the Atlantic, it hits an edge server somewhere nearby, If the provider has a presence in Lagos, It could be served right there. If not, the next closest option maybe somewhere else in West Africa. The point is it stays regional, not transatlantic.

If it's a cache hit, the content is already sitting on that edge server. It returns immediately. The origin server in the US doesn't even know the request happened.

If it's a cache miss, the edge server doesn't have it yet. It goes back to the origin, fetches the content, returns it to the user, and stores a copy so the next person requesting from that region gets it instantly.

That's the loop. Origin server holds the actual content. Edge servers hold cached copies and serve them to whoever is closest.

Worth noting here: What gets cached on edge servers is generic content, your HTML pages, images, JS bundles, stuff that looks the same for every user, User- Specific data like dashboards, auth states, or anything behind a login doesn't go through this path. That's a distinction CDNs and the developers configuring them are very deliberate about.

Each edge location serves the users closest to it. The origin only gets hit when and edge server needs to refresh its cache or sees content for the first time.

How this shows up in the tools we actually use

This is where it got relatable for me. CDNs aren't just a infrastructure concept. They are baked into services I use daily as a developer.

Cloudfare is probably the most obvious one. A huge part of what Cloudfare does is sit in front of your origin server and intercept requests. They have edge servers in cities all over the world, Lagos Included. When someone requests your site. Cloudfare serves cached content from the nearest location. Your origin doesn't really have to bother returning it.

Sanity is one I also noticed more recently. Sanity's main servers aren't in Nigeria, but when someone here requests content from sanity. It doesn't travel across the world. It comes from Sanity's CDN edge server, which is much closer. although sanity even does something interesting by exposing a flag know as useCDN:true/false, As an engineer I can either opt to fetch content straight from the origin or edge, Cool right?

Vercel and Netlify(popular host providers) have this built in too. When you deploy a static site or use edge functions, you're not really deploying to one server. You're deploying to their edge network. That's partly why deploys feels like magic; your content is already near you before the first request even lands.

As a developer, what does this actually mean for you?

Now that I have a better mental model of how this works, a few things I've run into as an engineer started clicking:

Cache invalidation is a real thing. When I update content, edge servers might still be serving the old cached version. Some platforms handle this automatically on deploy, others require explicitly purging the cache. I've pushed updates using a Content management system and wondered why users were still seeing the old version. Turns out the edge servers just hadn't caught up yet.

Another thing worth understanding is Cache-Control headers. The server can include instructions on how long content should be cached when it sends a response. For content that changes often, short cache times or none at all. For static assets like images, fonts, and JS bundles, cache aggressively. Getting this right means the CDN works with the app, not against it.

And not everything should be cached, this one is easy to miss. User-specific data, auth responses, anything that varies per person. None of that should be sitting on and edge server. CDNs shine brightest with static assets and content that looks the same regardless of who is asking for it.

Wrapping Up

CDNs exist because the internet, while fast, is still physical and distance adds latency. Instead of every user talking to one origin server far away, CDNs distribute copies of your content across edge servers worldwide so users get it from somewhere close to them.

You're almost certainly using a CDN if you're deploying on modern infrastructure. But understanding how it works helps you make smarter decisions about caching, about content structure, about why your users in one region are having a different experience than users somewhere else.

Let me know if you add have anything to add in the comments or any push back, would love to discuss it. And when I find something else I use every day but never really understood, I'll be back. Soon. Very soon. Byeeeeee

Nice read

Timi — Mon, 09 Mar 2026 17:29:50 +0000

Suraj Vishwakarma for Texavor

Mar 5

How to Optimize SEO with Next.js in 2026

#webdev #javascript #react #beginners

6 min read