DEV Community: Sameer Qaiser

Python APIs: Making HTTP Requests for Beginners

Sameer Qaiser — Fri, 02 Oct 2026 15:17:29 +0000

📌 Quick Info

Topic: Making HTTP requests in Python
Target Audience: Beginners who know functions and JSON
Goal: Understand how to fetch data from the internet with Python

1. Introduction

"Every app I used was pulling data from somewhere. Weather apps, social media, online stores — they all talk to servers. Then I learned about APIs and HTTP requests, and I could finally build programs that talk to the internet."

2. What Is an API?

An API (Application Programming Interface) is a way for two programs to talk to each other.

When you open a weather app, it doesn't know the weather itself. It asks a server: "What's the weather in Karachi?" The server responds with data. That's an API.

Think of it as a waiter in a restaurant — you don't walk into the kitchen. You tell the waiter what you want. The waiter brings it back.

3. The Problem (Without APIs)

Imagine trying to get the weather manually:

Open a browser
Go to a weather site
Read the temperature
Copy it down
Repeat every hour

Not scalable. Not automatable. You need a way for code to ask for data directly.

4. The Solution (Using `requests`)

import requests

response = requests.get("<https://api.github.com/users/torvalds>")
data = response.json()

print(data["name"])
print(data["public_repos"])

Output:

Linus Torvalds
100+

You just fetched live data from Github’s API in 4 lines.

5. How It Works (Line By Line)

Line 1: import requests — Loads the requests library (you may need to install it first with pip install requests).
Line 3: requests.get(url) — Sends an HTTP GET request to the URL.
Line 4: .json() — Converts the response to a Python dictionary.
Line 6: data["name"] — Accesses a specific field.

6. HTTP Status Codes

The server always tells you what happened:

Code	Meaning
200	OK- everything worked
404	Not Found- The URL doesn't exist
403	Forbidden- you don’t have access
500	Server error- the server broke

Always check the status code:

if response.status_code == 200:
    data = response.json()
else:
    print(f"Error: {response.status_code}")

7. Real Example (Weather API)

import requests

url = "https://api.open-meteo.com/v1/forecast"
params = {
    "latitude": 24.86,
    "longitude": 67.01,
    "current_weather": True
}

response = requests.get(url, params=params)
data = response.json()

print(f"Temperature: {data['current_weather']['temperature']}°C")

Output:

Temperature: 32.4°C

8. Common Mistakes Beginners Make

Mistake 1: Not installing requests

pip install requests

Mistake 2: Forgetting .json()

response is not the data — it's the response object. You need .json() to get the actual content.

Mistake 3: Not handling errors

Networks fail. URLs break. Always check status_code.

Mistake 4: Hardcoding API keys

If an API needs a key, store it in an environment variable, not in your code.

9. What I learned

APIs let your code talk to the internet
requests.get() sends a request
.json() turns the response into a Python dictionary
Status codes tell you what happened
Always handle errors — networks are not reliable

10. Conclusion

"APIs felt like magic when I first used one. Now they're just... tools. Small pieces of code that fetch data and give me back a dictionary. Once you build your first API call, you'll want to build twenty more.”

How I'd Learn Python from Scratch (If I Started Today)

Sameer Qaiser — Thu, 01 Oct 2026 07:58:05 +0000

📌 Quick Info

Topic: A beginner-friendly roadmap for learning Python
Target Audience: Anyone starting from zero
Goal: Give a clear, honest roadmap based on real experience

1. Introduction

"I started learning Python three weeks ago. I've published 17 articles about it. If I had to start over today, here's exactly what I'd do differently."

2. Week 1: The Absolute Basics

Don't skip these. No matter how boring they seem.

Variables and data types (int, str, float, bool)
print() and input()
if / elif / else
for and while loops

What I'd do: Write one tiny program each day. Not tutorials. Programs.

Examples:

A calculator that adds two numbers
A script that asks your name and greets you
A loop that prints numbers 1 to 10

What I'd skip: Installing 10 libraries you don't need yet.

3. Week 2: Data Structures

Lists
Dictionaries
Sets and tuples

What I'd do: Build a small contact book. Store names and phone numbers in a dictionary. Add, look up, delete.

Why it matters: Data structures are how you organize information. Every real program uses them.

What I'd skip: Advanced list comprehensions. You don't need them yet.

4. Week 3: Functions and Files

Writing your own functions (def)
Reading and writing files
Error handling (try / except)

