DEV Community: Mari

Your AI Agent Has Amnesia. Here's the One That Doesn't.

Mari — Sun, 31 May 2026 11:26:57 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

Most AI agents forget everything the moment you close the tab. Hermes Agent is built to do the opposite, and that changes more than you'd think.

Let me start with something that drove me a little crazy when I first started using AI agents.
You spend an hour teaching one of your projects. Your file structure, your preferences, the way you like things done. It's great. It helps. Then you close it, come back the next day, and it's like talking to a stranger. You're explaining everything again from scratch. It's like training a new intern every single morning, except the intern never actually learns.
That's not a bug in one tool. That's how almost every AI agent works. They're stateless by design. Open a new session, start from zero. Whatever the agent figured out yesterday is gone.
So when I came across Hermes Agent, the thing that caught my attention wasn't "another AI agent." It was one specific claim: this one doesn't forget. And the more I dug into how it works, the more I realized that's actually the interesting part. Let me walk you through it.

First, what Hermes Agent actually is

Quick clarification, because the name confuses people. Hermes Agent is not an AI model. It's not something you download and run like a brain.
It's an agent framework. Think of it as the software that wraps around a model and gives it hands, memory, and a place to live. You bring the model (it works with pretty much anyone you want, ChatGPT, Claude, Gemini, open models, whatever), and Hermes handles the rest: the planning, the tools, the memory, the way it talks to you.
It was built by Nous Research, released in February 2026, and it's open source under the MIT license. That means you can read every line of the code, change it, and run it yourself. It lives on your own server — could be a cheap five-dollar VPS (virtual private server), could be your laptop, and all your data stays on your machine. No tracking, no cloud lock-in.
So far, normal. Lots of agents do the planning-and-tools thing. Here's where it gets different.

The thing that makes it different: it remembers

Hermes has persistent memory. Not "I remembered the last few messages" memory. Real across-sessions memory. It remembers your projects, your preferences, and your environment, and it keeps that knowledge even after you restart it. The longer it runs, the better it knows you. You stop re-explaining yourself.
Behind the scenes, it's not magic. It stores what happens locally and uses search plus summarization to pull the right context back when it needs it. But the effect is what matters: it builds up a picture of who you are and what you're working on, and that picture sticks.
If you've ever felt the friction of repeating yourself to an AI, you already understand why this is a big deal.
The part I find genuinely clever: it teaches itself
This is the bit I want you to remember if you forget everything else.
When Hermes solves a hard problem, something non-trivial that actually took some figuring out, it writes down how it did it. It creates what's called a skill. A skill is basically a little instruction document that says, "When a situation looks like this, here's the approach that works."
So the next time it hits a similar problem, it doesn't start from scratch. It already has the playbook it wrote for itself.
Think about what that means. Most agents are smart in the moment but forgetful forever. Hermes accumulates. It gets a library of its own hard-won lessons, and that library grows every time it works.
And here's the part that takes it from "neat" to "actually important": those skills aren't locked inside your copy. They're saved in a portable, shareable format that follows an open standard. So one person's agent can learn something, write it down, and another person's agent can install that skill.
Sit with that for a second. It's basically Stack Overflow, except the answers are written by agents, for agents. Individual experience turning into shared knowledge. That's not a small idea.

What it can actually do day to day

To make this concrete, here's the kind of stuff Hermes handles out of the box:

It can run code, search the web, control a browser, click around, and take screenshots.
It can reach you on Telegram, Discord, Slack, WhatsApp, Signal, or just your terminal, all from one place. Start a conversation on your phone, finish it on your laptop.
It can run scheduled jobs. Daily reports, nightly backups, a morning briefing, all running while you're asleep.
It can spin up smaller helper agents to handle separate tasks at the same time.

The picture they're painting is an agent that isn't tied to your laptop sitting open. It's something that lives on a server, works in the background, and pings you wherever you are.

*So why does the "memory" thing matter so much?
*
Here's my honest take after looking into all of this.
For the last couple of years, the whole AI conversation has been about intelligence. Which model is smartest? Who scored higher on which benchmark? And that matters, sure.
But intelligence that resets to zero every session has a ceiling. No matter how smart your agent is on Monday, if it's a blank slate again on Tuesday, you're capped. You're always paying the "re-explain everything" tax.
What Hermes is betting on is a different axis entirely: not how smart the agent is in one moment, but how much it compounds over time. An agent that remembers and writes down what it learns doesn't just stay useful. It gets more useful the longer you use it. That's a fundamentally different shape than what most of us are used to.
I don't know if Hermes specifically wins. The space moves fast, and there are other strong frameworks. But the idea it's built on, agents that accumulate instead of reset, feels like one of those things that's obvious in hindsight. Once you've felt the friction of an agent with amnesia, you don't really want to go back.
If you want to try it
You don't need much. It runs on Linux, macOS, or WSL2 on Windows, and it installs with a single command, no big setup, no prerequisites. There's a free CLI to start chatting right away, and an optional step to connect it to your messaging apps if you want it reachable from your phone.
It's free, it's open source, and you can run it on a cheap server. If the "agent with memory" idea grabs you the way it grabbed me, it's worth a weekend.

