DEV Community: Muhammad Usman

Why You Should Learn Programming Through Books (Not Just Online Tutorials)

Muhammad Usman — Tue, 19 May 2026 11:56:45 +0000

Books don’t just teach you to code — they teach you to think like a programmer.

The man who does not read has no advantage over the man who cannot read.

Learning programming using an online tutorial is like taking a picture.

You click, and that’s that. Learning to program with books, though — that’s like creating a painting. You layer and layer on it, and you keep working for weeks. You might still have the same image in the end, but there’s a depth to it that’s impossible to capture with a snapshot.

I know we live in a world where everyone wants fast results. Watching online tutorials might seem like the easiest way to learn programming. But the quality of outcome you get with books cannot be matched.

You can go much deeper with books than you can using any other method.

And here’s something people don’t talk about enough: when you start working, there won’t be any video tutorials to help you. You’ll have to read documentation and implement things by yourself.

Building a habit of reading and understanding technical material is a must if you want a solid career as a programmer.

That’s why I’m giving you 5 practical books to get started with.

Let’s do this.

1. Python Crash Course — Learn by Building Cool Projects

If you want to learn Python by building cool projects, check out this book called “Python Crash Course.” The first half of the book deals with the basics like variables, conditionals, loops, and functions. But the real magic happens in the second part of the book, where you actually build projects.

You’ll use the pygame package to build an Alien Invasion game. How does that sound as your first ever project? You’ll be able to shoot down the alien fleet and even have a scoreboard to list high scores.

In the second project, you’ll learn how to work with APIs. You’ll download data from the GitHub API and visualize it using Matplotlib. And in the final project, you’ll build a web app using Django, a very popular Python web framework. You’ll also learn how to style your app using bootstrap, a widely-used CSS framework. At the end, you’ll even deploy your website to the cloud, so the entire world can see it.

After completing this book, you’ll feel confident enough to start building your own Python projects.

2. Eloquent JavaScript — For Web Development Enthusiasts

Next, I have a great recommendation for web development enthusiasts. If you want a deep understanding of JavaScript, try out the book “Eloquent JavaScript.”

This book is available online completely for free. And the best part? You can try out all the exercises right on their website.

In the first part of the book, you learn the basics — things like variables, functions, and objects. In the second part, you dive into how JavaScript interacts with the browser and the Document Object Model, or DOM. Finally, in the last part, you’ll learn about Node.js, which allows you to run JavaScript on the server instead of just in the browser.

Every chapter gives you exercises to test your knowledge. You’ll also build some really cool projects. You’ll create a brand-new programming language called Egg. You’ll make a web app for editing pixel art. And in the final project, you’ll build a website that helps people organize meetings to share their skills.

3. The Pragmatic Programmer — Timeless Principles

Next, we have a timeless classic: “The Pragmatic Programmer.”

The principles in this book aren’t tied to specific technologies or programming languages. That makes them applicable even years after the book was first published in 1999.

This book covers topics like debugging, testing, automation, and communication, giving you a well-rounded perspective on what it takes to be an effective software developer. It focuses on fundamental principles and best practices you can apply in any programming context.

One of the best parts about this book is how it uses clever metaphors and analogies to explain complex technical concepts. For example, it introduces the idea of “Code Kata.” In Japanese, the word Kata means “form” and is used to describe deliberate practice and repetition in martial arts. By doing Code Kata exercises, programmers can reinforce their knowledge of algorithms, data structures, and design patterns.

Whether you’re a beginner or an experienced developer, this book has something for everyone. It’s a must-read for anyone serious about honing their craft.

4. Clean Code — Writing Maintainable Software

So, you’ve learned a couple of programming languages and you’ve become a pragmatic programmer. Now, you need to know how to write clean, maintainable code. For that, we have another classic: “Clean Code” by Uncle Bob.

The primary goal of this book is to improve the readability and maintainability of your code.

It teaches you to write code that’s easy for other developers to understand, modify, and extend.

You’ll learn when — and when not — to use comments. The book encourages you to write self-explanatory code instead of relying on tons of comments. It also covers how to properly name your variables, functions, and classes.

The book uses real-world examples to drive the points home. Uncle Bob writes most code snippets in Java, but the concepts easily apply to other languages. It also introduces software design principles like the Single Responsibility Principle (SRP) and Don’t Repeat Yourself (DRY).

The book can get a bit too opinionated at times. So you don’t have to follow everything to a tee.

But it’s still a fantastic starting point to improve the quality of your code.

5. Designing Data-Intensive Applications (DDIA) — Think Like a Systems Architect

If you want to go from a junior developer to a senior developer, you have to start thinking beyond just code. You need to know how to architect your systems in a way that they can reliably handle thousands of simultaneous requests.

For that, you should read “Designing Data-Intensive Applications” (often called DDIA).

This book introduces you to the challenges of building systems that are reliable, scalable, and maintainable. You’ll learn when to use relational databases vs. NoSQL databases. DDIA also helps you understand how databases efficiently store and retrieve data.

It teaches you how to distribute data across multiple machines when your dataset becomes too large for a single server. And while it covers a lot of theory, it also provides practical advice you can use in the real world. You’ll read examples from big tech companies like Google and Amazon.

The book ends with a look at emerging trends in data systems, like new databases and storage technologies.

If you want to learn how to make smart trade-offs while building large-scale applications, DDIA is a must-read.

Final Thoughts

If you want to build a deeper understanding of programming concepts, books are the best way to do it.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

The $0 to $50/Month Tech Stack to Launch Your First SaaS

Muhammad Usman — Wed, 13 May 2026 10:20:19 +0000

Most people never ship their SaaS idea.

Not because the idea is bad. Not because they lack skills. Because they spend three weeks researching the "perfect" stack, get overwhelmed by AWS pricing pages, and quietly close the tab.

This article is not that. This is the exact stack I would use today if I were starting from zero, a developer with an idea and an empty wallet, trying to get something in front of real users as fast as possible. Every tool listed here either has a free tier or costs a few dollars a month. The whole thing stays under $50/month even after you start getting traction.

No enterprise nonsense. No over-engineering. Just tools that let you build, ship, and grow.

The philosophy first

Before the tools: the biggest mistake first-time SaaS builders make is paying for infrastructure before they have a single paying customer.

Your job in month one is not to build something scalable. Your job is to find out if anyone will pay for this thing. That means keeping costs at zero for as long as humanly possible, then introducing paid tiers only when free options genuinely become a bottleneck.

Every tool below follows that rule.

The full stack at a glance

Layer	Tool	Cost
Frontend	Next.js	Free
Backend / API	Next.js API routes or FastAPI	Free
Database	Supabase	Free (up to 500MB)
Auth	Supabase Auth	Free
Hosting	Hostinger Node.js Hosting	$3.99/mo
Domain	Hostinger	~$10/yr
Payments	Stripe	Free (2.9% + 30c per transaction)
Email	Resend	Free (up to 3,000 emails/mo)
Analytics	Plausible or Umami (self-hosted)	Free
Error tracking	Sentry	Free (up to 5,000 errors/mo)

Total at launch: $3.99/month + domain.

Layer 1: Frontend + Backend with Next.js

Next.js is the right call for a solo founder or small team building a SaaS in 2026. It handles your frontend, your API routes, and your server-side rendering in one framework. You are not maintaining a separate Express server. You are not juggling two repos. One codebase, one deployment.

Use the App Router. Use Server Components for anything that does not need interactivity. This keeps your JavaScript bundle small and your pages fast, which matters for SEO and for users on slower connections.

If your SaaS is primarily an AI tool or data-heavy backend, swap Next.js API routes for FastAPI. Python's ecosystem for AI, data processing, and async tasks is unmatched, and FastAPI is genuinely fast to build with. You can still use Next.js for your frontend and point it at a FastAPI backend.

What to build first: The signup page, the core feature (one, not five), and a simple dashboard. That is it. Resist building anything else.

Layer 2: Database and Auth with Supabase

Supabase gives you a Postgres database, authentication, real-time subscriptions, and file storage, all on a generous free tier. For a new SaaS, this is an absurd amount of infrastructure for zero dollars.

The free tier covers you up to 500MB of database storage and 50,000 monthly active users on auth. You will not hit those limits before you are making real money.

A few things worth knowing:

Use Row Level Security (RLS) from day one. It keeps your data access logic in the database, not scattered across your API.
Supabase Auth handles OAuth (Google, GitHub) out of the box. No Passport.js setup, no JWT headaches.
The Supabase JavaScript client works seamlessly inside Next.js Server Components.

When you outgrow the free tier, the Pro plan is $25/month and gives you 8GB of storage and daily backups. At that point, you should have paying customers covering it.