What I'd do: Build a to-do list that saves to a file. It should load existing todos when the program starts.

Why it matters: Functions keep your code organized. Files let your programs remember things.

5. Week 4: Real Projects

Now you're ready to build something real.

Project ideas:

A weather app (uses an API)
A password generator
A budget tracker that saves to JSON
A simple web scraper

What I'd do: Pick one. Finish it. Publish it on GitHub.

Why it matters: Nobody cares what you know. They care what you've built.

6. What I'd Do Differently

1. I'd write about it sooner.
Writing about what I learn taught me more than reading about it. Every tutorial I published forced me to understand the concept deeply.

2. I'd stop waiting to feel ready.
You'll never feel ready. The first article was terrifying. The 17th was routine.

3. I'd ask for help earlier.
Struggling alone isn't noble. It's slow. Ask questions on Stack Overflow or Dev.to.

4. I'd focus on depth, not speed.
One concept understood beats five concepts skimmed.

7. What Actually Matters

Here's the truth: the language doesn't matter as much as the habit.

Python is a tool. Consistency is the skill.

If you show up every day — even for 30 minutes — you'll learn more in a month than someone who binges tutorials on weekends and forgets everything by Tuesday.

8. Conclusion

"If I started over today, I'd learn less and build more. I'd ship imperfect things. I'd ask for help sooner. And I'd write about everything — because the writing is what made it stick."

What I've Learned from Pitching 7 Companies (And Getting 0 Replies)

Sameer Qaiser — Thu, 01 Oct 2026 07:51:19 +0000

📌 Quick Info

Topic: The reality of pitching companies as a beginner writer
Target Audience: Anyone trying to break into writing, freelancing, or any creative field
Goal: Show that the silence is normal, not a verdict on your work

1. Introduction

"Over the past two weeks, I've sent pitches to 7 companies that pay for technical writing. I've followed up with 5 of them. So far, I've received zero replies. Here's what I've learned."

2. The Numbers

Metric	Count
Companies pitched	7
Follow-ups sent	5
Closed doors (not accepting)	4
No reply yet	3
Positive replies	0

That last number stings. But let me explain why I'm not panicking.

3. What Actually Happened

Some pitches died immediately:

One company said "not currently seeking authors"
Another's submission form only had options for Elixir, Ruby, and JavaScript — no Python
A third required a paid subscription just to submit

The rest were sent into the void. No "we received your pitch." No timeline. Just silence.

4. The Honest Part

Here's what nobody tells you about pitching:

Silence is normal. Editors get hundreds of pitches. Yours is one of them.
No response isn't a rejection. It's just... nothing. Yet.
The waiting is harder than the writing. Writing takes an hour. Waiting takes weeks.

I checked my inbox every day for the first week. Then every other day. Now I check twice a week, because refreshing doesn't change anything.

5. What I Got Right

Looking back, my pitches were solid:

I picked companies that actually pay
I sent real writing samples
I followed up professionally, not desperately
I tracked everything in a spreadsheet
I didn't lie about my experience

The pitches weren't the problem. The volume was. Seven pitches is not a lot. Seven is what you send before you understand the game.

6. What I'd Do Differently

Pitch more companies. Ten isn't enough. Fifty is barely enough.
Start smaller. Big publications are harder to get into than smaller ones with the same pay.
Pitch companies nobody's heard of. DevTool startups need content too.
Follow up one more time. After two weeks of silence, one more nudge is fine.
Don't wait to write. Keep publishing while pitches sit in inboxes.

7. The Part That Keeps Me Going

I published 16 articles while waiting for replies. That's 16 pieces of proof that I can write. Every one of them makes the next pitch stronger.

The companies that said no? They might say yes in six months. The companies that ignored me? They might reply next week. I don't know.

What I do know is this: the only way I lose is if I stop pitching.

8. If You're in the Same Spot

You will send pitches that get ignored. You will follow up and hear nothing. You will wonder if you're wasting your time.

You're not.

Every "no" is data. Every silence is a chance to keep working. The people who eventually get paid aren't the ones who pitched once and got lucky — they're the ones who kept pitching while everyone else quit.

9. Conclusion

"Zero replies doesn't mean zero chances. It means the story isn't finished yet. I'll let you know when it is."

Python Virtual Environments: What They Are and Why You Need Them

Sameer Qaiser — Wed, 30 Sep 2026 07:55:38 +0000

📌 Quick Info