start here:
https://hermes-agent.nousresearch.com/

One day since I wrote this article and I keep remembering how difficult and poor local LLMs were but now it’s a different story. Google Deepmind and other open weight models are changing the story. Read more…..

Mari — Thu, 21 May 2026 17:48:44 +0000

Gemma 4 Challenge: Write about Gemma 4 Submission

Mari

May 17

I Ran Google's Gemma 4 on a 10-Year-Old Laptop With No GPU. Here Is What I Found.

#devchallenge #gemmachallenge #gemma

Comments 1

8 min read

Local Models are getting so good these days. Imagine having an AI agent on your local machine. No API keys. No Subscription. No Rate Limits. I installed Gemma 4 E2B on a 10-year-old laptop. Read to find out my experience.

Mari — Mon, 18 May 2026 12:20:30 +0000

Gemma 4 Challenge: Write about Gemma 4 Submission

Mari

May 17

I Ran Google's Gemma 4 on a 10-Year-Old Laptop With No GPU. Here Is What I Found.

#devchallenge #gemmachallenge #gemma

Comments 1

8 min read

I Ran Google's Gemma 4 on a 10-Year-Old Laptop With No GPU. Here Is What I Found.

Mari — Sun, 17 May 2026 13:54:53 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

I knew local LLMs existed, but I never knew they were capable of doing high computational work. A few days ago, I installed Google's Gemma 4 E2B on a 10-year-old HP EliteBook, Intel i7 from 2016, 16 GB of RAM, no GPU, just integrated graphics.
I honestly didn't know what to expect. I was totally blown away. I thought it was going to be very slow, but it wasn't. I also thought it was going to give me generic responses, but I was completely wrong.
This is what I found.

The Setup