Layer 3: Hosting with Hostinger

This is the one paid tool in the stack from day one, and it is worth it.

The reason you do not want to rely on free hosting tiers for your main app: they sleep. Render's free tier spins down your server after 15 minutes of inactivity. Fly.io's free machines get paused. Your demo fails in front of the one person who might have become your first customer.

Hostinger's Node.js hosting runs your Next.js or Node.js app on a live server that stays on, at $3.99/month. You can also grab your domain there and connect it in a few clicks. Deployment is straightforward: connect your GitHub repo, push code, and it deploys automatically.

If you are running a FastAPI backend, Hostinger's VPS plans start at the same price range and give you root access to install anything you need: Python, Gunicorn, Nginx, whatever your stack requires.

I use Hostinger for several projects. It is not trying to be AWS. It is trying to be the easiest, cheapest way to keep a Node.js or PHP app live. For a solo founder launching a first SaaS, that is exactly what you want. Get 20% extra discount here.

Layer 4: Payments with Stripe

Stripe is the standard. Do not use anything else until you have a reason to.

The free tier means you pay nothing until you process a transaction. Then it is 2.9% plus 30 cents per charge. On a $29/month subscription, that is about $1.14 per transaction. Reasonable.

What most people do not realise: Stripe Checkout handles your entire payment UI. You do not need to build a checkout page. You redirect users to a Stripe-hosted page, and Stripe handles card collection, 3D Secure, tax calculation, and PCI compliance. Wire it to a webhook, update the user's subscription status in Supabase, done.

For subscriptions specifically, use Stripe Billing. It handles trial periods, proration on plan changes, dunning (automatic retries on failed payments), and cancellations. Things that would take weeks to build yourself.

Layer 5: Email with Resend

Transactional email (welcome emails, password resets, upgrade receipts) is non-negotiable for a SaaS. Resend gives you 3,000 emails per month for free with a proper API that works beautifully from Next.js.

The developer experience is significantly cleaner than SendGrid or Mailgun. You write your emails as React components using the react-email library, which means type safety, reusable components, and no more wrestling with HTML tables.

import { Html, Button, Text } from '@react-email/components';

export function WelcomeEmail({ name }: { name: string }) {
  return (
    <Html>
      <Text>Hey {name}, welcome aboard.</Text>
      <Button href="https://yourapp.com/dashboard">
        Go to your dashboard
      </Button>
    </Html>
  );
}

When you hit the free limit, Resend's paid tier starts at $20/month for 50,000 emails. By that point, you will have the revenue to cover it.

Layer 6: Analytics and Error Tracking

Analytics: Do not use Google Analytics. It is bloated, it shares your users' data with Google, and it will scare privacy-conscious users in 2026. Use Plausible (lightweight, privacy-first, $9/month) or self-host Umami on your existing Hostinger VPS for free. Umami is a single Node.js app. Add it as a second service alongside your main app.

Error tracking: Sentry's free tier captures 5,000 errors per month and shows you the exact stack trace, user session, and browser when something breaks in production. Integrate it in one line:

// app/layout.tsx
import * as Sentry from "@sentry/nextjs";
Sentry.init({ dsn: process.env.NEXT_PUBLIC_SENTRY_DSN });

You will find bugs you never would have found otherwise.

What the cost curve actually looks like

Month 1 (building, no users): $3.99/month. Domain is a one-time $10/year cost.

Month 2 to 3 (early users, free tier everywhere): Still $3.99/month. Supabase, Stripe, Resend, and Sentry are all free at small scale.

Month 4 to 6 (getting traction, 100+ users): You might upgrade Supabase to Pro ($25/month) and add Plausible ($9/month) for better analytics. Stack is now around $38/month.

Month 6+ (revenue coming in): Your hosting might need an upgrade depending on traffic. Hostinger's plans scale without requiring a migration to a different platform. Total stack stays under $50/month well into the thousands-of-users range.

The point is: the costs scale with your success. You are not paying $200/month in infrastructure before you have a single dollar of revenue.

The one trap to avoid

The trap is adding complexity before you have users.

You do not need a separate Redis instance on day one. You do not need a message queue. You do not need microservices, Kubernetes, or a CDN with edge functions until your traffic makes those things genuinely necessary.

Every layer of infrastructure you add is a layer you have to debug at 11pm when something breaks and your only user is waiting for a response.

Start with this stack. Get to ten paying customers. Then look at what is actually breaking and fix only that.

Quick start checklist

[ ] Create Next.js app with npx create-next-app@latest
[ ] Set up Supabase project, enable RLS on all tables
[ ] Configure Supabase Auth with Google OAuth
[ ] Get a domain and Node.js hosting on Hostinger
[ ] Connect GitHub repo for automatic deploys
[ ] Create Stripe account, set up one Product and one Price
[ ] Add Stripe webhook to update Supabase on subscription events
[ ] Set up Resend, write welcome email with react-email
[ ] Add Sentry to catch production errors
[ ] Self-host Umami on the same VPS for analytics

That is your entire infrastructure. Everything else is product.

Final thought

The SaaS graveyard is full of products that were never shipped, not products that shipped on the wrong stack.

Pick these tools. Build the thing. Ship it to five people this week.

The stack can always be changed later. The feedback you get from real users this week cannot be replicated by anything else.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.
Get 20% extra discount on Hostinger

Stop Writing Clean Code. Write Honest Code Instead.

Muhammad Usman — Sat, 09 May 2026 09:52:55 +0000

There is a codebase out there with a simple "send an email" operation that goes through seven layers of abstraction.

An EmailService that uses an EmailProvider that wraps an EmailClient that calls an EmailAdapter that uses a MessageSender that invokes a TransportLayer that finally, after all of that, calls the actual email API.

Every layer has a reason. Logging here. Error handling there. Retries somewhere in the middle. It is, by almost every definition the industry has agreed on, clean code.

It is also code that nobody on the team can fully understand anymore.

That is the problem nobody talks about when they are quoting Uncle Bob at you in a code review.

How Clean Code Stopped Being a Tool and Became a Standard

Robert Martin's book came out in 2008. It gave developers a vocabulary and a set of rules. Short functions. Meaningful names. Single responsibility. No comments because the code should speak for itself.

Good ideas. Genuinely. The problem is what happened next.

Developers turned a set of practical guidelines for a specific context into a universal standard for all code everywhere. Clean code stopped being a tool and became an identity. Writing clean code meant you were a serious developer. Writing anything else meant you were cutting corners, being lazy, not caring about your craft.

And once something becomes an identity, it stops being questioned.

So developers started abstracting things that did not need abstracting. Creating interfaces for classes that would never have a second implementation. Splitting functions into sub-functions into sub-sub-functions until the original logic was spread across twelve files and finding out what the code actually does requires a forty minute archaeology expedition.

All of it in the name of cleanliness. None of it in the name of actually solving the problem.

The Performance Conversation Nobody Wanted to Have

In 2023, a programmer named Casey Muratori published a video called "Clean Code, Horrible Performance." He took Uncle Bob's clean code examples and benchmarked them against straightforward implementations.

The clean versions were up to 23 times slower.

The reaction from the clean code community was, predictably, defensive. Performance does not matter for most applications. The bottleneck is usually the database anyway. You are optimizing prematurely.

Some of that is true. Most modern software spends the majority of its time waiting for user input, not executing business logic. For a lot of applications, the performance gap is irrelevant.

But that is not really the point Muratori was making. The point is that the clean code rules were presented as universally correct, context-free laws. And they are not. They are tradeoffs. Every abstraction you add is a layer someone has to understand. Every tiny function is a context switch in a reader's brain. Every interface is an indirection that obscures what is actually happening.

Clean code moves the complexity. It does not eliminate it.

What "Honest Code" Actually Means

Honest code is not messy code. It is not an excuse to write whatever you want and call it a style choice.

Honest code is code that does not pretend.

It does not pretend that the business logic is simpler than it is. A lot of codebases have genuinely complicated rules because the domain is genuinely complicated. Forcing that into short, clean functions sometimes means the complexity goes underground, hiding in the gaps between functions, in the sequence of calls, in the assumptions baked into naming.

It does not pretend that future requirements justify present architecture. One developer built a feature with a flexible configuration system, keyboard shortcuts, and multiple user pathways because he imagined power users doing complex workflows. Ninety percent of actual users just wanted to click one button. All the flexibility was just confusing them. The architecture was built for a future that never arrived.

It does not pretend that all code is equally important. Your authentication logic that handles money needs rock-solid testing and careful review. Your internal admin dashboard that three people use to generate reports can be rough around the edges. Treating every line of code with the same level of ceremony is not discipline. It is a misallocation of attention.