Topic: Virtual environments in Python
Target Audience: Beginners who've installed packages with pip and hit problems
Goal: Understand why virtual environments exist and how to use one

1. Introduction

"For my first two weeks of Python, I installed every package globally. Then I had two projects that needed two different versions of the same library — and everything broke. That's when I learned about virtual environments."

2. The Problem (Installing Everything Globally)

pip install requests
pip install flask
pip install pandas

Every package goes into your global Python installation.

Problem: Project A needs requests==2.28, but Project B needs requests==2.31. You can only have one version installed globally. One project breaks.

3. The Solution (A Virtual Environment Per Project)

cd my_project

python -m venv venv

venv\Scripts\activate

source venv/bin/activate

pip install requests

Now every project has its own isolated set of packages.

4. How It Works

A virtual environment is just a folder (venv/) that contains:

Its own copy of Python
Its own pip
Its own list of installed packages

When you "activate" it, your terminal points to that folder instead of the global Python.

Nothing you install inside can affect other projects.

5. What You’ll See When It’s Active

After activating, your terminal prompt changes:

(venv) C:\Users\You\my_project>

That (venv) prefix means the environment is active. If you don't see it, you're using the global python.

6. Real Examples (Two Projects, Two Versions)

cd project_a
python -m venv venv
source venv/bin/activate
pip install requests==2.28

cd ../project_b
python -m venv venv
source venv/bin/activate
pip install requests==2.31

Now both projects have the version they need. No conflict.

7. Saving Your Dependencies

When you finish a project, save what you installed:

pip freeze > requirements.txt

Later, on a new machine, restore everything with

pip install -r requirements.txt

That’s how python projects share exact package versions.

8. Deactivating and Deleting

To deactivate:

deactivate

To Delete: Just delete the venv/ folder. That's it. Nothing is left behind.

9. Common Mistakes Beginners Make

Mistake 1: Forgetting to activate

You install a package thinking you're in the environment, but you're not.
Check for (venv) in your prompt.

Mistake 2: Committing venv/ to Git

Add venv/ to your .gitignore.
It's huge and not meant to be committed.
Commit requirements.txt instead.

Mistake 3: Creating the environment in the wrong folder

Always cd into your project first.
Then run python -m venv venv.

10. What I learned

Virtual environments isolate packages per project
python -m venv venv creates one
Activate it before installing anything with pip
(venv) in your prompt means it's active
pip freeze > requirements.txt saves your dependencies
Always add venv/ to your .gitignore

11. Conclusion

"Virtual environments felt like extra steps for no reason — until the day two projects broke each other. Now I create one for every project, every time. It's five seconds of setup for hours of saved debugging.”

Python JSON: Working with Data Files

Sameer Qaiser — Mon, 28 Sep 2026 08:09:13 +0000

📌 Quick Info

Topic: Working with JSON in Python
Target Audience: Beginners who know files and dictionaries
Goal: Understand how to save and load structured data

1. Introduction

"I could write text to a file. But what if I needed to save a whole dictionary? A list of users? A config file? That's when I learned about JSON — and now it's how every one of my projects saves data."

2. The Problem (Saving Complex Data to a Text File)

user = {"name": "Ali", "age": 25, "city": "Karachi"}

with open("user.txt", "w") as file:
    file.write(str(user))

What’s in the file:

{'name': 'Ali', 'age': 25, 'city': 'Karachi'}

Problem: It’s ugly. It’s not standard. Other programs can’t read it easily.

3. The Solution (JSON)

import json

user = {"name": "Ali", "age": 25, "city": "Karachi"}

with open("user.json", "w") as file:
    json.dump(user, file)

What’s in the file:

{"name": "Ali", "age": 25, "city": "Karachi"}

Clean. Standard. Readable by almost any language.

4. Reading JSON Back

import json

with open("user.json", "r") as file:
    user = json.load(file)

print(user["name"])   # Ali
print(user["age"])    # 25

The Dictionary comes back exactly as it was saved.

5. How It Works (Line By Line)

import json — Loads Python’s built-in JSON module.

json.dump(data, file) — Writes a Python object to a file as JSON.

json.load(file) — Reads JSON from a file back into a Python object.

json.dumps(data) — Converts a Python object to a JSON string (instead of writing to a file).

json.loads(string) — Parses a JSON string into Python.

6. JSON vs Python: What Maps to What

Python	JSON
dict	Object
List	Array
str	string
int/ float	number
True / False	true / false
None	null

The names are different, but the structure is the same.

7. Real Example (My Practice)