Google's Gemma 4 was released in April 2026. For those that aren't aware of it, Gemma 4 is a family of open-weight models (open-weight simply means anyone can download the model and run it themselves, no internet needed once it's installed). It has four models: the E2B and E4B (designed mainly for phones and laptops with low computational power), and the 26B and 31B (for high-end systems and GPUs). I used E2B because that's what my system could handle, a 7.2 GB model file.
This runs on Ollama, a tool for running AI models on a computer.
My setup: Ubuntu 24.04, Ollama 0.23.3, Gemma 4 E2B.

The Install

Before I show you what Gemma 4 can do, I should be honest about what it took to get it running. It was not quick.
I started with the standard Ollama install command. The download got to 98.9% and then died with a protocol error. My connection is not the most stable,and the install script could not handle the dropouts. I saw a lot of "Could not resolve host: github.com" messages along the way.
The fix was to download the install script separately first, with retries built in:

curl -L --retry 5 --retry-delay 3 -o install.sh https://ollama.com/install.sh
sh install.sh

The --retry flag tells curl to keep trying when the connection drops. That part worked. Ollama was installed eventually, after about two hours of patience.
Then I pulled the model:

ollama pull gemma4:e2b

That was another two hours for 7.2 GB. Total time from clicking the first command to my first real conversation with Gemma: about four hours.
Here is the part that makes the four hours worth it. After this, no internet is ever needed again. The model lives on my disk. No API key, no subscription, no monthly bill. Pay the install cost once, use it forever.

The First Conversations

I started with a simple question: how does Gemma verify information?
The answer surprised me. Gemma did not pretend to be a search engine or a fact-checker. It admitted plainly that it does not verify anything. It explained that it is a pattern-matching engine that predicts likely sequences of words based on its training data, and it used the word "hallucination" to describe its main limitation.
In its own words:

I am an extremely sophisticated pattern-matching engine. I generate information based on the knowledge I absorbed during training, not by verifying facts against an external database. Therefore, it is crucial to treat my output as a starting point or a resource, and always verify critical information using reliable, external sources.

That kind of honesty from a small local model was not what I expected.
One thing I noticed quickly: Gemma's default style is very structured. Lots of headers, lots of bullet points, lots of bold. For some tasks, this is great. For casual conversation, it feels like the model is filing a report. Worth knowing if you plan to use it.

Code, the Real Test

This is the part that mattered to me as a developer. I asked Gemma to write a Python function that takes a list of integers and returns the second-largest unique value, handling edge cases.
The response was better than I expected. Gemma first showed its reasoning, working through edge cases before writing a single line of code: empty list, duplicates, negatives, and all elements the same. Then it produced this:

`from typing import List, Optional

def find_second_largest_unique(numbers: List[int]) -> Optional[int]:
"""
Finds the second largest unique value in a list of integers.
"""
if not numbers:
return None
unique_numbers = set(numbers)
sorted_unique = sorted(list(unique_numbers), reverse=True)
if len(sorted_unique) < 2:
return None
return sorted_unique[1]`

Proper type hints. A real docstring. Comments explaining the choices. After the function, it added six test cases covering every edge case I would have written, and finished with a complexity analysis: O(N log N) time, O(N) space.
I would accept this in a code review. From a developer working under me, this is solid junior-to-mid-level work. From a 7.2 GB file running on a 2016 laptop with no GPU, it is something else.
The timing on this response: about 5 to 15 seconds before the first word appeared, then 30 to 60 seconds for the full response, including the thinking trace, the code, the tests, and the complexity analysis. Fast enough to read along as it is typed. I never sat there waiting.

The Long Context Test

Gemma 4 advertises a 128K token context window, which is roughly enough to hold a short novel. I wanted to see how that holds up on real hardware.
I downloaded "The Yellow Wallpaper" by Charlotte Perkins Gilman from Project Gutenberg, about 9,000 words, and asked Gemma to summarize it in three sentences.
The first attempt took 10 minutes, and the summary it gave me was not about the story. It was about copyright and Project Gutenberg's terms of use. The boilerplate header at the top of the file had taken over.
I stripped out the license text and tried again with just the story, about 6,000 words. This time it took 5 minutes, and the summary was real:

The narrator, confined by oppressive circumstances, engages in a desperate act of rebellion by tearing down or removing a portion of the wallpaper, which reveals a hidden reality. This act leads to a further exploration of the narrator's confinement, paranoia, and a climactic confrontation with the perceived prison. Ultimately, the story ends with the narrator's escape, emphasizing a violent break from her oppressive environment."

A literature student would accept this.
So the long context works. But two things matter. First, on CPU-only hardware, every thousand words of input has a real-time cost. Second, what you put in matters as much as how much you put in. Feed it boilerplate, and you get a summary of boilerplate.

Where It Broke: The Multilingual Claim

The Gemma 4 documentation says the model supports more than 140 languages. I speak Nigerian Pidgin and Igbo, so I tested both.
I asked Gemma to translate this sentence into Nigerian Pidgin: "I'm going to the market to buy some food because there's nothing in the house."
Gemma's best option:

I go market to buy food because there na nothing for the house.

How a Nigerian actually says it:

I wan go market go buy food, notin dey house.

The difference is not small. Gemma used real Pidgin words but glued them together with English grammar. It kept "to buy" instead of the Pidgin serial verb "go buy." It used "because" as a connector when Pidgin would just lean on the comma. The result is recognizable to a Pidgin speaker, but it is not how anyone actually talks.
Igbo was worse. I asked for the same sentence in Igbo, and Gemma gave me this:

A na-ekwu n'ịde maka ịzụ ụfọdụ n'aka n'ụlọ, ka ọ bụla nọ n'ụlọ.

The correct version:

Anam aga ahịa igote nri maka na onweghị ihe dị na ụlọ.

The Gemma version is not just unnatural. It uses words that do not mean what the model thought they meant. In its own thinking trace, Gemma defined "ahụ" as "I," when it actually means "body." It defined "nwere" as "to buy," when it really means "to have." The model was confidently making up definitions and then using them to translate.

Supports 140 languages" is doing a lot of work in that marketing line. For low-resource African languages, my honest finding is that the model does not just struggle. It fabricates.

Where It Worked: The Image Test

To balance the multilingual finding, I tried something Gemma 4 is supposed to be strong at: looking at images.
I downloaded a photo of a mountain landscape at golden hour, with peaks rising above a sea of clouds. I asked Gemma to describe what she saw.
The processing took about 8 minutes, which is slow but expected on a CPU. The description was not slow:

This is a breathtaking, panoramic photograph that captures a dramatic mountain landscape seen from a high vantage point, likely during sunrise or sunset. The image is defined by a striking contrast between the dark, rugged foreground and a vast, ethereal sea of clouds below.

It went on to describe the three layers of the composition, the snow on the peaks, the warm tones on the high mountains versus the cool blues higher in the sky, and the dark scrubby terrain in the foreground. All of it was accurate. A blind person reading that description could form a real picture of the actual photo.
So the multimodal feature works, and it works well. It is just slow on a laptop like mine.

The Honest Moment

One thing I want to admit before I wrap up. While I was running the math test, I gave Gemma a word problem about trains traveling between two cities.

The answer came back referencing the cities I had typed. I looked at the output and at first thought Gemma had swapped my cities for American ones. I was about to write a section about training data bias.
Then I looked at my own prompt. I had typed the American cities myself and forgotten. Gemma was just using what I gave her.
The reason I am including this: when something seems wrong with AI, it is worth checking your own input first. A lot of "AI is bad at X" takes are quietly user error.

What This Means

Eight years ago, running a useful language model on a laptop without a GPU was a fantasy. Two years ago, it was possible, but the output was bad enough that you would only do it as a hobby. Now I am running a 7.2 GB file on a 2016 business laptop, and it is writing code I would accept from a junior engineer, summarizing 6,000-word documents, and describing photographs with the eye of a writer.
It is not perfect. The long context is slow on the CPU. The multilingual support breaks for low-resource languages. The image processing takes minutes, not seconds. But "not perfect" is a different conversation from "not useful."
The gap between cloud AI and what runs on ordinary hardware has closed faster than I realized. For a developer without an API budget, without reliable internet, or without a workstation, that gap-closing is not just a technical detail. It is the difference between using these tools and not.

And because Gemma 4 is released under the Apache 2.0 license, anything I build with it is mine to ship. No usage fees, no rate limits, no terms of service that change next year.

How to Try It Yourself

If you have a laptop with at least 8 GB of RAM and a few hours of patience, you can try this today. Three commands:

curl -fsSL https://ollama.com/install.sh | sh ollama pull gemma4:e2b ollama run gemma4:e2b

The first installs Ollama. The second pulls the model. The third starts a chat.
If your connection is flaky like mine, swap the first command for the retry-friendly version I used:

curl -L --retry 5 --retry-delay 3 -o install.sh https://ollama.com/install.sh sh install.sh

Then ask it something hard. See what surprises you.

If you try it, I'd love to hear what you build with it. Drop a comment with what worked, what didn't, or what surprised you. The local AI conversation is just getting started.
Then ask it something hard. See what surprises you.

A Simple Guide to Cookies in Modern Web Development

Mari — Wed, 14 Jan 2026 05:22:37 +0000

If you have ever logged into a website and found that you were still logged in the next day, you have used a cookie. But what is it actually?

As we move through 2026, the way we store data on a user's computer has changed. Whether you are building your first website or your fifty-eighth, here is a guide to how cookies work today and why they still matter.

What exactly is a Cookie?
Think of a cookie as a digital luggage tag. Imagine you go to a hotel to drop off your bags:

The Drop-off: You give your bags to the clerk.

The Ticket: The clerk gives you a small numbered ticket.

The Return: Later, you come back. You do not have to explain who you are. You just show the ticket.

The Match: The clerk looks at the number and gives you your bags.

In this story, the ticket is the cookie. It is a tiny piece of text that the website gives your browser so it can remember who you are later.

How the Process Works (Step-by-Step)
To understand cookies, you have to see the back-and-forth conversation between your computer and the website.

The Request: You type website.com and hit enter. Your browser asks the website for the page.

The Response: The website sends the page data. Along with that data, it sends a note that says: Set-Cookie: ID=123.

The Storage: Your browser sees that note and saves the ID 123 in a small file on your computer.

The Next Visit: The next time you click a link on that site, your browser automatically attaches a note to your request: Cookie: ID=123.

The Recognition: The website sees the ID, looks it up in its database, and says, "Welcome back, User 123!"

Cookies vs. LocalStorage
Developers often get confused about which one to use. Here is the simple breakdown:

Cookies: These are tiny. Their main job is to be sent back and forth between the browser and the website server. They are designed for security and identifying who you are.

LocalStorage: This is much larger. It stays on your browser and is never sent to the website automatically. It is designed for saving settings like "Dark Mode" or a draft of a message.

The Rule: Use cookies for anything sensitive (like a login). Use LocalStorage for things that are not secret.

The Modern Security Rules
In the past, cookies were simple. Today, they have "bodyguards" called attributes. If you do not use these, your website is at risk.

HttpOnly (The Invisible Shield)
When you mark a cookie as HttpOnly, it means the website's own code cannot see or touch the cookie. Only the browser can send it to the server. This prevents hackers from stealing your login information using malicious scripts.
Secure (The Enforced Lock)
The Secure attribute tells the browser to only send the cookie if the connection is encrypted (HTTPS). This prevents people from "eavesdropping" on your data when you use public Wi-Fi.
SameSite (The Border Control)
This attribute tells the browser whether to send the cookie when you click a link from a different website. Setting this to Lax is the modern standard. It prevents other websites from tricking your browser into performing actions you did not intend.

Common Mistakes and How to Fix Them
The Localhost Problem
Many developers turn on the Secure flag and then wonder why their login stopped working on their personal computer. Since your local computer usually does not use an encrypted connection, the browser blocks the cookie. You should only turn on the Secure flag when your website is live on the internet.

The 400-Day Limit
Browsers now have a strict limit on how long a cookie can live. Even if you tell a cookie to last for 10 years, the browser will delete it after about 13 months (400 days). To keep a user logged in longer, you must give them a fresh cookie every time they visit.

The Missing Connection
If you use code to talk to your server, you might notice the cookies are missing. You must tell your code to "include credentials" in your settings. Otherwise, the browser thinks you want to keep your cookies private and will not send them.

Summary: Your 2026 Strategy
To keep your users safe, follow this simple plan:

For Login Sessions: Use a Cookie. Turn on the HttpOnly, Secure, and SameSite settings.

For UI Preferences: Use LocalStorage. It is faster and does not send extra data to the server every time you click a button.

By following these steps, you protect your users while keeping your website fast and easy to use.

The Intersection of web2 backend and web3

Mari — Thu, 18 Dec 2025 21:16:45 +0000

The Intersection of Web2 Backends and Web3

Web3 is often described as a complete replacement for Web2. In practice, that idea breaks down very quickly once real products, real users, and real scale are involved. Most successful Web3 applications today are not purely decentralized systems. They are hybrids, combining traditional Web2 backends with blockchain-based infrastructure.

Understanding this intersection is critical for backend developers who want to move into Web3 without abandoning everything they already know.

This article explores what actually happens at the boundary between Web2 and Web3, why it exists, and how backend engineers fit into the picture.

Why Web2 does not disappear in Web3

Blockchains are excellent at a few specific things. They provide trust minimization, censorship resistance, a transparent state, and permissionless execution. They are not good at fast queries, private data storage, complex computations, or frequent logic changes.

Web2 backends solve those exact problems.

That is why Web3 systems still rely heavily on traditional servers, databases, APIs, and background workers. The goal is not to replace Web2, but to reduce how much trust users must place in it.

In most production systems, Web2 handles speed and usability, while Web3 handles ownership and trust.

What stays Web2

In a typical Web3 application, the following components almost always remain off-chain:

User profiles and preferences
Authentication layers beyond wallet ownership
Complex business logic
Analytics and reporting
Search and filtering
Caching and performance optimization
Notifications, emails, and messaging
Admin and moderation tools

Blockchains are slow, expensive, and public by design. Anything that requires privacy, flexibility, or scale belongs in a traditional backend.

What becomes Web3 aware

At the intersection, the backend begins to understand blockchain concepts and treat them as first-class data sources.

Instead of usernames or emails as primary identifiers, the backend works with wallet addresses.
Instead of database rows as the source of truth, it verifies on the on-chain state.
Instead of internal events, it reacts to smart contract events.

The backend does not own a critical state anymore. It mirrors, indexes, and responds to it.

A common hybrid architecture

A very common Web2 plus Web3 flow looks like this:

A user connects a wallet on the frontend
The user signs a message
The backend verifies the signature
The backend creates a session or token
The backend listens for blockchain events
The backend updates its database accordingly

This approach allows applications to remain fast and user-friendly, while still relying on cryptographic proof of ownership.

The backend developer’s role in Web3

Despite popular narratives, Web3 companies hire a large number of backend engineers. The responsibilities simply expand.

Backend developers in Web3 often:

Verify wallet signatures
Index blockchain data into databases
Listen to smart contract events
Trigger off-chain workflows
Aggregate data across multiple chains
Expose REST or GraphQL APIs
Prevent abuse and automate moderation
Integrate with external services

In many startups, the majority of the codebase is still Web2.

Smart contracts versus backend logic

One of the most important design decisions in hybrid systems is deciding what lives on chain and what stays off chain.

Smart contracts should be minimal, deterministic, and security-critical. They define ownership, value transfer, and irreversible actions.

Backends should handle logic that changes frequently, requires heavy computation, or depends on private data.

Pushing too much logic on the chain leads to high costs and inflexibility. Pushing too much logic off-chain weakens trust guarantees. The intersection exists to balance both.

Tools commonly used at the intersection

On the Web2 side:

Traditional backend frameworks
Relational databases
Caching layers
Message queues
REST and GraphQL APIs

On the Web3 side:

Blockchain RPC providers
Wallet signature verification libraries
Smart contract event listeners
Indexing services

The backend acts as the glue that connects these worlds.

Real-world examples

DeFi platforms store funds and rules on-chain, while backends track positions, history, and risk metrics.

NFT platforms keep ownership on chain, while metadata, search, and discovery live off-chain.

DAO tooling runs voting on chain, but analytics, dashboards, and permissions are handled by backends.

Very few production systems are fully decentralized end-to-end.

Why this intersection matters

Pure Web3 systems struggle with usability and scale.
Pure Web2 systems struggle with trust and transparency.

Hybrid systems combine the strengths of both.

For backend developers, this intersection is an opportunity rather than a threat. Existing skills in APIs, databases, security, and system design are not obsolete. They are essential.

Learning how blockchains work allows you to build systems that are fast, trustworthy, and practical.

The future of Web3 is not about abandoning Web2. It is about integrating it intelligently.

Why Every Generation Has a Different Relationship With Technology

Mari — Fri, 12 Dec 2025 07:37:45 +0000

Every generation carries a different story about the world. A different memory. A different way of surviving and understanding life. That is why no two generations approach technology the same way. Technology did not meet us equally. It did not arrive at the same stage of our lives. It did not shape our beliefs in the same way.

For some, technology was a shock. For others, it was a miracle. And for those growing up today, technology is simply the world they were born into.

The Generation That Watched the World Transform

Older generations lived through a time when technology was not everywhere. Phones had limits. Information requires effort. Connection requires presence. To them, technology is still something to be managed and approached with caution. They had to adjust to it. They had to learn it. They had to trust it slowly.

This relationship is built on distance. They remember what life looked like before everything became fast. Before everything became digital. Before everything became automated. Their memories give them a different kind of balance.

The Generation That Grew Up in Transition

Then there is the generation that grew up in the middle. They saw the world shift from analog to digital right in front of their eyes. They watched phones evolve. They watched the internet spread. They watched opportunities multiply. To them, technology is both familiar and new. Both exciting and overwhelming. Both empowering and distracting.

They understand life before and after the revolution. They understand the silence before everything became loud. They understand the simplicity before everything became optimized. Their relationship with technology is a blend of curiosity and caution because they have lived on both sides.

The Generation Born Into the Digital World

For today’s younger generation, technology is not an invention. It is a foundation. It is the first language they learn before they even understand their own thoughts deeply. They navigate screens before they know how to write fully. They find answers online before asking questions offline.

Their relationship with technology is natural. It is not a tool. It is a lifestyle. It shapes their identity, their friendships, their worldview, and their expectations. It becomes the lens through which they see the world.

Why These Differences Matter

Different relationships with technology create different beliefs. Different fears. Different values. Different strengths.

One generation values privacy because they lived without the internet. Another generation values speed because they witnessed the rise of efficiency. The youngest values access because they have never seen a world without it.

This is not a conflict. It is a spectrum. Each generation brings something the others do not have. Wisdom. Adaptability. Curiosity. New vision.

When these perspectives come together, technology becomes more human. More grounded. More meaningful.

Technology Is Not Just Devices. It Is Culture.

In the end, the story of technology is the story of people. How we adapt. How we learn. How we evolve. Technology shapes our behavior, our communication, our careers, our relationships, and even our definition of community. But each generation interprets these changes through its own history.

This is why we misunderstand each other sometimes. This is why our expectations differ. This is why our comfort levels are not the same. But instead of seeing these differences as a division, we should see them as an advantage.

Technology grows best when many perspectives shape it. When the people who remember life before the internet meet the people who cannot imagine a world without it. When experience meets innovation. When memory meets possibility.

Every generation brings something essential to the digital world. And that is what keeps technology human.

The Silent Pressure of Staying Relevant in Tech

Mari — Mon, 01 Dec 2025 12:59:50 +0000

There is a kind of pressure in tech that nobody really talks about. It is not the pressure of deadlines or difficult tasks. It is the quiet fear that if you stop learning for a moment, the industry will leave you behind.

Every week, there is a new framework. Every month, there is a new tool. Every year, there is a new trend that everyone claims will “change everything”. And in the middle of all of that noise is you, trying to learn, build, grow and still breathe.

The Pace Is Exhausting

People outside tech sometimes believe developers enjoy every update. They think we spend all day exploring new tools for fun. But the truth is simpler. Most of us just want to be good at our work. We want to build things that matter. Yet the landscape moves so fast that even when you are doing your best, you can still feel behind.

You learn a framework today, and by the time you finally understand it, another one is already taking over the conversation. You master a tool only to hear that there is a “better” one you should be using. You start a course, and midway through it, a new update makes half of the syllabus feel old.

The pressure is not loud. It is quiet. It sits at the back of your mind. It pushes you when you are tired. And sometimes, it whispers the thought nobody wants to admit: “Maybe I am not keeping up.”

The Emotional Weight That Follows

This pressure shows up in small ways.

You feel guilty when you take a break.
You feel insecure when you see people posting new projects on social media.
You feel anxious when you realise you have not learned something “important” yet.
You feel overwhelmed when your to-learn list grows longer than your to-do list.

And even though everyone around you seems to be moving forward, you feel like you are running just to remain in the same place.

Why It Happens

Tech is built on speed. Companies build fast. Tools evolve fast. People share fast. That speed can create a culture where slowing down feels like failure. But the truth is this: nobody can learn everything. Nobody can keep up with every update. Nobody can master every tool.

The industry moves fast, but humans do not. And that is fine.

How to Navigate Without Losing Yourself

What helps is not trying to learn everything. What helps is learning with intention.

Keep your focus small.
Pick one path and grow there.
Choose depth over hype.
Let your learning be guided by what you want to build, not by what the internet is shouting about.

You will always see new tools. You will always see new trends. But you do not need to chase all of them. You only need to understand the ones that move you forward.

And remember to rest. You are not falling behind when you breathe. You are not losing your place when you pause. You are simply giving yourself space to grow more healthily.

A Simple Truth

Tech might move quickly, but your career is long. The goal is not to catch everything. The goal is to remain grounded, consistent and intentional.

You do not need to learn like the internet is on fire. You only need to learn at a pace that keeps you human.

The AI-Human Collaboration Every Developer Needs to Understand

Mari — Mon, 24 Nov 2025 13:35:58 +0000

Artificial Intelligence isn’t here to replace developers, at least, not yet.

The real question isn’t “Will AI take my job?” It’s “How can I collaborate with AI to become a better developer?”

AI is already changing how we write code, debug, and solve problems. But to truly benefit from it, we need to rethink workflow, decision-making, and trust. AI isn’t just a tool—it’s a partner, and the way we collaborate with it will define the next era of software development.

AI as a Productivity Partner, Not a Replacement

AI shines at automating repetitive tasks. It can generate boilerplate code, suggest test cases, or even draft documentation. These small efficiencies can save hours each week.

But automation is not intelligence. Humans still decide:

Which problems to solve

Which solutions fit the context

How to weigh trade-offs

When a system is “good enough”

In practice, AI accelerates development, but humans guide it. It’s a partnership.

Example:
Imagine building a booking API. An AI tool might generate serializers, validators, or endpoint templates. But only you can determine whether the design aligns with your architecture or business logic. AI provides options—you decide the direction.

Rethinking Workflow With AI

Collaboration with AI requires a shift in how we approach tasks:

Idea First, Code Later
AI works best when it understands context. Define the problem clearly before asking it to generate code.

Iterative Feedback Loops
Treat AI like a junior developer: generate a solution, review it, refine it, and repeat.

Focus on Higher-Level Thinking
With AI handling repetitive work, humans can concentrate on system design, scalability, and maintainability—areas AI struggles with.

Trust But Verify
AI outputs are not flawless. They can hallucinate, make assumptions, or introduce insecure patterns. Verification and testing remain human responsibilities.

Decision-Making in an AI-Augmented World

AI doesn’t replace judgment—it shifts it.

Trade-offs: AI may suggest the fastest solution, but not the most maintainable.

Ethics: AI can inadvertently introduce bias or insecure practices. Developers must evaluate consequences.

Creativity: AI generates ideas, but humans determine which solutions are novel or valuable.

Collaboration is about amplifying human intelligence, not surrendering it.

Building Trust With AI

Effective AI-human collaboration depends on trust:

Understand AI’s limitations

Be consistent in prompts and review processes

Treat AI as a partner, not an executor

Maintain accountability—humans are ultimately responsible for the code

The stronger your trust framework, the more productive and safe your collaboration becomes.

The Future Isn’t AI vs Human—It’s AI + Human

Developers who embrace AI as a collaborator will:

Work faster

Produce cleaner, more maintainable systems

Focus on high-value decisions instead of repetitive tasks

Those who fear AI may waste time fighting automation or doing work that machines could handle. The reality is simple: AI augments, it doesn’t replace.

The real skill is learning how to collaborate with AI while preserving human judgment, creativity, and responsibility.

Key Takeaways

Stop asking whether AI will replace you. Start asking:

How can AI help me make better decisions?

How can AI reduce friction in my workflow?

Where do I need to remain vigilant and human?

AI-human collaboration isn’t a future concept—it’s already here. Developers who understand it will define the next generation of software development.

How to avoid procrastination as a developer

Mari — Mon, 17 Nov 2025 13:46:47 +0000

Procrastination is one of those things nobody warns you about when you start learning how to code. People talk about choosing a programming language, understanding algorithms and building projects, but nobody talks about the days when you simply do not have the strength to start.

I have learned that procrastination is not just a habit. It is a feeling. It is that quiet heaviness that sits in your chest when you know what to do but you cannot bring yourself to do it. And the most painful part is that only you can stop it.

As developers, we enter every new year with goals. You tell yourself that you will finish this course. You will build that project. You will improve a skill. You will finally be consistent. But somewhere along the line, something shifts.

You start feeling stuck.
You start feeling behind.
You start feeling like you are not good enough.
And slowly procrastination becomes a comfortable hiding place.

You say things like
I will code later
I will continue that course later
I will fix that error later

In reality, nothing is wrong with you. You are simply overwhelmed. And overwhelm is the fastest way procrastination grows.

So how do you break out of it as a developer?

The first step is clarity. Most developers do not procrastinate because the work is hard. They procrastinate because they do not know the next small step to take. When your task is too big, your mind rejects it. But when the first step is clear, your mind begins to move.

The second step is simplicity. Stop trying to learn ten things at once. Pick one skill and stay with it until you can explain it without thinking twice. When your learning path is simple, your consistency increases.

The third step is momentum. Not motivation. Motivation comes and goes. But momentum grows when you show up even when you do not feel like it. Write a small function. Debug one line. Read one chapter. The goal is to move, even if the movement is small.

The fourth step is honesty. Be honest with yourself about why you are delaying. Are you scared? Are you confused? Are you exhausted? Once you know the real reason you are avoiding the work, solving it becomes easier.

The fifth step is environment. Your environment controls your discipline. A noisy workspace produces a noisy mind. Clean your space. Close unnecessary tabs. Give your brain room to think.

Being a developer means dealing with uncertainty. You will always have one bug you do not understand and one new concept you are still trying to wrap your head around. That is normal. That is the job. But you cannot let that uncertainty turn into procrastination.

Consistency is not built on big wins. It is built on small steady steps that accumulate with time. You do not have to be perfect. You just have to start again.

How I organize my VS Code for Maximum Productivity

Mari — Mon, 10 Nov 2025 11:12:56 +0000

Visual Studio Code is one of the most flexible editors out there, but the real magic happens when you make it work your way. After trying different setups and tools, I’ve built a simple VS Code workflow that keeps me productive, focused, and less distracted.

Here’s how I organize my VS Code environment for maximum efficiency as a backend developer.

Keep the Sidebar Clean

I only keep the Explorer, Source Control, and Extensions views pinned. Everything else stays hidden until I need it. A cluttered sidebar slows me down, so if it doesn’t directly help me write or manage code, it’s out of sight.

For quick navigation, I use Ctrl + P to jump to files instantly. It’s faster than scrolling through folders.

Workspaces Over Folders

Instead of opening individual folders, I use VS Code Workspaces.
Workspaces let me manage multiple related projects together and remember settings like themes, extensions, and formatting rules per project.

For example, my Django and API projects have different linters and interpreters, and workspaces make that possible without conflicts.

Extensions That Actually Help

I keep my extensions minimal but powerful. Here are the essentials that make a real difference in my daily flow:

Prettier: Automatic formatting that keeps my code consistent.

GitLens: Makes version control easier to understand at a glance.

Pylance: Improves autocompletion and type checking for Python.

Error Lens: Highlights issues directly in the editor, so I catch them early.

Todo Tree: Keeps track of unfinished work through my TODO comments.

I regularly disable or uninstall extensions I no longer use, and performance improves noticeably.

Terminal Inside VS Code

I stopped switching between my terminal and editor. The integrated terminal is always open at the bottom of my screen.
For backend development, this saves time when running Django servers, managing virtual environments, or testing scripts.

Themes and Fonts Matter

A comfortable theme is not aesthetic — it’s functional.
I use a light theme during the day and a dark one at night. My current setup is One Dark Pro with Fira Code font (for clean ligatures). It reduces eye strain and makes code blocks easier to scan.

Auto Save and Format on Save

This might sound small, but turning on Auto Save and Format on Save prevents countless errors and lost changes.
It also helps when switching between branches or testing code quickly; everything stays consistent.

Keybindings for Speed

Custom shortcuts are the secret to fast navigation.

Ctrl + B → Toggle sidebar

Ctrl + ` → Toggle terminal

Ctrl + / → Comment or uncomment code
These small tweaks save seconds, but over time, they add up.

In Conclusion

Your VS Code setup should reflect how you think and code. The goal isn’t to install every extension available — it’s to build a workspace that reduces friction and keeps you in flow.

Once you personalize VS Code to your habits, you’ll spend less time managing tools and more time writing code that matters.

How to design a database like a developer:A begineer's guide to data planning

Mari — Wed, 05 Nov 2025 10:09:17 +0000

When most beginners start building projects, they rush to open their editors and start coding. They create models or tables without first asking the most important question, What am I really building?

The truth is, good backend developers don’t start from code. They start from structure, and that structure begins with database design.

In this article, I’ll walk you through how to design a database the way a developer does, by thinking about entities, relationships, and constraints before writing a single line of code.

Start with the Problem, Not the Tables

Before you design a database, pause and think about what problem your application solves.

Every database exists to serve a purpose. If you don’t know that purpose clearly, your schema will collapse once your app grows.

Ask yourself:

.What kind of system am I building?

.Who will use it?

.What data do they create or interact with?

For example, imagine you’re building a simple booking system. Your first instinct might be to create a “Bookings” table — but slow down. A booking system involves users, rooms, payments, and schedules. Each of those will eventually become part of your database structure.

Identify Your Entities

Entities are the real-world “things” your app needs to keep track of.

Think of them as nouns: User, Product, Order, Task. Each of these will eventually become a table in your database.

For example, in a task management app, your main entities could be:

.User – someone who owns tasks

.Task – something the user needs to complete

At this stage, you’re not worrying about columns or types. You’re just identifying the main objects that exist in your system.

Define Relationships Between Entities

Now that you have your entities, the next step is to connect them.

Databases are about relationships, how one piece of data interacts with another.

Here are the three main types you’ll use:

.One-to-One: A user has one profile.

.One-to-Many: A user can have many tasks.

.Many-to-Many: A product can appear in many carts, and a cart can have many products.

If you were designing the task manager mentioned earlier:

One user → many tasks
That’s a one-to-many relationship.

It’s helpful to draw this out using an ER (Entity Relationship) diagram, even a simple sketch helps visualize the connections.

Define Attributes for Each Entity

Every entity needs details, and those details become your table columns.

Let’s continue with the task manager example:

User
.id
.name
.email

Task
.id
.title
.description
.completed

user_id (to connect each task to its owner)

At this point, you’re essentially describing what each entity knows about itself.

Apply Constraints and Rules

Constraints are what keep your data clean, organized, and meaningful.

They define the rules your database follows — rules that prevent duplicate entries, broken relationships, or invalid data.

The most common ones are:

Primary Key → uniquely identifies a record (e.g., id).

Foreign Key → connects two entities (e.g., task.user_id links to user.id).

Unique → ensures no duplicates (like email addresses).

Not Null → prevents missing values for important fields.

Think of constraints as the traffic rules of your database. Without them, everything collides.

Normalize Your Data

A lot of beginners make one big mistake — they repeat data across tables.

For instance, if your “Task” table contains the user’s name and email for every task, your database will become redundant and hard to maintain.

Normalization helps avoid that. It means:

Each piece of data should live in one place.

If two tables need it, use a relationship instead of duplication.

So instead of saving the user’s name in every task, just store the user’s ID and reference it from the User table.

That’s clean, efficient, and scalable.

Visualize Your Design

At this point, you can visualize your structure:
`User

id
name
email

Task

id
title
description
completed
user_id

Relationship: One user can have many tasks.

That’s the backbone of your database — before a single line of SQL or Django code.

This is also the stage where backend developers usually create quick ER diagrams. You can use free tools like draw.io, dbdiagram.io, or even paper and pen.

Validate Your Design

Before finalizing your design, ask yourself:

Can this structure handle future features?

Can another developer understand it easily?

Is every piece of data traceable?

A good database design should make sense without needing explanation.

Conclusion

Designing a database like a developer isn’t about memorizing SQL commands. It’s about understanding your data and its relationships before you code.

When you design this way, everything that comes after, your models, serializers, APIs, and even performance tuning, becomes clearer and easier to manage.

So next time you start a project, close your editor for a moment and open your mind.
Sketch your data. Think in entities, relationships, and rules.
That’s how you build systems that last.