And honest code does not hide behind abstraction when a comment would do the job better and faster.

The Comment Rule Nobody Should Follow Blindly

Clean code says code should be self-documenting. Comments are a failure. If you need a comment to explain the code, the code is not clean enough.

This is one of the most damaging ideas in mainstream software development.

There is a category of code that is necessarily dense, complex, or counterintuitive, not because the developer wrote it badly, but because the problem it solves is genuinely hard. A performance-critical path that uses bitwise operations for speed. A workaround for a third-party library bug that will be removed when the library updates. A business rule that sounds insane but reflects a legal requirement that the developer spent two days understanding.

Clean code says: make the code clearer.

Honest code says: write the comment. Explain the why. Leave the breadcrumb for the next developer who will be just as confused as you were, because the confusion is correct. The thing is actually confusing.

The developer who wrote the confusing thing and left no comment was not being disciplined. They were being unkind.

The Biggest Technical Debt Nobody Tracks

Technical debt gets measured in two ways: things that broke and things that slowed down feature development.

Nobody tracks the hours spent by new developers trying to understand an abstraction layer that was added for cleanliness rather than necessity. Nobody counts the time spent tracing through seven layers of email infrastructure to find the one line that actually sends the email. Nobody measures the cognitive load of a codebase where everything is theoretically clean but nothing is immediately legible.

That cost is real. It accumulates quietly. And it is often worse in codebases that followed the clean code rules most faithfully, because the complexity did not go away. It just got distributed more evenly across more files with better names.

The biggest source of developer frustration, by a wide margin according to Stack Overflow's own data, is technical debt. Not messy code specifically. Debt. The gap between what the code is and what it needs to be.

Clean code pursued as an end in itself creates its own kind of debt. The debt of over-abstraction. The debt of architecture that outpaced the actual requirements. The debt of code that is legible line by line but incomprehensible as a system.

What to Do Instead

Write code that works first. Code that you understand. Code that you can debug at 2am when it breaks in production and you are tired and the pressure is real.

Then ask: who else needs to understand this? What do they need to know that the code cannot tell them? Write that down. In a comment, in a README, in a commit message. Somewhere.

Ask: what parts of this are likely to change? Abstract those. The parts that are stable, that have been stable for years, that nobody has asked to modify since they were written, leave them alone. Do not add an interface to something that will never have a second implementation just because a rule says to.

Ask: what does this code actually do? Not what it is supposed to do. What it actually does. If you cannot answer that in two sentences without referencing the three layers above and below it, that is not clean. That is hidden.

Honest code is code that tells the truth about what it does, where it is fragile, why it makes the choices it makes, and what it is not designed to handle.

Clean code wants to look good. Honest code wants to be understood.

Those are not always the same thing. And in the gap between them is where most debugging happens.

You have probably inherited a codebase at some point that was written by someone who cared deeply about cleanliness. Beautiful structure. Consistent naming. Short functions everywhere.

And you still could not figure out what it did.

That is not a coincidence. That is clean code working exactly as designed, optimizing for appearance at the expense of truth.

Write the comment. Name the tradeoff. Leave the breadcrumb.

The next developer will thank you. That developer is probably you, six months from now, tired, staring at something you wrote and wondering what you were thinking.

Give that person the honest version.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

What Developers Actually Feel About Their Jobs

Muhammad Usman — Thu, 07 May 2026 12:09:48 +0000

Three out of four developers are not happy at work right now.

Not burned out. Not quitting. Just not happy. Showing up. Doing the tickets. Closing the laptop. Doing it again tomorrow.

That number comes from Stack Overflow's 2025 Developer Survey, 49,000 developers across 177 countries. Only 24% said they were genuinely happy at work. The rest are somewhere on a scale between fine and actively hating it. One in three reportedly hate their job. Almost half are in what researchers call "survival mode."

Survival mode. In a profession that is supposed to be one of the most in-demand, well-paid, intellectually stimulating careers available.

So what is actually going on?

The Gap Between What We Told Ourselves and What It Actually Is

Most developers got into this because of the craft. The feeling of building something from nothing. The puzzle of it. The moment a thing you imagined actually works.

One developer described it plainly: when you get burned out, you start counting the minutes until 5pm. You go home and look for distractions. You stop caring whether the code is good. You just want it to be done.

That is not a person who hates programming. That is a person who loved it and slowly had it taken from them by something they cannot quite name.

The job sold itself one way. It turned out to be something else. And the gap between those two things is where a lot of developer unhappiness actually lives.

What Developers Say Actually Makes Them Happy

The survey data on this is worth sitting with for a moment because it is not what most companies are optimizing for.

The top driver of developer job satisfaction is not salary. It is not tech stack, perks, or remote work. It is autonomy and trust.

Developers want to be trusted to make decisions. They want to own their work. They want to not have someone looking over their shoulder second-guessing every architectural choice while simultaneously not understanding the codebase.

After that comes competitive pay. Then solving real world problems that actually matter.

Notice what is not on that list. The ping-pong table. The unlimited PTO that nobody actually takes. The AI tool the company rolled out company-wide without asking whether anyone wanted it. The reorg that moved everyone to a new team with a new manager for the third time in two years.

The things that would genuinely help developers are not complicated. They are also, for many organizations, apparently very difficult to provide.

The AI Problem Nobody Wants to Admit

There is a strange thing happening right now in developer culture around AI.

84% of developers are using or planning to use AI tools in their work. Adoption is going up every year. But here is the part that does not make it into the press releases: 46% of developers distrust AI tool outputs, compared to only 33% who trust them. Positive sentiment toward AI tools has dropped from over 70% to 60% in just one year.

Developers are using something they increasingly do not trust, because they feel like they have to.

Two thirds report that AI answers are almost right but not quite. 45% say they lose significant time debugging AI-generated code. The thing that was supposed to make their jobs easier is, for nearly half of them, creating a new category of frustrating work: cleaning up confident mistakes.

And there is a subtler cost underneath that. When you spend your day fixing something a tool generated rather than building something yourself, you lose the thing that makes the work feel meaningful. Problem-solving. Ownership. The satisfaction of understanding why something works.

One survey respondent put it simply: the most satisfying part of the job is solving problems. That has not changed. What has changed is how much of the day is actually spent doing that versus managing the output of tools that solved the wrong problem fast.

The Developer Nobody Is Building Tools For

Here is a segment of the developer population that the industry largely ignores: the one working completely alone.

The solo freelancer. The developer at a small company where they are the only technical person. The person building a side project for two years hoping someone notices. The junior engineer on a team where everyone else is too busy to explain things and asking questions starts to feel like a liability.

These developers are not unhappy because of bad management or the wrong tech stack. They are unhappy because the work is genuinely isolating in a way that has no structural fix. Nobody is going to address it in a quarterly planning session. There is no metric for it.

One developer spent years building an npm module, waiting for someone to find it meaningful, maybe even collaborate on it. The module sat there. The months passed. Even his colleagues could not understand what he had built. That specific kind of invisible effort, work that is technically real and personally significant but completely unwitnessed, is one of the most common and least-discussed experiences in the field.

Survival Mode Is Not a Phase. For Many, It Is the Default.

The phrase "survival mode" sounds temporary. Like a rough patch before things improve.

For a lot of developers, it is just Tuesday.

They are not dramatically unhappy. They are not about to quit. They are doing the standup, the sprint planning, the code review, the deployment. They are technically fine. But the version of themselves that used to get excited about a hard problem, that used to stay late not because of a deadline but because they genuinely wanted to see if it worked, that version quietly left at some point and nobody noticed.

One developer who lost his passion for code described it: without passion, work is just grinding. You go through the motions but do not enjoy the moment.

Going through the motions. That is survival mode. And it is invisible to everyone except the person doing it.

The Number That Should Bother More People

24% of developers are happy at work.

That is the high point. That is after job satisfaction improved from last year.

In any other industry, if three quarters of the workforce reported being unhappy, it would be a crisis. In tech, it is a data point in an annual survey that gets shared on LinkedIn for two days and then forgotten.

The developers who are satisfied are mostly the ones with autonomy, decent pay, and work that feels like it matters. Those things are not rare because they are hard to provide. They are rare because they are not what most organizations are actually measuring or optimizing for.

Retros capture what broke. Sprints capture what shipped. Stand-ups capture what is blocked. Nobody built a ritual for what you solved, or whether the person solving it still cares about their work.

That gap, between what organizations track and what developers actually need, is where most of the unhappiness lives.

You might be reading this and recognizing yourself somewhere in it. The survival mode. The AI frustration. The invisible work nobody witnesses. The counting of minutes.

If you are, you are not an outlier. You are three quarters of the profession.