import json

users = [
    {"name": "Ali", "score": 85},
    {"name": "Sara", "score": 92},
    {"name": "Ahmed", "score": 78}
]

with open("scores.json", "w") as file:
    json.dump(users, file, indent=2)

with open("scores.json", "r") as file:
    loaded = json.load(file)

for user in loaded:
    print(f"{user['name']}: {user['score']}")

Output:

Ali: 85
Sara: 92
Ahmed: 78

The indent=2 makes the file human-readable.

8. Common Mistakes Beginners Make

Mistake 1: Forgetting to import json

json.dump(...)

Mistake 2: Confusing dump and dumps

json.dump(): writes to a file
json.dumps(): returns a string

Mistake 3: Trying to save non-JSON types

import json
json.dumps({"date": datetime.now()})

JSON only supports basic types. Convert to strings first.

9. What I learned

-) JSON is the standard for saving structured data
-) json.dump() writes to a file, json.load() reads from it
-) json.dumps() and json.loads() work with strings
-) indent=2 makes files human-readable
-) Not everything can be saved — only dicts, lists, strings, numbers, booleans, and None

10. Conclusion

“JSON solved a problem I didn't know I had. Now every project I build saves its data as JSON — because it's readable, portable, and just works. Once you learn it, you'll never go back to saving dictionaries as text.”

Python Classes: A Beginner's Guide to OOP

Sameer Qaiser — Sun, 27 Sep 2026 08:58:31 +0000

📌 Quick Info

Topic: Classes and objects in Python
Target Audience: Beginners who know functions and dictionaries
Goal: Understand why classes exist and how to write one

1. Introduction

"For weeks, I stored everything in dictionaries. Then I had 10 players in a game, each with a name, score, and level — and I had to update all of them manually. That's when I learned about classes."

2. The Problem (Using Dictionaries for Everything)

player1 = {"name": "Ali", "score": 0, "level": 1}
player2 = {"name": "Sara", "score": 0, "level": 1}
player3 = {"name": "Ahmed", "score": 0, "level": 1}

def add_score(player, points):
    player["score"] += points

add_score(player1, 10)
print(player1["score"])  # 10

Problem: Every player is a plain dictionary. No structure. Easy to typo. Hard to scale.

3. The Solution (With Classes)

lass Player:
    def _init_(self, name):
        self.name = name
        self.score = 0
        self.level = 1

    def add_score(self, points):
        self.score += points

player1 = Player("Ali")
player2 = Player("Sara")

player1.add_score(10)
print(player1.score)   
print(player2.score)

Every Player is now a Player object with its own data and its own methods.

4. How It Works (Line By Line)

Line 1: class Player: — Defines a new class called Player.

Line 2: def init(self, name): — This runs automatically when you create a new player. It's called the constructor.

Line 3-5: self.name = name — Stores data on the object. self refers to the specific instance.

Line 7: def add_score(self, points): — A method that belongs to the class.

Line 11: player1 = Player("Ali") — Creates an instance (an object) of the class.

5. What is self?

self is how Python knows which player you're talking about.

When you write player1.add_score(10), Python translates it to:

Player.add_score(player1, 10)

So self = player1 in that call. It's the object the method was called on.

Rule: Every method inside a class takes self as its first parameter. No exceptions.

6. Real Example (My Practice)

class BankAccount:
    def __init__(self, owner, balance=0):
        self.owner = owner
        self.balance = balance

    def deposit(self, amount):
        self.balance += amount

    def withdraw(self, amount):
        if amount > self.balance:
            print("Insufficient funds.")
        else:
            self.balance -= amount

    def show_balance(self):
        print(f"{self.owner}: ${self.balance}")

account = BankAccount("Ali", 100)
account.deposit(50)
account.withdraw(30)
account.show_balance()

Output:

Ali: $120

7. Class vs Instance

class Dog:
    species = "Canis familiaris"  

    def __init__(self, name):
        self.name = name          

dog1 = Dog("Rex")
dog2 = Dog("Max")

print(dog1.species)   
print(dog2.species)   
print(dog1.name)      
print(dog2.name)

Class attribute = shared by every instance.
Instance attribute = unique to each instance.

8. What I learned

· Classes bundle data and behavior together
· —init— runs when you create a new instance
· Self is how methods know which instance they belong to
· Class attributes are shared, instance attributes are unique
· Classes make code easier to scale when you have many similar things

9. Conclusion

