DEV Community: Humayun Kabir

A Practical Blogging Strategy for Software Engineers Who Want to Be Seen

Humayun Kabir — Thu, 30 Oct 2025 15:58:11 +0000

Most engineers want more visibility.
They want better opportunities, stronger networks, interesting people to collaborate with, and an audience to share ideas with.

But almost nobody publishes.
Not because they can’t write — but because they underestimate the value of sharing their experiences.

Here’s a practical approach to becoming visible in the engineering community without becoming a “content creator” caricature.

1. Write About Real Problems You’ve Faced

Tutorials are everywhere. Your unique experience isn’t.

Write about:

decisions that didn’t age well
production incidents
process failures
gaps in documentation
weird edge cases
cultural or communication friction

When you talk about how and why things broke in the real world, people listen.

2. Keep a Friction Log

Throughout the week, capture tiny frustrations:

confusing toolchains
vague error messages
flaky pipelines
messy abstractions

Each entry is a potential post.
You’re not inventing ideas — you’re documenting where reality rubbed against expectation.

3. Add Context

The best engineering content explains the environment.

Tell readers:

the constraints
the deadlines
the team size
the trade-offs

Context turns ordinary lessons into useful ones.

4. Publish in One Place, Distribute in Several

Your long-form post lives on Substack.
That’s where you build a home.

Then you extract:

a short LinkedIn post with the core insight
a dev.to version with a code snippet or technical variation
a small thread on X breaking down the conclusion

One idea becomes multiple touch points.
Repetition builds recognition.

5. Develop Themes

Engineers should know what you “stand for.”
Pick four or five recurring themes such as:

architecture trade-offs
developer productivity
building and shipping SaaS products
AI tooling in everyday workflows
team dynamics and communication

Patterns create identity.

6. Publish at a Sustainable Cadence

One solid article a week is enough to grow.
Add two short posts on LinkedIn or X if you can.

Consistency beats intensity.

Engineers respect long-term thinkers.

7. Have Opinions

It’s easy to write safe content.
It’s forgettable.

You don’t have to be loud or provocative.
Just be honest.

Say what you learned, where you disagree, and what you’d do differently next time.

People follow clarity, not neutrality.

8. Engage With the Community

Comment on other posts, respond thoughtfully, ask questions, share someone else’s article.

Publishing without engaging is broadcasting into the void.

Visibility is social.

9. Build a Library

Over time, group posts into categories:

scaling lessons
debugging patterns
cultural pain points
productivity systems

architecture stories

Each category becomes a reference.

That’s how readers start saying:
“I go to this person when I need clarity on X.”

10. Focus on Clarity, Not Perfection

Good writing has:

simple sentences
direct claims
clean structure

Cut jargon.
Cut filler.
Cut disclaimers.

Publishing teaches clarity.

The Real Benefit

You won’t just get views.
You’ll get:

better job conversations
invitations to speak or collaborate
early adopters for side projects
consulting leads
a network that opens doors

Writing compounds.

The earlier you start, the sooner it pays off.

Final Thought

Don’t wait until you feel “experienced enough.”
Publishing is how you sharpen your thinking and find your audience.

Engineers who write become more valuable than engineers who don’t.

Start with one post.
You’ll figure out the rest along the way.

🧑‍💻 How I Manage Multiple GitHub Accounts on One Computer (Without Losing My Mind)

Humayun Kabir — Tue, 01 Jul 2025 08:02:54 +0000

If you’ve ever juggled more than one GitHub account — say, one for work and one for personal projects — you’ve probably hit that annoying wall: Git doesn’t know which identity to use, SSH keys get mixed up, and suddenly you're pushing company code from your personal account.

I ran into this too, and after way too much trial and error, I found a setup that just works. If you’re looking for a clean, reliable way to handle multiple GitHub accounts on the same machine — with the right user name, email, and SSH key for each — this guide is for you.

🧩 The Problem

You have multiple GitHub accounts
Git and SSH don’t know which one to use
You accidentally commit code from the wrong identity
Or worse, push to the wrong repo and get permission errors