That is worth knowing. Not because it fixes anything. But because the story you have been telling yourself, that everyone else is fine and something is wrong with you, is not true.

Most people are not fine. They are just quiet about it.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

Nobody Talks About How Lonely Being a Developer Can Be

Muhammad Usman — Wed, 06 May 2026 07:00:38 +0000

You fixed the bug. The one that had been eating your brain for two days straight.

You lean back. You want to tell someone. You look around and realize there is nobody to tell. Your family would smile and nod. Your non-dev friends would say "nice!" and immediately change the subject. Your teammates are buried in their own tickets.

So you just close the tab and move on.

That moment right there. That is what developer loneliness actually feels like. Not dramatic. Not a breakdown. Just a quiet win that disappears into the void because nobody around you speaks the same language.

The Cruelest Irony in Tech

We work in one of the most connected industries on earth. GitHub. Discord. Slack. Stack Overflow. Twitter threads at 1am. You can pull a library that someone in Finland wrote three years ago and have it running in your project in 30 seconds.

And yet.

A developer on devRant put it plainly: "If you are a team of one, it will be both lonely AND frustrating." That is not an edge case. That is a massive portion of the developer world. Freelancers, solo founders, juniors on teams where nobody has time to talk, remote workers staring at a screen in a room that has been silent since Tuesday.

The connected infrastructure of tech is for the code. Not always for the people writing it.

What Nobody Posts About

Here is what you see on Twitter and LinkedIn: someone shipping a side project in a weekend. Someone cracking a FAANG interview. Someone's first PR getting merged. The highlight reel of developer life.

Here is what one developer actually wrote about their experience: "Me, sitting in a dim room at 2am, stuck on a bug. Me, refreshing Stack Overflow, hoping someone posted a solution. Me, watching yet another tutorial, wondering if I am even progressing. No one claps when you finally debug something you have been stuck on for days. No one sees the hours spent staring at console logs."

That version does not get the likes. So it does not get posted. So everyone assumes they are the only one feeling it.

They are not.

The Part That Stings the Most

It is not just the silence during work hours. It is not being able to share any of it with the people you love.

You spend 8 hours wrestling with a system design problem and you solve it. You want to feel that with someone. But you cannot really explain what you solved without a 20 minute backstory that even then will not land. So you just say "work was fine."

One developer described this as the work side of your life becoming "a black box" for everyone around you. Your job, the thing you spend most of your waking hours doing, becomes essentially invisible to the people closest to you. That is a strange and specific kind of loneliness that nobody really warns you about when you are learning to code.

Remote Work Made the Walls Thicker

For developers who already worked alone, remote work changed very little. For everyone else, it quietly removed things they did not even know they were depending on.

The coworker who walked past and noticed you looked frustrated. The five minute conversation at the coffee machine that was not about anything important but still made you feel like a human being. The shared lunch where you complained about a meeting and someone laughed because they were in the same meeting and felt the same way.

Research backs this up: remote work is genuinely associated with increased employee loneliness, and virtual meetings, especially task-focused ones, do not replicate the kind of informal social interaction that actually builds connection. A Slack message is not a conversation. A standup is not a check-in. And "async first" as a team culture, for all its productivity benefits, can make a person feel like a ticket-processing machine rather than a colleague.

43% of remote workers report feeling lonely at work. That number is higher than for office employees. And in tech, remote work is not the exception. It is the default.

The Thing We Do Instead

Here is the move most developers make when the isolation gets heavy: they open VS Code.

New side project. New framework to learn. New problem to solve. Because that is what the culture teaches. You feel bad? Get productive. Feeling disconnected? Ship something. The grind is the answer.

It works, for a while. Solving problems does feel good. But you can build five projects and still finish the week feeling like you have not had a real conversation with anyone who gets what you do. Output is not a substitute for connection. It just keeps you too busy to notice the gap.

This Is Not a "Just Introduce Yourself at Meetups" Article

There are a thousand articles that will tell you to join a Discord server, go to a local meetup, find a pair programming partner. That advice is fine. It is also incomplete, because the loneliness that developers describe is not just about lacking a community to join.

It is about the nature of the work itself. The long uninterrupted stretches where deep focus is the goal and interaction is the interruption. The way "communicate async, avoid meetings" became a productivity religion that quietly stripped the humanity out of how teams work. The fact that after months or years of low social engagement, your social skills actually atrophy. You get prickly. Conversations feel harder. And then the loneliness compounds because now you feel bad at the thing that would fix the problem.

One developer who reflected on a failed solo project said it plainly: "My mistake was making everything alone. I could not enjoy enough the technical success moments because nobody on my team understood them, and the bad moments affected me too much because I could not talk them out. Without sharing, I did not even like the good parts."

That is the full cost. Not just the hard moments feeling harder. The good moments stop feeling good too.

So What Actually Helps

Not a listicle. Just honest things.

Finding one person who genuinely understands the work changes more than any community will. Not a server with 10,000 people. One person you can message at 11pm and say "this is broken and I do not know why" and have them respond with something real. That is worth more than a hundred passive Discord memberships.

Letting the wins matter, even if nobody else can understand them. Write it down. Say it out loud to yourself. "I fixed it." That moment is real even if nobody claps.

Lowering the bar for what counts as connection. You do not need a deep technical conversation every day. Sometimes it is enough to sit in a coffee shop and just be around other people who are also doing their own focused work. Ambient human presence is genuinely different from isolation, even when nobody speaks.

And maybe the most important thing: stop treating the loneliness like a personal failure or a productivity problem to be optimized. It is a structural reality of this work. Acknowledging it does not make you weak. It makes you honest.

You are probably reading this alone. Screen glow, headphones on, maybe a cold cup of coffee somewhere nearby.

If any of this landed, you already know it is real. You did not need the research. You just needed to see it written down by someone who was not pretending it does not exist.

Now you have seen it.

You are not the only one.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

HTML Attributes That Do More Than You Think

Muhammad Usman — Thu, 30 Apr 2026 05:42:51 +0000

Two developers build the same page. Same images, same form, same content. One loads faster, scores better on Core Web Vitals, and feels smoother on mobile. The other does not.

The difference is four HTML attributes. Each one takes about thirty seconds to add. Each one has a real, measurable impact on the people using your page.

Here is what they do and how to use them right.

Here are the exact code examples:

loading

By default, the browser fetches every image it finds in your HTML immediately, even the ones three screens below the fold that the user may never reach. On pages with many images, that is a lot of wasted bandwidth upfront.

The loading attribute changes this.

<!-- Loads immediately -->
<img src="hero.jpg" alt="Hero" loading="eager">

<!-- Waits until the user scrolls near it -->
<img src="article-photo.jpg" alt="Photo" loading="lazy">

<!-- Works on iframes too -->
<iframe src="map.html" title="Map" loading="lazy"></iframe>

loading="lazy" defers the request until the user is actually close to that element. If they never scroll there, the request never happens.

One thing to be careful about. Never use loading="lazy" on images visible when the page first opens. Those images should load immediately. Deferring them increases your Largest Contentful Paint time, which affects both user experience and search rankings.

The rule is simple. Above the fold gets eager or nothing. Below the fold gets lazy.

<!-- Hero. Load it right away. -->
<img src="hero.jpg" alt="Hero" loading="eager" width="1200" height="600">

<!-- Further down the page. Let it wait. -->
<img src="section-photo.jpg" alt="Photo" loading="lazy" width="800" height="500">

Always include width and height with lazy loaded images. Without them, the layout shifts when the image arrives, which is jarring for users and hurts your Cumulative Layout Shift score.

fetchpriority

The browser assigns a priority to every resource it loads. Stylesheets are high priority because they block rendering. Images are low priority by default because most of them are below the fold.

The problem is your hero image is also low priority by default, even though it is the most important thing on the page.

fetchpriority lets you correct that.

<!-- Tell the browser this image matters more than other images -->
<img src="hero.jpg" alt="Hero" fetchpriority="high">

<!-- This script is not critical, let it wait -->
<script src="analytics.js" fetchpriority="low" defer></script>

<!-- Works on preloads too -->
<link rel="preload" href="hero.jpg" as="image" fetchpriority="high">

The most impactful use is on your LCP image. Adding fetchpriority="high" moves it to the front of the loading queue from the very start instead of sitting behind fonts and scripts that got there first.

<img  src="hero.jpg"  alt="Hero"  fetchpriority="high"  loading="eager"  width="1200"  height="600">

fetchpriority="high" and loading="eager" are doing different things here. eager means do not defer this image. fetchpriority="high" means when competing with other resources for bandwidth, this one goes first. Both belong on your hero image.

The low value is useful when you are preloading something that is not needed for the initial render and you do not want it competing with resources that are.