"Classes felt like overkill when I had one player. But when I had ten, they saved me hours. Now I reach for classes whenever I have multiple things with the same shape — because managing them manually is how bugs get born."

What Nobody Tells You About Writing Online!

Sameer Qaiser — Sat, 26 Sep 2026 16:42:14 +0000

📌 Quick Info

Topic: The honest truth about starting to write online
Target Audience: Anyone thinking about writing publicly but hasn't started
Goal: Show what actually happens after you hit publish

1. Introduction

"Two weeks ago, I published my first article. Twelve articles later, here's what I wish someone had told me before I started."

2. The Advice You Always Hear

"Just start."

"Write every day."

"Share your work."

"Be consistent."

All of it is true. None of it is the full story.

3. What Nobody Tells You

Nobody tells you the first article takes 3 hours.
Not because you're slow. Because you're learning how to finish something. The second one takes 1 hour. The tenth takes 30 minutes. The speed comes from repetition, not talent.

Nobody tells you the fear doesn't go away.
Every single article I've published, I've had a moment where I almost didn't. The fear doesn't disappear — you just learn to act anyway.

Nobody tells you the silence is the hardest part.
Your first article might get 5 views. Your second might get 2. It's easy to think nobody cares — but the first 10 articles are for you. You're building a habit, not an audience.

Nobody tells you writing teaches you more than reading does.
I've learned more about Python from writing tutorials than from any course. When you have to explain something, you discover what you don't actually understand.

Nobody tells you the "post it later" trap.
There will always be a reason to wait. The draft isn't ready. The topic isn't perfect. You need to research more. You don't. Publish the imperfect version.

4. What Actually Happens After You Publish

Here's the honest version:

Nothing happens immediately. No flood of readers, no comments, no DMs.
A few people read it. Maybe one person likes it. That's still one person.
You feel weirdly exposed. Like you showed up to a party in the wrong outfit.
You check the stats way too often. Stop. It won't help.
You write the next one anyway. That's the only thing that matters.

5. The Real Reward

It's not views. It's not likes. It's not followers.

The real reward is you become the kind of person who finishes things. That identity — "I'm a writer" — changes how you see yourself. And it bleeds into everything else you do.

You stop saying "I want to write someday" and start saying "I wrote something yesterday."

That's the shift. That's what nobody tells you.

6. What I'd Tell Someone Starting Today

Publish before you're ready. Ready is a moving target.
Write about what you're learning. You don't need to be an expert.
Ignore the stats for the first 30 days. Focus on showing up.
Do it for yourself first. An audience is a side effect, not the goal.
Keep going when nobody's watching. That's the whole skill.

7. Conclusion

"Writing online isn't about being seen. It's about seeing yourself — you're thinking, your progress, your voice — for the first time. That's worth more than any number of views."

Python Files: Reading and Writing for Beginners

Sameer Qaiser — Fri, 25 Sep 2026 16:52:58 +0000

📌 Quick Info

Topic: Reading and writing files in Python
Target Audience: Beginners who know the basics but haven't worked with files yet
Goal: Understand how to save data to a file and read it back

1. Introduction

"For weeks, every Python program I wrote forgot everything the moment it closed. Then I learned how to work with files — and suddenly my programs could remember."

2. The Problem (Data Disappears)

name = input("What's your name? ")
print(f"Hello, {name}!")

Run it once, it works. Run it again tomorrow, it asks again.

The data disappears the moment the program ends. Nothing is saved.

3. The Solution (Writing to a File)

with open("names.txt", "w") as file:
    file.write("Ali\n")
    file.write("Sara\n")
    file.write("Ahmed\n")

print("Saved!")

What happens: A file called names.txt is created with three names.

4. Reading From a File

with open("names.txt", "r") as file:
    content = file.read()

print(content)

Output:

Ali
Sara
Ahmed

The data is still there — even after the program closed.

5. How It Works (Line by Line)

Line 1: with open("names.txt", "w") as file: — Opens the file in write mode ("w").

Line 2-4: file.write(...) — Writes each name, plus \n to start a new line.

The with keyword: Automatically closes the file when you're done. You don't have to remember to close it.

6. The Three File Modes

Mode	What It Does
“r”	Read only. Throws an error if the file doesn’t exist.
“w”	Write. Erases the file if it already exists.
“a”	Append. Adds to the end without erasing.

Warning: "w" overwrites everything. Use "a" if you want to keep existing content.

7. Real Example (My Practise)

with open("scores.txt", "a") as file:
    file.write("92\n")
    file.write("85\n")