Yeah. Not fun.

✅ The Goal

Use separate SSH keys for each GitHub account
Automatically use the correct Git user name and email for each project
Avoid switching configs manually every time

Let’s break it down.

🔐 Step 1: Create a Separate SSH Key for Each GitHub Account

We’ll create one key for your personal account and one for work.

Open your terminal and run:

# Personal account key
ssh-keygen -t ed25519 -C "your_personal@email.com" -f ~/.ssh/id_ed25519_personal

# Work account key
ssh-keygen -t ed25519 -C "your_work@email.com" -f ~/.ssh/id_ed25519_work

This will create two key pairs:

~/.ssh/id_ed25519_personal and id_ed25519_personal.pub
~/.ssh/id_ed25519_work and id_ed25519_work.pub

🔗 Step 2: Add Your Keys to GitHub

For each account, copy the public key and add it to GitHub:

cat ~/.ssh/id_ed25519_personal.pub

Then:

Go to GitHub.com > Settings > SSH and GPG keys
Click New SSH key, give it a name, and paste the key

Repeat the same for your work account using the id_ed25519_work.pub key.

⚙️ Step 3: Configure SSH to Know Which Key to Use

Now let’s tell SSH which key goes with which GitHub account.

Edit (or create) your SSH config file:

nano ~/.ssh/config

And add this:

# Personal GitHub
Host personal.github.com
    HostName ssh.github.com
    User git
    Port 443
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

# Work GitHub
Host work.github.com
    HostName ssh.github.com
    User git
    Port 443
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

Here’s the trick: you’re telling SSH that anytime it sees personal.github.com, it should use your personal key, and for work.github.com, your work key.

🧪 Step 4: Clone Repos Using the Right Host

Here’s where that custom Host comes in.

Instead of the usual GitHub URL, clone like this:

# For personal projects
git clone git@personal.github.com:yourusername/repo.git

# For work projects
git clone git@work.github.com:yourcompany/repo.git

It might feel weird at first, but this is how SSH knows which key to use. No more key conflicts!

👤 Step 5: Automatically Use the Right Git User Info

Okay, this part was a game-changer for me.

You know how Git uses your name and email in every commit? If you don't set it correctly, your commits might show up under the wrong GitHub account.

You could set it manually for each repo with:

git config user.name "Your Name"
git config user.email "you@example.com"

But... that gets old fast. Instead, let’s make Git smart enough to pick the right user based on the folder your repo lives in.

1. Open your global Git config:

nano ~/.gitconfig

2. Add these lines:

[includeIf "gitdir:~/projects/personal/"]
    path = ~/.gitconfig-personal

[includeIf "gitdir:~/projects/work/"]
    path = ~/.gitconfig-work

This tells Git: “Hey, if I’m working in any folder under ~/projects/personal, use the personal config. If I’m in ~/projects/work, use the work one.”

3. Create the two config files:

~/.gitconfig-personal

[user]
    name = Your Personal Name
    email = your_personal@email.com

~/.gitconfig-work

[user]
    name = Your Work Name
    email = your_work@email.com

4. Organize Your Projects

Put your repos into folders like:

~/projects/personal/my-website
~/projects/work/client-dashboard

Now Git will automatically use the right name and email when you commit — no extra commands needed.

🧼 That’s It!

Now you can:

Push to multiple GitHub accounts using different keys
Keep work and personal commits separate
Avoid annoying identity issues forever

🛠 Bonus Tips

Run git config user.name inside a repo to double-check which identity it’s using.

Run ssh -T git@personal.github.com to test if your SSH key works.
Keep all your SSH keys safe and backed up.

☕ Wrapping Up

This setup might seem like a lot up front, but once it’s in place, it just works. No more errors, no more misattributed commits, and no more mental juggling.

Hope this helped you clean up your GitHub life! If you’ve got questions, drop a comment — or if you’ve got tips of your own, I’d love to hear them.