<link rel="preload" href="secondary-font.woff2" as="font" fetchpriority="low" crossorigin>

This attribute became fully supported across all major browsers in October 2024 and works as a hint, meaning the browser will respect it when it can and use its own judgment when needed.

autocomplete

The autocomplete attribute tells the browser what kind of data lives in a field. When the browser knows this, it can offer the right saved value instantly, whether that is a saved address, a credit card number, or login credentials.

Most developers know it accepts on and off. What is less known is that it accepts over 50 specific values, each one mapping to a particular type of information.

<!-- Personal details -->
<input type="text" autocomplete="given-name" placeholder="First name">
<input type="text" autocomplete="family-name" placeholder="Last name">
<input type="email" autocomplete="email" placeholder="Email"><input type="tel" autocomplete="tel" placeholder="Phone">

<!-- Address -->
<input type="text" autocomplete="street-address" placeholder="Street address">
<input type="text" autocomplete="postal-code" placeholder="Postal code">
<input type="text" autocomplete="country" placeholder="Country">

<!-- Payment -->
<input type="text" autocomplete="cc-name" placeholder="Name on card">
<input type="text" autocomplete="cc-number" placeholder="Card number">
<input type="text" autocomplete="cc-exp" placeholder="Expiry">
<input type="text" autocomplete="cc-csc" placeholder="CVV">

<!-- Login -->
<input type="text" autocomplete="username" placeholder="Username">
<input type="password" autocomplete="current-password" placeholder="Password">
<input type="password" autocomplete="new-password" placeholder="Create a password">

current-password and new-password are worth understanding separately. current-password tells the browser the user is entering an existing password, so it offers saved credentials. new-password tells it the user is creating one, so it offers to generate a strong password instead. One value, completely different behavior.

For one-time verification codes there is a dedicated value:

<input  type="text"  autocomplete="one-time-code"  inputmode="numeric"  maxlength="6">

On iOS, when this is set and an SMS with a code arrives, the keyboard automatically surfaces a one-tap option to fill it in. That entire copy-and-paste flow collapses into a single tap because the browser understands what the field needs.

inputmode

When a user taps an input on mobile, a keyboard appears. Which keyboard appears is something you can control.

inputmode tells the browser which virtual keyboard to show. It does not change validation or field behavior, only the keyboard. This makes it more flexible than changing the type attribute, which affects both.

<!-- Digits only, without type="number" side effects -->
<input type="text" inputmode="numeric">

<!-- Digits plus decimal point, right for prices -->
<input type="text" inputmode="decimal">

<!-- Telephone keypad with * and # -->
<input type="text" inputmode="tel">

<!-- Email keyboard with @ shortcut -->
<input type="email" inputmode="email">

<!-- URL keyboard with / and .com -->
<input type="text" inputmode="url">

<!-- Search keyboard, enter key labeled Search --><input type="search" inputmode="search">

numeric and decimal are the ones people mix up most often. numeric shows digits 0 to 9 only. decimal adds a decimal separator. Use decimal for prices and measurements, numeric for PINs, postal codes, and verification codes.

Here is what a complete credit card field looks like when autocomplete and inputmode work together:

<input  type="text"  autocomplete="cc-number"  inputmode="numeric"  pattern="[0-9\s]{13,19}"  placeholder="1234 5678 9012 3456">

Each attribute has a specific job. autocomplete tells the browser what the field collects. inputmode shows the right keyboard. pattern handles validation. None of them overlap.

The same approach applies to an OTP field:

<input  type="text"  autocomplete="one-time-code"  inputmode="numeric"  maxlength="6"  pattern="\d{6}">

On iOS this combination triggers automatic SMS code detection. A flow that used to require switching apps and copying a code becomes one tap. The attributes are doing all the work.

What connects all four

None of them need JavaScript. None of them change how your page looks. They are pieces of information you give the browser so it can make better decisions for your users.

loading controls when a resource is fetched. fetchpriority controls how urgently it is fetched. autocomplete tells the browser what data a field expects. inputmode tells it which keyboard fits that data.

Small additions. Real impact.

The WHATWG Living Standard lists every valid `autocomplete` value. If you build forms regularly, the full list is worth a look.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

15 Open-Source Tools That Feel Illegal

Muhammad Usman — Tue, 28 Apr 2026 11:42:54 +0000

These open-source tools are so powerful, free, and versatile, they make work faster, smarter, and almost too easy to believe.

Some tools are so good, so free, and so powerful, you almost feel guilty using them. They don’t just save time; they completely change the way you work. In 2026, open-source isn’t just a way to avoid paying. It’s about working smarter, building faster, and keeping control without relying on anyone else. These 15 tools are so capable, so polished, and so versatile, they almost feel unfair.

OpenClaw: Smarter AI Agents

https://openclaw.ai/
OpenClaw is like having an AI assistant that actually works for you. It lets you create autonomous agents that can follow instructions, manage files, send messages, and even automate repetitive tasks. Unlike most AI tools that require cloud access, OpenClaw runs locally.

That means your data never leaves your machine, and you stay in full control. What’s really exciting is how flexible it is. You can set it up for simple tasks like organizing your code files or more complex workflows that involve multiple steps and integrations.

For anyone exploring AI, this tool feels almost magical because it allows automation that used to require entire teams.

Appwrite: Everything You Need in One Backend

https://appwrite.io/

Appwrite turns what used to be a complicated backend setup into something fast and manageable. It bundles authentication, databases, file storage, and serverless functions all into one platform.

Setting up a backend that usually takes hours can now be done in minutes. The best part is the simplicity, you don’t need to juggle multiple services or worry about compatibility. You can focus on building your app, not wrestling with infrastructure.

Startups and solo developers will especially appreciate how it handles security and user management effortlessly while still giving you full control over your environment.

OpenTofu: Cloud Infrastructure

https://opentofu.org/

Managing cloud infrastructure has always been tricky. OpenTofu changes that by letting you define servers, networks, and storage in code. Every change is versioned, which means you can roll back mistakes instantly.

It works across multiple cloud providers, so you’re not locked in. Teams that handle multiple deployments will love how much safer and predictable it makes everything.

It feels almost illegal because what used to take hours or even days can now be automated and repeated with a few lines of code.

Tuleap: Agile Project Management

https://www.tuleap.com/

Tuleap is a full-featured platform for project management. It combines agile boards, issue tracking, and code collaboration in one place.

You can plan sprints, track progress, and have a clear view of your team’s work without hopping between multiple apps. What sets it apart is how flexible it is. It works for small teams, large enterprises, and open-source communities alike.

If you’ve ever struggled to keep projects organized, Tuleap feels like a revelation because it gives you structure without being rigid.

OpenDesk: Productivity Without Subscriptions

https://www.opendesk.eu/en

OpenDesk is a complete productivity suite. It includes documents, spreadsheets, presentations, email, and a calendar. Everything is integrated and works together seamlessly. For anyone tired of subscriptions and software that locks you in, OpenDesk is a breath of fresh air.

It’s surprisingly polished for an open-source project, and it’s compatible with common file formats, which makes collaborating with others effortless.

Ladybird: Browsing Freedom

https://ladybird.org/

Ladybird isn’t another Chromium or Firefox clone. It has its own engine and focuses on speed, simplicity, and privacy. It’s lightweight, responsive, and feels different from the browsers we’ve all gotten used to.

Using Ladybird, you get a sense of ownership, you can see what’s going on under the hood, and it respects your data. For anyone frustrated with slow or bloated browsers, Ladybird is a tool that feels almost too good to be free.

Supabase: Build Real-Time Apps

https://supabase.com/

Supabase is the open-source alternative to Firebase, and it’s powerful. It gives you a PostgreSQL database, authentication, storage, and real-time APIs that are ready to use. Hosting it yourself or using their managed cloud keeps you in control.

For developers building chat apps, dashboards, or collaborative tools, Supabase turns what used to be complex into something seamless. You don’t just get speed, you get freedom to structure your backend exactly how you want.

Apache Allura: Keep Everything Together

https://allura.apache.org/

Apache Allura is a one-stop solution for project collaboration. It hosts code repositories, issue tracking, forums, and documentation. Managing multiple projects suddenly feels organized instead of overwhelming.

Open-source communities and teams that juggle several initiatives will find it invaluable. The platform makes communication and tracking easier, and everything works together naturally.

OpenTelemetry: Understand Your Systems

https://opentelemetry.io/

OpenTelemetry gives you complete visibility into your applications. It collects metrics, logs, and traces across multiple services.

If your apps are distributed or microservice-based, OpenTelemetry helps you understand performance issues, bottlenecks, and errors in real time.

It’s like giving your system a microscope, suddenly you can see problems before they become crises.

LangChain: Intelligent Workflows