with open("scores.txt", "r") as file:
    for line in file:
        print(line.strip())

Output:

92
85

line.strip() removes the extra newline character.

8. What I Learned

-) Files let data survive after the program ends
-) "r" reads, "w" writes (and erases), "a" appends
-) with open(...) handles closing for you — always use it
-) .strip() cleans up extra whitespace
-) Always check that a file exists before reading it.

9. Conclusion

"Files felt scary at first — I was worried I'd overwrite something important. But once I understood the three modes, files became one of the most useful tools in my Python toolbox. Programs that remember are programs people actually use."

Python Error Handling: try/except for Beginners

Sameer Qaiser — Thu, 24 Sep 2026 09:55:56 +0000

📌 Quick Info

Topic: Error handling in Python
Target Audience: Beginners who've seen error messages but don't know how to handle them
Goal: Stop being scared of errors and start handling them gracefully

1. Introduction

"The first time I saw a red error message in Python, I panicked. Now I read them like a map. Here's how I stopped being scared of errors — and started using try/except to handle them properly."

2. The Problem (When Code Crashes)

age = int(input("Enter your age: "))
print(f"You are {age} years old")

What happens if the user types “Twenty”?

ValueError:invalid literal for int() with base 10:'twenty'

The whole program crashes. One wrong input and everything stops.

3. The Solution (try/expect)

try:
    age = int(input("Enter your age: "))
    print(f"You are {age} years old")
except ValueError:
    print("Please enter a number, not text.")

Output (if user types “twenty”):

Please enter a number, not text.

The program keeps running. No Crash.

4. How It Works (Line by Line)

Line 1: try: — "Python, try running this code."

Line 2-3: The code that might fail.

Line 4: except ValueError: — "If a ValueError happens, do this instead."

Line 5: The fallback message.

If no error happens, the except block is skipped entirely.

5. Catching Multiple Errors

try:
    result = 10 / 0
except ZeroDivisionError:
    print("You can't divide by zero.")
except TypeError:
    print("Wrong type of value.")

Output:

You can't divide by zero.

6. The finally Block

finally runs no matter what- error or no error:

try:
    file = open("data.txt", "r")
    content = file.read()
except FileNotFoundError:
    print("File not found.")
finally:
    print("Done trying to read the file.")

Output (if file missing):

File not found
Done trying to read the file.

Great for cleanup- closing files, releasing connections, etc.

7. Common Beginner Mistakes

Mistake 1: Catching everything

try:
  # any code
except:
    pass

This hides real bugs. Catch specific exceptions.

Mistake 2: Using an empty `except` block

except ValueError:
    pass  # silently ignores the error

At minimum, print or log something. Never swallow errors silently.

Mistake 3: Using `try/except` for control flow

Don’t wrap every line in try/except “just in case.” Only wrap code that might realistically fail.

8. Real Example (My Practise)

def get_number():
    while True:
        try:
            return int(input("Enter a number: "))
        except ValueError:
            print("That's not a number. Try again.")

number = get_number()
print(f"You entered: {number}")

Behavior: It keeps asking until the user types a valid number.

9. What I Learned

· Errors aren’t failures — they’re Python telling you what went wrong
· try/except lets your program recover instead of crashing
· Catch specific exceptions, not everything
· finally runs whether or not there’s an error
· Never silently swallow errors — always log or print something

10. Conclusion

"Error handling felt like extra work at first. Now I add it the same way I add comments — because I know future me will thank present me. A program that handles errors gracefully is a program people actually trust."

Why Every Developer Should Learn to Write

Sameer Qaiser — Thu, 24 Sep 2026 09:25:01 +0000

📌 Quick Info

Topic: Why writing is a developer skill
Target Audience: Developers who think writing isn't their job
Goal: Show that writing = thinking, and thinking = better code

1. Introduction

"I used to think writing was something 'other people' did. Then I started writing about code, and my code got better. Here's why."

2. The Assumption I Used to Have

For a long time, I thought writing and coding were two separate skills.

Coders write code. Writers write words. Different people. Different jobs.

I was wrong. And it took publishing 9 articles to see it.

3. What Writing Actually Does to Your Code

Writing forces clarity.
When you have to explain range(1, 6) to a beginner, you can't hand-wave. You have to actually know what it does, why it stops at 5, and where people get confused. Writing exposes the parts of your understanding that are still fuzzy.

Writing catches bugs before they ship.
Half the bugs I've found in my own code came from writing about it. When you explain line by line, you notice the missing edge case. You notice the variable name that doesn't match what it's doing.

Writing is thinking made visible.
If you can't explain it clearly, you don't understand it yet. Writing is the test.

4. The Developer Who Can't Write

Here's what happens when developers don't write:

Their PR descriptions are one line: "fix bug"
Their commit messages are "update"
Their documentation is out of date or missing
Their code reviews are vague: "this feels wrong"
Their interviews go badly because they can't explain their own work

None of those are coding problems. All of them are writing problems.

5. The Developer Who Can Write

Here's what happens when they do:

Their PRs get merged faster because reviewers understand the intent
Their commits tell a story
Their docs actually help the next person
Their code reviews lift the whole team
Their interviews go well because they can talk about their work
They get asked to write blog posts, give talks, and lead projects

Writing is a force multiplier on top of coding. It doesn't replace the skill — it amplifies it.

6. The AI Era Makes This More True

AI can write code now. It can't explain why the code matters.

The people who win in the AI era won't be the ones who type the most code. They'll be the ones who:

Understand what the code is supposed to do
Can explain it to non-engineers
Can write about decisions and trade-offs
Can document systems that other people need to maintain

All of those are writing skills.

7. What I'd Tell a Developer Who Hates Writing

You don't have to write blog posts. You don't have to publish articles.

But you should write:

Clear commit messages — future you will thank present you
Real PR descriptions — explain why, not just what
Documentation that isn't just autogenerated — add the "why"
Comments that explain decisions, not syntax

Start there. And if you find you enjoy it, write something public. Even one article changes how you see your own work.

8. Conclusion

"Writing didn't make me a worse developer. It made me a better one — because it forced me to actually understand what I was doing. Every developer should write. Not to become a writer. To become a better developer."

What 7 Articles in 7 Days Taught Me About Consistency

Sameer Qaiser — Wed, 23 Sep 2026 07:25:56 +0000

📌 Quick Info

Topic: What I learned from writing daily for a week
Target Audience: Anyone who wants to start writing but keeps waiting
Goal: Show that consistency beats motivation every time

1. Introduction

"Seven days ago, I decided to publish one article every day for a week. I didn't know if I'd make it to day three. Here's what actually happened."

2. The Challenge I Set for Myself

I'm a beginner. I started learning Python, started writing online, and then decided to do something that sounded crazy:

One article. Every day. For seven days.

No breaks. No "I'll do two tomorrow." Just show up, write, publish, repeat.

I gave myself three rules:

Publish before midnight
Don't skip a day
Don't obsess over perfection

3. What I Expected

I thought the hard part would be writing.

I thought I'd run out of ideas by day three. I thought the articles would get worse as I got tired. I thought I'd quit somewhere in the middle.

None of that happened — at least not the way I expected.

4. What Actually Happened

Day 1: Took 3 hours. Was terrified to hit publish.

Day 3: Took 1 hour. Started finding my rhythm.

Day 5: Took 45 minutes. The ideas were coming easier.

Day 7: Took 30 minutes. It felt normal.

The writing didn't get harder. It got easier. The only thing that changed was I stopped treating it like a big deal.

5. The 3 Lessons I Actually Learned

Lesson 1: Consistency beats motivation.
Motivation is a feeling. Consistency is a decision. On day 4, I didn't feel like writing. I wrote anyway. That's the whole game.

Lesson 2: Publish before perfect.
My first article took 3 hours because I kept rewriting it. My seventh took 30 minutes because I stopped polishing and just shipped. The seventh was better received than the first.

Lesson 3: Momentum compounds.
The first article felt impossible. The seventh felt routine. That gap — between impossible and routine — is what you get from showing up every day.

6. What I'd Tell Someone Starting

Don't wait for the perfect idea. Start with what you know.
Don't wait until you feel ready. You won't.
Don't aim for perfect. Aim for published.
Don't do it alone. Share your work, ask for feedback, keep going.

The hardest article is always the first one.

7. Conclusion

"I set out to write 7 articles. I ended up learning 7 lessons that have nothing to do with writing. The consistency was the point. The articles were just proof."

Why I Started Writing Online (And What I Was Afraid Of)

Sameer Qaiser — Sun, 20 Sep 2026 08:20:34 +0000

📌 Quick Info

Topic: Why I started writing online
Target Audience: Anyone thinking about starting but scared to
Goal: Show that starting is the hardest part — and it's worth it