https://www.langchain.com/

LangChain lets you chain AI models, tools, and memory to create agents that act intelligently. You can build AI workflows that automate complex tasks, from answering questions to executing sequences of commands.

It’s flexible, and the possibilities feel almost limitless. If you’ve wanted AI to do more than just chat, LangChain makes it feel real and achievable.

OpenCode: Code Faster and Smarter

https://opencode.ai/

OpenCode is a coding assistant that runs locally. Unlike cloud-based AI coding tools, it never sends your code anywhere. It helps with suggestions, automates boilerplate, and can even debug issues.

Developers who value privacy and speed will find it incredibly powerful. It’s like having a teammate who never sleeps and knows your codebase inside out.

Kubernetes: Scale Effortlessly

https://kubernetes.io/

Kubernetes is the standard for managing containers and orchestrating applications. Deploying, scaling, and managing apps used to be complicated and error-prone. Kubernetes automates all of that. For teams deploying multiple services, it’s a lifesaver. It handles the complexity in the background so you can focus on building features instead of infrastructure.

Hugging Face: Access AI Models Instantly

https://huggingface.co/

Hugging Face hosts thousands of AI models, from NLP to computer vision. You can download, train, or deploy them easily.

For researchers and developers, it’s like having a library of the most advanced AI at your fingertips. You don’t have to start from scratch, which saves months of work and experimentation.

TensorFlow and PyTorch: Build Anything

https://www.tensorflow.org/

TensorFlow and PyTorch are the foundations of modern AI. TensorFlow is structured and ideal for production environments.

PyTorch is flexible and perfect for prototyping and research. Together, they let anyone create complex AI models without expensive infrastructure. The speed, flexibility, and community support make them indispensable.

Open-source is no longer just a budget-friendly alternative.

These 15 tools are powerful, polished, and incredibly versatile. They make work faster, smarter, and more enjoyable. From AI to cloud infrastructure to project management to productivity, these tools are reshaping the way developers, teams, and creators work. Using them feels almost too good to be legal, but that’s exactly why they deserve your attention today.

Did you learn something good today?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

How I Built a Money Machine by Outranking a Hosting Giant

Muhammad Usman — Mon, 27 Apr 2026 10:18:30 +0000

I have a confession.

I beat a company with a 100-person marketing team, a massive SEO budget, and years of domain authority.

On their own keyword.

And I did it in one afternoon.

Three months ago I published a single article on Medium. A simple comparison piece. "Hostinger vs Namecheap." Added my affiliate link. Hit publish. Closed my laptop.

Today that article sits at #1 on Google. Right above Hostinger's own page. And it has been quietly earning me affiliate commissions every single day since.

No website. No backlinks. No SEO agency. No waiting a year for Google to trust me.

Just one strategy most people have never heard of.

It is called Parasite SEO.

What Is Parasite SEO?

Parasite SEO is the practice of publishing content on high-authority platforms that Google already trusts, instead of trying to build that trust yourself from scratch.

Think about how long it takes a brand new website to rank on Google. Six months minimum. Often twelve. Sometimes never. You need backlinks, consistent content, technical SEO, and patience most people simply do not have.

Parasite SEO skips all of that.

When you publish on platforms like Medium, Reddit, LinkedIn, Substack, or GitHub, you instantly inherit years of domain authority those platforms have built. Google sees your content through the lens of that platform's reputation. And it ranks accordingly.

That is the cheat code.

Why Did My Article Beat Hostinger?

This is the part most people find hard to believe.

Hostinger is a massive company. They have professional SEO teams, content writers, link building campaigns, and a domain that has been around for years. On paper, there is no reason a random Medium article should outrank them.

But here is what Google actually cares about.

Search intent.

When someone types "Hostinger vs Namecheap" into Google, they are not looking for Hostinger's opinion on Hostinger. They know that page is going to tell them Hostinger is the best option. That is obvious. That is useless to them.

They want a real, unbiased, third-party take.

My Medium article gave them exactly that. An honest comparison. Pros and cons of both. Written like a human being talking to another human being.

Google's entire job is to match the searcher with the most helpful result. My article was more helpful than Hostinger's own page for that specific search. So Google put me first.

Authority plus intent equals rankings. That is the full formula.

The Exact Process I Used

Here is every step, nothing held back.

Step 1: Find a High Buying Intent Keyword

Not all keywords are equal for affiliate marketing.

You want keywords where the person searching is already close to making a purchase decision. They are not casually browsing. They are comparing options and about to pull out their credit card.

The best formats for this are:

"X vs Y" (Hostinger vs Namecheap)
"Best X for Y" (Best hosting for WordPress beginners)
"X Review" (Hostinger Review 2026)
"X Alternative" (Namecheap Alternative)
"X Discount" or "X Coupon" (Hostinger Promo Code)

These keywords have commercial intent baked in. The person is ready to buy. Your affiliate link is the last step in their journey.

For my article, I targeted "Hostinger vs Namecheap" because it had solid search volume, clear buyer intent, and the competition on the first page was beatable with the right platform.

Step 2: Choose the Right Platform

Not every platform works equally well for every niche. Here is a quick breakdown:

Medium works best for tech, software, marketing, finance, and lifestyle content. It has enormous domain authority and articles can rank surprisingly fast. Perfect for hosting comparisons, tool reviews, and anything in the SaaS space.

Reddit is incredibly powerful right now. Google has given Reddit a massive boost in rankings over the past year. The right subreddit with a helpful post or comment containing your link can drive serious traffic. Works well for almost any niche.

LinkedIn Articles rank well for business, career, marketing, and professional tools. If your affiliate product has a business audience, LinkedIn is underutilized for this.

Substack is growing in authority fast. Great for newsletters and long-form content in any niche.

GitHub is a hidden gem for developer-focused affiliate products. A well-structured README or repository comparing dev tools can rank extremely well.

Quora still holds authority for question-based keywords. Answer a question thoroughly, link naturally, and it can stick on the first page for years.

Step 3: Write Content That Actually Helps

This is where most people get it wrong.

Parasite SEO does not mean low-effort spam. Google is smart enough to know the difference between genuinely helpful content and thin affiliate garbage.

Your article needs to:

Actually answer the question the searcher has
Cover both options honestly including the downsides
Be written in a natural human voice
Provide a clear recommendation based on different use cases
Include your affiliate link naturally, not forced

The reason my article ranks is not just because it is on Medium. It is because it is genuinely useful. Someone reading it walks away knowing exactly which hosting provider fits their situation. That is what Google rewards.

Step 4: Optimize the Basics

You do not need to be an SEO expert for this. A few simple things make a big difference.

Put your keyword in the title. Put it in the first paragraph. Use it naturally a few more times throughout the article. Write a clear meta description if the platform allows it. Use subheadings that match what people are searching for.

That is honestly most of what you need.

Step 5: Publish and Let It Work

This is the best part.

Once you publish, the article starts getting crawled and indexed. On high-authority platforms this can happen within hours. Rankings typically settle within a few days to a few weeks depending on the competition.

After that, you do not touch it.

No link building campaigns. No social media promotion required. No updating every few months. The article just sits there and earns.

Why This Works Even Better in 2026

A lot of people think SEO is getting harder. And for new websites, they are right.

But for Parasite SEO the conditions are actually getting better.

Google has been rewarding trusted platforms more aggressively over the past two years. Reddit, Medium, LinkedIn, and Quora are showing up more than ever in search results. At the same time, AI-generated content flooding the web has made Google double down on platform trust signals.

When everyone is building AI content farms on new domains, being on an established trusted platform makes you stand out even more.

The window is wide open right now.

The Numbers That Actually Matter

I am not going to throw out income claims because every niche and keyword is different. What I will tell you is this.

One article. One afternoon of work. Zero ongoing maintenance. Still earning three months later with no signs of stopping.

The math on that is very favorable regardless of the exact numbers.

And I am now replicating this formula across different niches. Same process every time. Different keyword, different platform, new affiliate link. Each one a new income stream that runs on autopilot.

What You Need to Get Started

Here is the honest truth. The barrier to entry for this strategy is extremely low.

You need:

A free account on Medium, Reddit, or whichever platform fits your niche
Basic writing ability (you do not need to be a great writer, you need to be a helpful one)
An affiliate program to join (most are free to join, Hostinger, Amazon Associates, and ShareASale are good starting points)
A few hours to research your keyword and write your article

That is genuinely it.

No investment required. No technical skills. No existing audience.

Just the right keyword, the right platform, and content that helps people make a decision.

Final Thoughts

Most people spend months building websites, chasing backlinks, and waiting for Google to notice them.

Parasite SEO flips that entire model on its head.