1. Introduction

"A week ago, I published my first article on the internet. Today I have eight. Here's why I started — and what almost stopped me."

2. The Real Reason I Started

I didn't start writing online because I thought I was an expert.

I started because I was learning something and I wanted to remember it.

Every time I learned a new Python concept, I'd forget it a week later. Every time I figured out a bug, I'd hit the same bug three months later and have no idea how I fixed it.

Writing was my way of keeping what I learned.

But if I'm honest, there was another reason too. I wanted to see if I could do it.

3. What I Was Actually Afraid Of

I wasn't afraid of writing. I was afraid of being seen.

What if someone smarter than me reads this and laughs?
What if people think I'm pretending to be an expert?
What if I write something wrong and someone calls me out?

I sat on my first article for three days before publishing it.

Three days of staring at it, tweaking the title, rewriting the intro, telling myself "it's not ready yet."

It was ready. I wasn't.

4. What Actually Happened

I hit publish.

Then I waited for the comments. For the criticism. For someone to tell me I didn't belong.

Here's what actually happened:

Nobody was mean.
A few people read it.
One person said it helped them.

That's it. That's all.

The thing I was terrified of didn't happen. And the thing I hoped for — someone finding it useful — did.

5. What I Learned

The fear doesn't go away. You just act anyway.
Most people are kind. The ones who aren't were never your audience.
Writing is thinking. I understand Python better now because I have to explain it.
Momentum is real. The first article took 3 days to publish. The seventh took 30 minutes.

6. If You're Thinking About Starting

Start with something small. Start with something you're learning. Start before you feel ready.

You don't need permission. You don't need credentials. You don't need to be an expert.

You just need to be one step ahead of the person you're writing for.

That's it.

7. Conclusion

"I started writing because I wanted to remember what I learned. I kept writing because it changed how I learn. And I'm still writing because — for the first time — I feel like I'm actually building something."

DEV Community: Sameer Qaiser

Python APIs: Making HTTP Requests for Beginners

📌 Quick Info

1. Introduction

2. What Is an API?

3. The Problem (Without APIs)

4. The Solution (Using requests)

Output:

5. How It Works (Line By Line)

6. HTTP Status Codes

7. Real Example (Weather API)

Output:

8. Common Mistakes Beginners Make

9. What I learned

10. Conclusion

How I'd Learn Python from Scratch (If I Started Today)

📌 Quick Info

1. Introduction

2. Week 1: The Absolute Basics

3. Week 2: Data Structures

4. Week 3: Functions and Files

5. Week 4: Real Projects

6. What I'd Do Differently

7. What Actually Matters

8. Conclusion

What I've Learned from Pitching 7 Companies (And Getting 0 Replies)

📌 Quick Info

1. Introduction

2. The Numbers

3. What Actually Happened

4. The Honest Part

5. What I Got Right

6. What I'd Do Differently

7. The Part That Keeps Me Going

8. If You're in the Same Spot

9. Conclusion

Python Virtual Environments: What They Are and Why You Need Them

📌 Quick Info

1. Introduction

2. The Problem (Installing Everything Globally)

3. The Solution (A Virtual Environment Per Project)

4. How It Works

5. What You’ll See When It’s Active

6. Real Examples (Two Projects, Two Versions)

7. Saving Your Dependencies

8. Deactivating and Deleting

9. Common Mistakes Beginners Make

10. What I learned

11. Conclusion

Python JSON: Working with Data Files

📌 Quick Info

1. Introduction

2. The Problem (Saving Complex Data to a Text File)

3. The Solution (JSON)

4. Reading JSON Back

5. How It Works (Line By Line)

6. JSON vs Python: What Maps to What

7. Real Example (My Practice)

Output:

8. Common Mistakes Beginners Make

Mistake 1: Forgetting to import json

Mistake 2: Confusing dump and dumps

Mistake 3: Trying to save non-JSON types

9. What I learned

10. Conclusion

Python Classes: A Beginner's Guide to OOP

📌 Quick Info

1. Introduction

2. The Problem (Using Dictionaries for Everything)

3. The Solution (With Classes)

4. How It Works (Line By Line)

5. What is self?

6. Real Example (My Practice)

Output:

7. Class vs Instance

8. What I learned

9. Conclusion

What Nobody Tells You About Writing Online!

📌 Quick Info

1. Introduction

4. The Solution (Using `requests`)

Mistake 2: Using an empty `except` block

Mistake 3: Using `try/except` for control flow