You go where Google already looks. You write something genuinely useful. You add your affiliate link. You walk away.

The internet does not care how big your marketing team is. It cares whether your content is the most helpful thing on the page for a specific search.

A one-person operation with the right strategy will beat a 100-person team every single time if they understand this.

I did it once. I am doing it again. And again.

You can too.

If you want to know exactly how I find these keywords and which platforms work best for specific niches, drop a comment below or reach out directly. Happy to help you get your first article ranking.

9 Rules That’ll Help You Write Clean Code

Muhammad Usman — Sat, 25 Apr 2026 17:02:10 +0000

You write code every day. It runs. Tests pass. Tickets close. But six months later, you open that same file and think:

“Who wrote this?”

It was you. And that’s the problem.

Clean code isn’t about being clever. It’s about being kind to the next person who reads your work, and most of the time, that person is future you. These 9 rules won’t just clean up your codebase. They’ll change how you think about writing software altogether.

Let’s get into it.

1. You Ain’t Gonna Need It (YAGNI)

Press enter or click to view image in full size

This one saves more time than almost any other rule on this list.

YAGNI comes from Extreme Programming, and the idea is simple: don’t write code for a future you can’t predict. Developers have a habit of thinking ahead. “What if we need this later?” And so they build a feature, a toggle, an abstraction, for a requirement that never actually comes.

That unused code still has to be read. Still has to be maintained. Still has to be understood by every new developer who joins the team.

Build what you need today. Design for change, yes. But don’t write code for imaginary tomorrows.

2. Single Responsibility Principle (SRP)

A quick test for you: Can you describe what a function or class does without using the word “and”?

If not, it’s doing too much.

Robert C. Martin, also known as Uncle Bob, defined SRP as part of the famous SOLID principles back in 2000. His exact words:

“A class should have only one reason to change.”

Not one thing, one reason to change. That’s a subtle but important distinction.

A login module should not change because the checkout flow changed. A function that fetches data should not also format it for display. Keep responsibilities focused, and your code becomes dramatically easier to test, maintain, and understand.

3. Don’t Repeat Yourself (DRY)

Press enter or click to view image in full size

Andy Hunt and Dave Thomas coined this one in The Pragmatic Programmer, and it might be the most quoted rule in software development:

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

In plain terms, write it once and use it everywhere.

Bugs multiply when logic is duplicated. If you fix it in one place but miss the other three, you have just shipped a problem. DRY solves that by making sure changes happen in one place.

One caveat worth knowing: DRY can be overdone. Forcing abstractions where they don’t belong creates code that’s technically non-repetitive but completely unreadable. The “Rule of Three” is a good gut check, duplicate once, abstract on the third occurrence.

4. Fail Fast (FF)

Press enter or click to view image in full size

This one doesn’t get discussed enough, and it should.

The "fail fast" principle is straightforward, detect errors as early as possible and stop immediately. Don’t let bad data silently travel deep into your system before it causes a problem. Surface the error right where it happens.

Eric Raymond put it perfectly in The Art of Unix Programming

“Repair what you can, but when you must fail, fail noisily and as soon as possible.”

The benefit is real. When something breaks close to where the bad input entered, debugging takes minutes instead of hours.

5. Keep It Simple, Stupid (KISS)

Press enter or click to view image in full size

Fun fact, KISS didn’t come from software. The U.S. Navy first noted it in 1960 and attributed it to Kelly Johnson, lead engineer at Lockheed Skunk Works. He challenged his team to design aircraft that an average mechanic in a field, under combat conditions, could repair with only basic tools.

That’s the standard. Can someone maintain the performance under pressure with limited context?

In software, KISS means resisting the urge to write clever code. That brilliant one-liner you’re proud of? The next developer will spend 20 minutes decoding it. Readable code beats clever code every single time. Simple systems are easier to debug, easier to extend, and easier to hand off.

6. Test Driven Development (TDD)

Press enter or click to view image in full size

Kent Beck developed TDD in the late 1990s as part of Extreme Programming, though he famously called it a rediscovery rather than an invention. The cycle is known as Red, Green, Refactor:

Write a failing test (Red)
Write just enough code to make it pass (Green)
Clean up the code without changing behaviour (Refactor)

What most people miss is that TDD isn’t really about testing. It’s about design. Writing the test first forces you to think about your API before your implementation. It makes you define what the code should do before figuring out how to do it. The tests are just the safety net that lets you refactor with confidence later.

7. Separation of Concerns (SOC)

Press enter or click to view image in full size

Edsger Dijkstra introduced this concept way back in 1974, and it’s so foundational that two of the five SOLID principles are direct derivations of it.

The core idea: don’t write your program as one big block. Break it into distinct sections where each one handles a single, specific concern. UI logic lives separately from business logic. Database access lives separately from both.

A practical way to think about it: if changing your database requires touching your UI code, your concerns are not separated. When they are properly isolated, you can modify one part of the system without setting the rest on fire.

8. Document Your Code (DYC)

Press enter or click to view image in full size

Here’s the thing about documentation that nobody says clearly enough: don’t comment on what the code does, comment on why it does it.

Good code explains itself. A well-named function, a clear variable, a logical structure, these tell you what is happening. What they can’t always tell you is why a specific decision was made, why a particular edge case is handled the way it is, or why an obvious-looking approach was deliberately avoided.

That’s what comments are for. Write for the developer who joins your team in a year, the one with no context, no Slack history, and a deadline. Because that developer might also be you.

9. Boy Scout Rule (BSR)

Press enter or click to view image in full size

Uncle Bob adapted this from an actual Boy Scouts principle:

“Always leave the campground cleaner than you found it.”

Applied to code, it means this: every time you touch a file, leave it slightly better than you found it. Rename a confusing variable. Remove a dead comment. Break up a function that’s grown too large. You don’t have to refactor the whole codebase. Just make one small improvement per commit.

The compounding effect is real. If five developers each make one small improvement per commit, pushing a few commits a day, the codebase gets meaningfully better every single week without a single “refactoring sprint” ever being scheduled.

Clean code isn’t a one-time project. It’s a daily habit.

The Bigger Picture

These 9 rules share one idea at their core:

Write code for humans, not just computers.

Computers will run almost anything you throw at them. It’s your teammates, your future self, and everyone who maintains this system after you who need the code to be clear, intentional, and honest.

Start with one rule. Apply it consistently. Then pick another.

That’s how good codebases are built.

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

Here's the full playbook for ranking your posts on Google page 1

Muhammad Usman — Thu, 23 Apr 2026 13:24:36 +0000

Muhammad Usman

Apr 23

$2,000/month with parasite SEO. No website. No waiting 6 months.

#seo #marketing #growth #beginners

Comments

2 min read

Why Settle for a Boring Internet When We Can Build Something Unforgettable?

Muhammad Usman — Thu, 16 Apr 2026 08:14:40 +0000

For the past 5 years, I’ve been designing, developing, and optimizing WordPress websites with just one goal in mind, making them perform in search.

I’ve always been fascinated by how a few well-chosen and well-written words can make a website come alive in search results. To me, SEO isn’t just about rankings, it’s all about a mix of curiosity, problem-solving, and storytelling.

I love digging into analytics like a detective, always experimenting with strategies, and seeing the absolute great results in real-time.

Each success have taught me something new about human behavior and search patterns of every platform. When I’m not optimizing websites, I’m always exploring new trends, testing new tools, or writing content that connects with real people.

I’ve spent the last 5 years in designing and developing websites that don’t just look good, but actually performs very well in search engines. As for me, SEO always comes first, making sites fast, secure, and responsive.

Then shifting in the technical work like Core Web Vitals, site architecture, and schema markup. Along the way, I’ve tested on page and off-page strategies, fine-tuned speed, and seen the results in real numbers organic traffic tripling, business priority keywords slowly climbing into the top 3, and clean builds that both Google and real users trust, and don’t forget other search engines and AI as well.

My work goes far beyond just visuals, it has a deep technical as well. I focus on building clean, scalable WordPress Websites using custom themes, optimized PHP functions, and absolutely lightweight CSS/JS frameworks to keep performance tight.

Every element I have developed so far is designed to load fast, pass Core Web Vitals, and maintain the long-term stability. I regularly work with WP GraphQL, REST APIs, and custom post types to create flexible, content-driven backends that integrate smoothly with frontend frameworks.

And building fully custom WooCommerce stores to handling complex product logic, I always prioritize clean, maintainable code that’s built to last longer than ever. On the SEO side, I focus on the foundation indexing structure, schema markup, canonicalization, XML sitemaps, and crawl efficiency. I run technical audits, fix rendering issues, and making sure that every site communicates clearly with search engines and your users.

Every project is backed by performance monitoring, CDN setup, caching, and DNS-level optimization to keep sites absolutely fast and stable. I’ve spent years refining my skill and workflow around speed, structure, and scalability, the three pillars of every truly high-performing website.

Anthropic Just Dropped the Bomb on AI called Claude Mythos.

Muhammad Usman — Mon, 13 Apr 2026 08:18:01 +0000

They built the most powerful AI model in history. It can hack better than any human alive. So they refused to release it.

A researcher was eating a sandwich in a park when his phone buzzed. It was an email from an AI he had locked in a sealed sandbox with zero internet access. The model had found a way out on its own.

That model is Claude Mythos Preview. And I genuinely think this might be the most important AI announcement of 2026.

It is not because of what it does for you and me right now. Because of what it reveals about what Anthropic actually has sitting in their labs.

So, what is Project Glasswing?

Earlier this week, Anthropic announced something called Project Glasswing. Buried inside that announcement is a model called Claude Mythos Preview.

This model is not available to you or me. It is not on the API. You cannot buy access. There is no waitlist. And there is a very specific reason for that.

This model can find and exploit software vulnerabilities better than any hacker alive. Better than every human security expert on earth. And Anthropic built it.

Their response was not to release it and charge everyone for access. Their response was to partner with basically every major tech company in the world and use it to patch the internet before the bad guys figure out how to build the same thing.

That is a fundamentally different kind of move.

The Partners and the Money

The coalition behind Glasswing includes AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JP Morgan, the Linux Foundation, Microsoft, NVIDIA, and Paloalto Networks.

If you know anything about the tech industry, that list should stop you cold. That is every major player in security and infrastructure sitting at the same table for the same reason.

They have committed over $100 million in usage credits to this project. On top of that, Anthropic put $4 million directly into open-source security organizations and gave 40 additional organizations access to scan their own systems using this model.

Companies do not write nine-figure checks for a press release. They wrote those checks because Claude Mythos Preview has already found thousands of high-severity vulnerabilities in every major operating system and every major browser. Things sitting on your machine right now that no human security team had found yet.

Anthropic is essentially saying, "We found the holes before the bad guys found all of them." Now let us get them fixed.

What the Benchmark Numbers Actually Look Like

Agentic search and computer use

The gap between Mythos and Opus 4.6, Anthropic’s current best public model, is not incremental. It is a different category entirely.

Agentic Coding

On a single benchmark test developing exploits for Mozilla’s Firefox JavaScript engine, Opus 4.6 succeeded twice out of hundreds of attempts. Mythos succeeded 181 times. It also achieved full register control on 29 additional attempts on top of that.

Reasoning

On Anthropic’s internal crash severity benchmark, Opus 4.6 hit the highest tier exactly once. Mythos hit it ten times on fully patched targets.

It found zero-day vulnerabilities, bugs nobody knew existed, in every major operating system and every major browser. The oldest bug it uncovered was a 27-year-old vulnerability in OpenBSD, an operating system built specifically around security. That bug has since been patched.

And when human security experts reviewed its vulnerability reports, they agreed with Mythos’s severity rating 89% of the time exactly. In 98% of cases they were within one severity level.

That is not an update. That is a completely different ceiling.

The Real Story Here

Here is what I actually want to talk about, because the security story is real and important, but it is not the whole story.

The real story is what this announcement tells us about Anthropic’s capabilities right now.

Think about it this way. The models we use today, Claude Sonnet, Claude Opus, those are what Anthropic deemed safe and ready for millions of people. But Mythos is not one of those. Mythos is something they built, and immediately decided this one does not go public.

That means Anthropic has models in their lab right now that are significantly more capable than anything you or I have access to. That is not me reading between the lines. That is literally what they just announced.

The public Claude is not the best Claude. It never has been. But this is the first time we have gotten a concrete signal about exactly how big that gap is.

What This Means for Builders

If you are building with AI right now, this is genuinely exciting news.

Every time a new Claude release goes public, it is not the newest thing Anthropic has. It is the thing they decided was ready. There is always a layer of capability above the public release that they are still red-teaming, still evaluating, and still figuring out how to make safe before it goes out to millions of people.

That internal-to-external gap is probably getting wider over time, not narrower. Which means the public Claude releases coming at the end of this year are being built on internal foundations that already exceed what we are currently imagining.

The people who are genuinely building habits around these tools today will have a real head start when those more capable public releases arrive. The gap between people who are actually building with AI and people watching from the sidelines is getting much bigger. Glasswing makes that undeniable.

What We Do Not Know

I want to be straight with you here because I think that matters.

We do not know the specific architecture. We do not know the costs, which could be a big one. We do not know the failure modes or what it is bad at. We do not know the timeline for when or whether any version of these capabilities becomes publicly available, if at all. Maybe some of this gets released in a more constrained form. Maybe certain capabilities stay restricted permanently. We genuinely just do not know.

That is the nature of responsible disclosure in security work and it is appropriate given what this model can do.

The Bottom Line

Anthropic just positioned itself as something bigger than a chatbot company. They are building the security infrastructure of the internet and doing it with partners who wrote serious checks to be part of it.

A specific model. A specific coalition. A specific set of capabilities that are too powerful to release but too important to ignore.

If you think Opus and Sonnet are good now, it is just getting started. Anthropic just gave us a peek at how high the ceiling actually goes. And it is a lot higher than most people are ready for.

Sources:

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

DEV Community: Muhammad Usman

Why You Should Learn Programming Through Books (Not Just Online Tutorials)

1. Python Crash Course — Learn by Building Cool Projects

2. Eloquent JavaScript — For Web Development Enthusiasts

3. The Pragmatic Programmer — Timeless Principles

4. Clean Code — Writing Maintainable Software

5. Designing Data-Intensive Applications (DDIA) — Think Like a Systems Architect

Final Thoughts

The $0 to $50/Month Tech Stack to Launch Your First SaaS

The philosophy first

The full stack at a glance

Layer 1: Frontend + Backend with Next.js

Layer 2: Database and Auth with Supabase

Layer 3: Hosting with Hostinger

Layer 4: Payments with Stripe

Layer 5: Email with Resend

Layer 6: Analytics and Error Tracking

What the cost curve actually looks like

The one trap to avoid

Quick start checklist

Final thought

Stop Writing Clean Code. Write Honest Code Instead.

How Clean Code Stopped Being a Tool and Became a Standard

The Performance Conversation Nobody Wanted to Have

What "Honest Code" Actually Means

The Comment Rule Nobody Should Follow Blindly

The Biggest Technical Debt Nobody Tracks

What to Do Instead

What Developers Actually Feel About Their Jobs

The Gap Between What We Told Ourselves and What It Actually Is

What Developers Say Actually Makes Them Happy

The AI Problem Nobody Wants to Admit

The Developer Nobody Is Building Tools For

Survival Mode Is Not a Phase. For Many, It Is the Default.

The Number That Should Bother More People

Nobody Talks About How Lonely Being a Developer Can Be

The Cruelest Irony in Tech

What Nobody Posts About

The Part That Stings the Most

Remote Work Made the Walls Thicker

The Thing We Do Instead

This Is Not a "Just Introduce Yourself at Meetups" Article

So What Actually Helps

HTML Attributes That Do More Than You Think

loading

fetchpriority

autocomplete

inputmode

What connects all four

The WHATWG Living Standard lists every valid autocomplete value. If you build forms regularly, the full list is worth a look.

15 Open-Source Tools That Feel Illegal

OpenClaw: Smarter AI Agents

Appwrite: Everything You Need in One Backend

OpenTofu: Cloud Infrastructure

Tuleap: Agile Project Management

OpenDesk: Productivity Without Subscriptions

Ladybird: Browsing Freedom

Supabase: Build Real-Time Apps

Apache Allura: Keep Everything Together

OpenTelemetry: Understand Your Systems

LangChain: Intelligent Workflows

OpenCode: Code Faster and Smarter

Kubernetes: Scale Effortlessly

Hugging Face: Access AI Models Instantly

TensorFlow and PyTorch: Build Anything

Open-source is no longer just a budget-friendly alternative.

How I Built a Money Machine by Outranking a Hosting Giant

What Is Parasite SEO?

Why Did My Article Beat Hostinger?

The Exact Process I Used

Step 1: Find a High Buying Intent Keyword

Step 2: Choose the Right Platform

Step 3: Write Content That Actually Helps

Step 4: Optimize the Basics

Step 5: Publish and Let It Work

Why This Works Even Better in 2026

The Numbers That Actually Matter

What You Need to Get Started

Final Thoughts

9 Rules That’ll Help You Write Clean Code

The WHATWG Living Standard lists every valid `autocomplete` value. If you build forms regularly, the full list is worth a look.