Forem: Farhad Rahimi Klie

How I’d Become a Programmer in 2026 (If I Had to Start From Zero)

Farhad Rahimi Klie — Tue, 26 May 2026 05:30:49 +0000

Imagine this.

You wake up tomorrow and lose everything related to your programming journey.

No degree.
No experience.
No connections.
No audience.
No money.

Just you, a laptop, and internet access.

Could you still become a programmer in 2026?

My answer is yes.

Not because becoming a developer is easy, but because the path today is more accessible than ever before. The problem is not lack of information anymore. The real problem is overload.

Too many tutorials.
Too many opinions.
Too many frameworks.
Too many people telling beginners to learn everything at once.

If I had to restart from zero in 2026, this is exactly how I would do it.

Step 1: Stop Trying to Learn Everything

This is the first mistake almost every beginner makes.

They open YouTube and suddenly see:

“Learn Python”
“Become an AI Engineer”
“Learn Rust”
“Master Kubernetes”
“Become Full Stack in 30 Days”
“Top 10 Frameworks You Need”

And then they panic.

So they start 15 different courses and finish none of them.

Programming is not hard because of coding itself.
Programming is hard because beginners constantly switch directions.

If I started again, I would choose ONE path and ignore everything else for a while.

Focus creates progress.

Step 2: Learn the Fundamentals First

I would start with web development because it has:

low entry barriers
huge job opportunities
freelancing potential
endless learning resources

My beginner stack would look like this:

HTML
CSS
JavaScript
Git
React
Node.js

That’s it.

Not 20 languages.
Not 40 tools.

Just enough to become useful.

A lot of beginners underestimate fundamentals because they look “simple.” But strong fundamentals are what separate good developers from confused developers.

HTML teaches structure.
CSS teaches layout and design thinking.
JavaScript teaches logic and interactivity.

Everything builds on top of these.

Step 3: Forget Advanced Topics for the First Month

If I were a beginner again, I would completely avoid:

AI engineering
blockchain
microservices
DevOps complexity
system architecture

Not because these things are bad, but because they are distractions for beginners.

You do not learn programming by jumping into complexity immediately.

You learn programming by understanding simple things deeply.

Most people quit because they try to sprint through concepts they barely understand.

Your first month should simply focus on:

understanding variables
functions
loops
conditions
DOM manipulation
basic layouts
simple projects

That foundation matters more than people think.

Step 4: Code Every Single Day

This is probably the most important part.

Not motivation.
Not intelligence.
Not talent.

Consistency.

I’ve seen average programmers become amazing simply because they stayed consistent for years.

Meanwhile, talented people disappear because they stop practicing.

If I restarted in 2026, I would code daily even if it was only:

30 minutes
1 hour
2 hours

Small progress compounds massively over time.

Programming is a skill built through repetition.

You cannot watch your way into becoming a developer.

Step 5: Escape Tutorial Addiction Early

Tutorial addiction is one of the biggest hidden problems in tech.

You watch video after video after video and feel productive…

…but the moment you open an empty editor alone, your brain freezes.

Why?

Because watching is passive.
Building is active.

Tutorials should introduce concepts, not replace practice.

If I started again, I’d follow a very simple rule:

Learn something → build something with it immediately.

That single habit changes everything.

Step 6: Build Ugly Projects

This part is important.

Your first projects are supposed to look bad.

Seriously.

Most beginners quit because they compare their first project to applications built by senior engineers with 10 years of experience.

That comparison destroys confidence.

My first projects would probably include:

Calculator App
Todo App
Weather App
Notes App
Portfolio Website

Simple projects matter because they teach:

debugging
structure
persistence
problem-solving
project completion

Finishing projects is a superpower.

A lot of beginners start projects.
Very few finish them.

Step 7: Learn Git and GitHub Properly

In modern programming, coding is only part of the job.

Developers collaborate.
Track changes.
Deploy updates.
Manage versions.

That’s where Git and GitHub become essential.

If I restarted, I would learn:

commits
branches
pull requests
repositories
version control workflows

Because employers love proof.

A strong GitHub profile can sometimes speak louder than certificates.

Your projects become your resume.

Step 8: Learn How to Use AI Correctly

In 2026, AI will absolutely become part of programming workflows.

But there’s something important beginners misunderstand:

AI is a tool, not a replacement for thinking.

Good developers use AI to:

explain concepts
debug errors
optimize code
learn faster
generate ideas

Bad developers copy-paste code without understanding it.

That creates dependency instead of growth.

If I restarted today, I’d treat AI like a mentor — not a shortcut.

Because eventually you must understand what your code actually does.

Step 9: Focus on Problem-Solving

A lot of people think programming is about memorizing syntax.

It’s not.

Syntax is searchable.

The real skill is learning how to think logically.

That means learning how to:

break problems into smaller pieces
debug systematically
analyze behavior
think step-by-step

This is why problem-solving platforms can help beginners improve.

Not because interview questions are magical, but because they train your brain differently.

Programming is applied thinking.

Step 10: Learn Backend Development

Frontend development is a great start.

But backend development is where things begin to feel “real.”

That’s when you learn:

APIs
databases
authentication
servers
requests/responses
application logic

Suddenly you’re not just building interfaces anymore.

You’re building complete systems.

This stage is exciting because you finally understand how modern applications actually work behind the scenes.

Step 11: Learn SQL Early

SQL is massively underrated among beginners.

Many new developers focus only on frontend frameworks while ignoring databases completely.

But almost every serious application needs data storage.

Learning SQL teaches:

structured thinking
data relationships
querying
filtering
optimization

Even basic SQL knowledge makes you more valuable immediately.

And honestly?

SQL is one of the most practical skills in tech.

Step 12: Start Freelancing Before You Feel Ready

One of the best ways to grow fast is working on real problems.

Real clients teach lessons tutorials never can.

When real people use your software:

bugs matter
communication matters
deadlines matter
reliability matters

Your first freelance projects may pay very little.

That’s okay.

At the beginning, experience is more valuable than money.

You are building:

confidence
proof
communication skills
practical understanding

Every small project compounds.

Step 13: Build an Online Presence

This matters much more in 2026 than people realize.

Opportunities often come from visibility.

You do not need millions of followers.

You simply need to show your journey consistently.

I would post:

what I’m learning
projects I’m building
mistakes I fixed
lessons I discovered

Because people hire developers they can SEE.

The internet rewards visible builders.

Step 14: Accept That Progress Feels Slow

This is where many beginners quit.

The first year of programming can feel frustrating.

You forget syntax.
You get strange errors.
Nothing works sometimes.

That is normal.

Programming often feels difficult because your brain is learning an entirely new way of thinking.

But eventually something changes.

Concepts start connecting.
Debugging gets easier.
Projects feel less intimidating.

The confusion slowly becomes clarity.

Step 15: Understand the Real Secret

The biggest secret in programming is this:

Most successful developers are not geniuses.

They simply stayed consistent longer than everyone else.

That’s it.

They kept learning.
Kept building.
Kept failing.
Kept improving.

Programming rewards patience more than talent.

Small daily progress looks invisible at first…

…but after a few years, it completely changes your life.

Final Thoughts

If I had to restart from zero in 2026, I wouldn’t chase shortcuts.

I wouldn’t obsess over becoming “perfect.”

I’d focus on:

consistency
fundamentals
projects
problem-solving
patience

Because becoming a programmer is not one giant breakthrough moment.

It’s thousands of small steps repeated over time.

And eventually, one day, you realize:

The beginner who once struggled to print “Hello World” is now building real software.

That’s how the transformation happens. 🚀

Fastest Programming Languages in 2026: Speed, Performance, and Real-World Use Cases

Farhad Rahimi Klie — Tue, 19 May 2026 07:05:13 +0000

Programming languages are not equally fast.

Some languages are designed for raw hardware-level performance, while others focus on developer productivity, simplicity, safety, portability, or rapid development.

When developers talk about the “fastest programming language,” they are usually talking about:

Execution speed
Memory efficiency
CPU usage
Startup time
Latency
Throughput
Control over hardware
Compiler optimizations

But performance is more complicated than simply asking:

“Which language is the fastest?”

Because different workloads produce different results.

For example:

A language that is extremely fast for operating systems may not be the best for AI.
A language optimized for web applications may not perform best for embedded systems.
Some languages trade raw speed for safety.
Others trade safety for maximum hardware control.

In this article, we will deeply explore the fastest programming languages, how they achieve performance, where they are used, their advantages, disadvantages, and which one should be chosen for different types of projects.

What Makes a Programming Language Fast?

Before comparing languages, we must first understand what affects performance.

A programming language itself is not magically fast or slow.

Performance depends on many layers.

1. Compiler Quality

A good compiler can heavily optimize code.

Examples:

GCC
Clang/LLVM
MSVC
Rust Compiler

Compilers perform optimizations such as:

Dead code elimination
Loop unrolling
Inline expansion
Register allocation
Vectorization
Constant folding

A powerful compiler can dramatically improve performance.

2. Memory Management

Languages handle memory differently.

Manual Memory Management

Examples:

Developer controls memory directly.

Advantages:

Maximum speed
Fine-grained control
Minimal overhead

Disadvantages:

Memory leaks
Dangling pointers
Buffer overflows

Garbage Collection (GC)

Examples:

Java
Go
C#

The runtime automatically frees unused memory.

Advantages:

Easier development
Safer memory handling

Disadvantages:

GC pauses
Extra CPU overhead
Higher memory usage

3. Runtime Overhead

Some languages require heavy runtimes.

Examples:

JVM for Java
CLR for C#
Python Interpreter

Runtime systems add features like:

Memory management
Security
Reflection
Dynamic typing

But these also introduce overhead.

4. Abstraction Level

Higher-level languages usually sacrifice some speed.

Low-level languages provide direct hardware access.

Examples:

Level	Languages
Low-Level	C, C++, Rust
Mid-Level	Go, Java
High-Level	Python, JavaScript

More abstraction usually means:

Easier development
Lower performance

5. JIT vs Ahead-of-Time Compilation

Ahead-of-Time (AOT)

Code compiles before execution.

Examples:

C
C++
Rust

Produces very fast native binaries.

Just-in-Time (JIT)

Code compiles during execution.

Examples:

Java
JavaScript
C#

JIT can become extremely optimized after warm-up.

The Fastest Programming Languages

Now let’s explore the fastest languages in detail.

1. C — The King of Raw Performance

Why C is Fast

C is one of the closest high-level languages to hardware.

It provides:

Direct memory access
Minimal runtime overhead
Manual memory management
Extremely small abstractions
Efficient compiled binaries

C code is translated almost directly into machine instructions.

That is why operating systems, databases, kernels, drivers, and embedded systems heavily use C.

Advantages of C

Extremely Fast

C has near-zero abstraction overhead.

Small Executables

Compiled binaries are compact.

Direct Hardware Access

Perfect for:

Operating systems
Drivers
Embedded devices
Database engines

Portable

C can run almost everywhere.

Disadvantages of C

Unsafe Memory Management

Programmers must manually manage memory.

This can cause:

Memory leaks
Crashes
Security vulnerabilities

Harder Development

C development is more difficult than modern languages.

Real-World Systems Built with C

Linux Kernel
MySQL
PostgreSQL
Redis
SQLite
Git
Nginx

Best Use Cases

C is excellent for:

Operating systems
Database engines
Embedded systems
Game engines
Compilers
Device drivers
Networking systems

2. C++ — High Performance with Abstraction

C++ extends C with advanced programming features.

It remains one of the fastest languages ever created.

Why C++ is Fast

C++ provides:

Native compilation
Zero-cost abstractions
Template metaprogramming
Fine memory control
Powerful optimizations

Modern C++ compilers are incredibly advanced.

Advantages of C++

Near-C Performance

C++ can perform almost as fast as C.

Object-Oriented Programming

Supports:

Classes
Inheritance
Polymorphism

Powerful Standard Library

Includes:

Containers
Algorithms
Smart pointers
Threading

High Flexibility

C++ supports multiple paradigms:

Procedural
Object-oriented
Generic
Functional

Disadvantages of C++

Complexity

C++ is one of the most complex programming languages.

Memory Safety Problems

Still vulnerable to:

Undefined behavior
Pointer bugs
Memory corruption

Real-World Systems Built with C++

Unreal Engine
Chrome Browser
Blender
Adobe Software
AAA Game Engines
High-frequency trading systems

Best Use Cases

C++ is excellent for:

High-performance applications
Game development
Real-time systems
Graphics engines
Simulation software
Financial systems

3. Rust — Fast and Memory Safe

Rust became extremely popular because it combines:

C/C++-level performance
Memory safety
Modern tooling

Rust is often considered the future of systems programming.

Why Rust is Fast

Rust uses:

Native compilation
Zero-cost abstractions
Ownership system
No garbage collector
Aggressive optimizations

Rust achieves safety without GC overhead.

Advantages of Rust

Memory Safety

Rust prevents:

Null pointer bugs
Data races
Use-after-free errors

Excellent Performance

Rust is often comparable to C++.

Concurrency Safety

Rust makes multithreading safer.

Modern Tooling

Cargo package manager is excellent.

Disadvantages of Rust

Steep Learning Curve

Ownership and borrowing are difficult initially.

Longer Compile Times

Rust compilation can be slower.

Real-World Systems Built with Rust

Firefox Components
Cloudflare Systems
Dropbox Infrastructure
Linux Kernel Modules
High-performance networking tools

Best Use Cases

Rust is excellent for:

Systems programming
Networking
Blockchain
Security tools
Databases
Game engines
High-performance APIs

4. Go — Simplicity with Strong Performance

Go was created by Google.

Its goal was:

Simplicity
Fast compilation
Concurrency
Scalable backend systems

Go is not as fast as C or Rust, but it performs extremely well for server-side workloads.

Why Go is Fast

Go uses:

Compiled binaries
Lightweight goroutines
Efficient runtime
Optimized garbage collector

Advantages of Go

Very Fast Compilation

Go compiles extremely quickly.

Excellent Concurrency

Goroutines are lightweight.

Simple Syntax

Easy to learn and maintain.

Strong Backend Performance

Perfect for cloud infrastructure.

Disadvantages of Go

Garbage Collection Overhead

GC still introduces some latency.

Less Low-Level Control

Not as flexible as C or Rust.

Real-World Systems Built with Go

Docker
Kubernetes
Terraform
Prometheus
Many cloud-native systems

Best Use Cases

Go is excellent for:

APIs
Microservices
Cloud infrastructure
Backend systems
Networking servers
DevOps tools

5. Java — High Performance Through JVM

Many developers underestimate Java speed.

Modern Java can be extremely fast because of:

JVM optimizations
JIT compilation
Advanced garbage collectors

Why Java is Fast

The JVM dynamically optimizes hot code paths.

After warm-up, Java performance becomes impressive.

Advantages of Java

Mature Ecosystem

Huge libraries and frameworks.

Strong Performance

Excellent enterprise performance.

Cross-Platform

“Write once, run anywhere.”

Strong Tooling

Excellent IDE support.

Disadvantages of Java

Higher Memory Usage

JVM consumes significant RAM.

Startup Time

Slower startup compared to native binaries.

Real-World Systems Built with Java

Hadoop
Elasticsearch
Enterprise Banking Systems
Android Applications

Best Use Cases

Java is excellent for:

Enterprise applications
Large-scale backend systems
Banking systems
Big data systems

6. C# — Fast Modern Managed Language

C# runs on the .NET runtime.

Modern .NET performance has improved dramatically.

Why C# is Fast

C# uses:

JIT compilation
Runtime optimizations
Efficient garbage collection

Modern .NET is highly optimized.

Advantages of C

Excellent Developer Experience

Very productive language.

Strong Ecosystem

Powerful frameworks and tools.

Good Performance

Very competitive runtime speed.

Great for Games

Unity uses C# heavily.

Disadvantages of C

Runtime Dependency

Requires .NET runtime.

GC Overhead

Still affected by garbage collection.

Real-World Systems Built with C

Unity Games
Enterprise Systems
ASP.NET Applications
Windows Applications

Best Use Cases

C# is excellent for:

Game development
Enterprise software
Desktop apps
APIs
Cross-platform applications

7. Zig — A Rising High-Performance Language

Zig is a modern systems programming language.

It focuses on:

Simplicity
Performance
Manual control
Better C interoperability

Why Zig is Fast

Zig compiles directly to native machine code.

It has:

Minimal runtime
Explicit memory management
Strong compiler optimizations

Advantages of Zig

Very Predictable Performance

Excellent C Interoperability

Simple Language Design

No Hidden Allocations

Disadvantages of Zig

Young Ecosystem

Libraries and tooling are still growing.

Smaller Community

Compared to established languages.

Best Use Cases

Zig is excellent for:

Systems programming
Embedded software
Performance-critical tools
Replacing C in modern projects

Performance Comparison Table

Language	Speed	Memory Efficiency	Safety	Ease of Use	Best For
C	Extremely High	Extremely High	Low	Medium	Kernels, databases
C++	Extremely High	Extremely High	Medium	Hard	Games, engines
Rust	Extremely High	Extremely High	Very High	Hard	Safe systems programming
Go	High	Good	High	Easy	Cloud backends
Java	High	Medium	High	Medium	Enterprise systems
C#	High	Medium	High	Easy	Enterprise + games
Zig	Extremely High	Extremely High	Medium	Medium	Modern low-level software

Which Language is Actually the Fastest?

There is no single universal answer.

But generally:

Raw Native Speed

Usually:

C
C++
Rust
Zig

These languages compile directly into optimized machine code.

Best Performance + Safety Balance

Rust is often considered the strongest balance between:

Performance
Reliability
Modern tooling
Concurrency safety

Best Performance for Backend Development

Go is often preferred because:

Easy concurrency
Fast development
Excellent deployment
Strong scalability

Best Enterprise Performance

Java and C# dominate enterprise software.

Their ecosystems are enormous.

Why Python and JavaScript Are Not in the Fastest List

Python and JavaScript are incredibly popular.

But they are not raw-performance languages.

Python

Python is slower because:

Interpreted execution
Dynamic typing
Heavy runtime overhead

However:

Python dominates:

AI
Machine learning
Data science
Automation

Because development speed matters.

JavaScript

JavaScript engines are highly optimized.

But JavaScript still cannot usually match:

C
C++
Rust

for low-level performance.

However, JavaScript dominates:

Web development
Frontend applications
Node.js backends

Speed vs Productivity

One important truth:

The fastest language is not always the best language.

For example:

A team can build a Python application much faster than a C++ application.
Developer productivity sometimes matters more than CPU speed.
Faster development can save millions of dollars.

That is why companies choose different languages for different goals.

Real-World Engineering Truth

Large systems rarely use only one language.

Example architecture:

Component	Language
Kernel	C
Database Engine	C/C++
Backend APIs	Go/Java
AI Systems	Python
Frontend	JavaScript
High-Performance Modules	Rust/C++

Modern software engineering is multi-language.

Final Ranking (General Purpose Performance)

Tier 1 — Absolute Performance

C
C++
Rust
Zig

Tier 2 — High Performance + Productivity

Go
Java
C#

Tier 3 — Slower but Extremely Productive

Python
JavaScript
Ruby
PHP

Final Thoughts

Performance is not only about benchmarks.

A truly great programming language balances:

Speed
Safety
Maintainability
Ecosystem
Developer productivity
Scalability

If you want:

Maximum hardware control → C
Powerful performance engineering → C++
Modern safe systems programming → Rust
Cloud-native backend development → Go
Enterprise systems → Java/C#

The “best” language depends on your goals.

But in terms of pure raw execution speed, low-level native languages like C, C++, Rust, and Zig continue to dominate the performance world.

What Do You Think?

Which programming language do you think offers the best balance between:

Speed
Safety
Productivity
Simplicity

Share your opinion in the comments.

Why Git Was Created

Farhad Rahimi Klie — Mon, 11 May 2026 05:56:32 +0000

Before Git, the Linux kernel developers used a version control system called BitKeeper.

BitKeeper was proprietary software, but Linux developers could use it for free for kernel development.

Then in 2005:

Licensing conflicts happened
Access to BitKeeper was removed for Linux developers
The Linux kernel team suddenly lost the tool managing one of the world’s biggest software projects

This was a disaster.

The Linux kernel already had:

thousands of files
many developers
patches arriving constantly
changes from all over the world

Linus Torvalds needed a replacement immediately.

He did not like existing systems because they were:

slow
centralized
hard to merge
bad at handling large distributed development

So he decided to build his own system.

2. How Fast Git Was Built

This is one of the most famous parts of Git history.

The first version of Git was built in only a few days.

Core development timeline:

Day 1–2: Basic object storage and hashing concepts
Around Day 4: Could track file snapshots
Around Day 10: Basic branching and commits worked
Within about 2 weeks: Git became usable for Linux kernel development

That speed sounds impossible today, but several things made it possible:

Linus already understood:

operating systems
filesystems
performance engineering
distributed collaboration
kernel development workflows
low-level data structures

He was not experimenting randomly.

He already had a very clear mental model before writing code.

3. What Language Git Was Written In

Git was primarily written in:

Why C?

Because:

extremely fast
direct filesystem access
portable
already used heavily in Linux
minimal overhead
efficient memory control

Git also used:

shell scripting initially
some Perl scripts in older tooling

But the core engine was C.

Today Git includes:

C
shell
Perl
Python
Tcl/Tk
some platform-specific code

But its heart is still mostly C.

4. The Mentality Behind Git

This is the most important part.

Git was not designed like a normal “application.”

Linus designed Git like a filesystem + cryptographic database.

His mentality was:

“Store everything as immutable content objects.”

That single idea shaped all Git architecture.

5. The Core Philosophy of Git

Most old version control systems stored:

file differences
centralized history
sequential changes

Git instead stores:

complete snapshots
content-addressed objects
immutable history

This was revolutionary.

Git thinks like this:

Project State → Hash → Stored Object

Not:

Edit A → Edit B → Edit C

That difference is enormous.

6. Git’s Most Important Idea: Hashing

Git uses cryptographic hashes.

Originally:

SHA-1

Every file and object gets a unique hash.

Example:

e83c5163316f89bfbde7d9ab23ca2e25604af290

That hash identifies content.

Meaning:

if content changes
hash changes

So Git can detect:

modifications
corruption
exact history relationships

This made Git:

reliable
fast
distributed

7. Git Was Designed Backwards From Performance

Linus cared deeply about performance.

His priorities were:

Speed
Data integrity
Distributed workflow
Branching efficiency
Merge capability

Not:

pretty UI
beginner friendliness
enterprise features

That is why Git commands can feel difficult.

It was originally designed for kernel developers.

8. The Architecture of Git

Git internally stores objects:

Blob

Stores file contents.

Tree

Stores directory structures.

Commit

Stores:

author
timestamp
parent commits
snapshot reference

Tag

Named references.

Everything becomes objects.

9. Why Git Branching Is So Fast

In many older systems:

branches copied files

In Git:

branches are basically lightweight pointers.

A branch is almost just:

branch_name → commit_hash

That means:

branch creation is nearly instant
switching branches is fast
merging is easier

This was a huge innovation.

10. Git Was Built for Distributed Development

Older systems often relied on a central server.

Git changed this.

Every developer gets:

full history
full commits
full branches
complete repository

Meaning:

work offline
no single point of failure
easier collaboration

This was revolutionary in 2005.

11. How Linus Actually Built It

Linus usually builds software with this mentality:

Step 1 — Solve only the core problem

No unnecessary abstractions.

Step 2 — Make data structures efficient

Performance first.

Step 3 — Use small composable tools

Git originally had many tiny commands.

Step 4 — Trust powerful primitives

Instead of giant frameworks.

Step 5 — Optimize around real workflows

Not theoretical design.

This is very Unix-like thinking.

12. Early Git Was Extremely Rough

The first Git versions were:

ugly
command-line heavy
poorly documented
hard to use

Linus himself said he was not trying to make it pretty.

He only wanted:

speed
correctness
distributed functionality

Later developers improved usability.

One major contributor was:

Junio Hamano

He became the long-term maintainer and helped Git mature into a polished tool.

13. Why Git Became Dominant

Git became dominant because it solved real engineering pain better than competitors.

Major advantages:

fast branching
powerful merging
offline development
integrity checking
scalability
distributed collaboration

This made it perfect for:

open source
large engineering teams
internet-scale collaboration

Then platforms like:

GitHub
GitLab
Bitbucket

accelerated adoption massively.

14. The Most Important Technical Insight

Git is not really “a source control app.”

Internally, it is closer to:

a content-addressable object database
plus graph relationships
plus filesystem snapshots

That architectural decision is why Git still scales today.

15. Why Git Feels Complicated

Because Git exposes internal concepts directly:

HEAD
refs
index
detached HEAD
rebasing
object store

Linus optimized for:

power
flexibility
speed

not beginner simplicity.

That tradeoff is still visible today.

16. The Deep Engineering Lesson From Git

Git teaches a major software engineering principle:

Great systems are often built from a few powerful primitives.

Git’s primitives:

hashes
immutable objects
pointers
graphs
snapshots

From those few concepts, an entire ecosystem emerged.

17. Final Summary

Git was:

created in 2005
mainly built by Linus Torvalds
written mostly in C
initially usable within about 10–14 days
designed under extreme pressure
optimized for speed and distributed collaboration

The mentality behind Git was:

Simple primitives
+ immutable data
+ hashing
+ distributed architecture
+ performance-first engineering

That combination changed software development forever.

Ken Thompson — The Quiet Genius Who Helped Build Modern Computing

Farhad Rahimi Klie — Sun, 10 May 2026 03:17:37 +0000

When people talk about the history of computers, names like Bill Gates, Steve Jobs, or Linus Torvalds usually appear first. But behind many of the technologies those people used or improved, there was another engineer whose influence runs deeper than most people realize:

Ken Thompson.

If modern computing were a giant city, Ken Thompson helped design the roads, plumbing, and electricity before anyone else even started building houses.

He was not loud.
He was not a businessman.
He rarely chased fame.

But he helped create some of the most important technologies in computer history:

UNIX
The C programming ecosystem
The B programming language
UTF-8
Early operating system concepts
Modern software tools
Influential ideas behind Linux, macOS, Android, and much more

Almost every programmer today uses systems that were directly or indirectly shaped by his work.

This article explores who Ken Thompson is, how he thought, what he built, why his ideas mattered, and why computer science students should study him carefully.

Who Is Ken Thompson?

Ken Thompson was born on February 4, 1943, in New Orleans.

He became one of the most influential computer scientists in history and is best known for co-creating:

UNIX operating system
B programming language
Early UNIX tools
UTF-8 encoding

He worked mainly at Bell Labs, one of the greatest research laboratories ever created.

Bell Labs was not an ordinary company office. It was a place where scientists invented technologies that changed the world:

Transistors
Information theory
UNIX
C language
Laser technology
Satellite communication innovations

Many legendary computer scientists worked there, including:

Dennis Ritchie
Brian Kernighan
Claude Shannon

Ken Thompson became one of the brightest minds among them.

Early Interest in Computers

Ken Thompson studied electrical engineering and computer science at the:

University of California, Berkeley

During the 1960s, computers were massive, expensive machines. Programming was difficult, slow, and painful.

Most systems were:

Complicated
Hard to use
Hard to modify
Tightly controlled by companies

Thompson had a different mindset.

He believed software should be:

Simple
Elegant
Modular
Practical
Easy to combine

That philosophy later became the foundation of UNIX.

The World Before UNIX

To understand Ken Thompson’s importance, you must understand the computing world before UNIX.

In the 1960s:

Operating systems were huge and messy
Software was often tied to specific hardware
Portability barely existed
Developers wasted enormous time managing system complexity

One major project at the time was:

Multics

Multics was a collaborative project involving:

General Electric
MIT
Bell Labs

The goal was ambitious:

Build the ultimate operating system.

But there was a problem.

The project became extremely complicated.

Ken Thompson and Dennis Ritchie started feeling frustrated with its complexity.

This frustration eventually led to one of the greatest breakthroughs in computing history.

The Birth of UNIX

In 1969, after Bell Labs left the Multics project, Ken Thompson began building a simpler operating system.

Initially, he wanted a system where he could run a game called:

Space Travel

That small experiment became something much bigger.

He worked on an old machine:

PDP-7 computer

And started building tools and system components from scratch.

Soon, Dennis Ritchie joined him.

Together they created:

UNIX

The name UNIX was actually a joke inspired by “Multics.”

Multics was complicated and massive.

UNIX was supposed to be simpler and cleaner.

Why UNIX Was Revolutionary

UNIX changed computing forever because it introduced ideas that were radically different.

1. Everything Should Be Simple

Instead of giant programs doing everything, UNIX encouraged:

Small tools
Small commands
Single-purpose utilities

Each program should do one thing well.

This idea sounds normal today.

Back then, it was revolutionary.

2. Programs Should Work Together

UNIX introduced pipelines.

Example:

cat file.txt | grep hello | sort

This allowed programs to communicate easily.

Small tools could be connected together like LEGO blocks.

This philosophy deeply influenced modern software engineering.

3. Everything Is a File

In UNIX:

Devices
Processes
Hardware communication

could often be treated like files.

This simplified system design dramatically.

Even today, Linux and macOS still follow this idea.

4. Portability

UNIX became portable across different hardware.

That was an enormous breakthrough.

Before UNIX, operating systems were usually trapped on one machine type.

This portability later inspired:

Linux
BSD
macOS
Android internals

The Creation of the B Language

Before C language existed, Ken Thompson created:

B programming language

B was influenced by another language called:

BCPL

B was simple and powerful for system programming.

But computers evolved quickly, and B had limitations.

Then Dennis Ritchie improved those ideas and created:

C programming language

Without Ken Thompson’s B language, C might never have existed in the form we know today.

And without C:

Linux may not exist
Modern operating systems may look very different
Embedded systems would evolve differently
Modern compilers would change dramatically

UNIX and C Changed the Entire Industry

UNIX and C together became one of the most important combinations in computer history.

Why?

Because UNIX was rewritten in C.

That was groundbreaking.

Before this, operating systems were mostly written in assembly language.

Assembly is:

Hardware-specific
Hard to maintain
Difficult to port

C allowed UNIX to move between different computers much more easily.

This single decision transformed software engineering forever.

Influence on Linux and Modern Systems

Many people think Linux appeared from nowhere.

It did not.

Linus Torvalds created Linux heavily inspired by UNIX.

Modern systems influenced by UNIX include:

Linux
Android
macOS
BSD systems
iOS internals
Server infrastructure
Cloud computing systems

Even command-line tools today still reflect UNIX philosophy.

When developers use commands like:

ls
grep
cat
awk
sed

they are using ideas that came from Thompson’s era.

Ken Thompson and UTF-8

One of Ken Thompson’s lesser-known but extremely important contributions was:

UTF-8

He worked with:

Rob Pike

to help develop UTF-8.

UTF-8 became the dominant text encoding standard for the internet.

Without UTF-8, handling global languages would be much harder.

Today UTF-8 powers:

Websites
Databases
APIs
Operating systems
Programming languages

Almost every developer uses UTF-8 daily, often without realizing it.

The UNIX Philosophy

The “UNIX Philosophy” became one of the most influential engineering mindsets ever created.

Core principles include:

Build Small Tools

Avoid giant complicated systems when possible.

Make Programs Composable

Programs should connect together easily.

Prefer Simplicity

Simple systems survive longer.

Write Clear Code

Readable systems are maintainable systems.

Avoid Unnecessary Complexity

Complexity is expensive.

This philosophy strongly influenced:

Open-source culture
Linux development
DevOps tools
Modern backend engineering
Cloud infrastructure

Even modern container systems like:

Docker

inherit UNIX-style thinking.

Ken Thompson’s Programming Style

Many legendary programmers admired Thompson because of his coding style.

His code was often described as:

Minimal
Elegant
Efficient
Clever without being messy

He avoided unnecessary abstraction.

He focused on practical engineering.

This is important because modern software sometimes becomes overly complicated.

Thompson believed good engineering often means removing complexity, not adding more features.

The Famous “Trusting Trust” Lecture

One of Ken Thompson’s most famous contributions to computer security was his lecture:

“Reflections on Trusting Trust.”

This lecture explained a terrifying idea.

A compiler could secretly inject malicious code into software automatically.

Even if developers inspect the source code, the malicious behavior could remain hidden.

This concept became one of the foundational ideas in software supply chain security.

Today, discussions about:

Compiler trust
Build security
Supply chain attacks

still reference Thompson’s ideas.

Modern cybersecurity experts continue studying this work.

Awards and Recognition

Ken Thompson received many major awards, including:

Turing Award

Often called:

“The Nobel Prize of Computing.”

He received it together with:

Dennis Ritchie

for UNIX development.

National Medal of Technology

Awarded by the United States government.

Japan Prize

Another major international scientific award.

Despite all these achievements, Thompson remained relatively humble and quiet.

Working at Google

Later in his career, Ken Thompson worked at:

Google

He contributed to various systems and engineering projects.

Even in modern computing eras, his expertise remained extremely valuable.

Why Ken Thompson Matters to Programmers

Many beginner programmers focus only on modern frameworks.

But understanding pioneers like Ken Thompson teaches deeper lessons.

He teaches us:

1. Simplicity Is Powerful

Complexity is not intelligence.

Clear systems often outperform complicated ones.

2. Good Tools Matter

Developer productivity depends heavily on tools.

UNIX tools changed how programmers work.

3. Software Design Matters

Architecture decisions can influence decades of technology.

UNIX ideas survived for over 50 years.

That is extraordinary.

4. Elegant Thinking Beats Hype

Ken Thompson was not known for marketing.

He was known for solving problems well.

Ken Thompson’s Lasting Legacy

Today, millions of developers unknowingly use his ideas every day.

When you:

Open a Linux terminal
Use macOS
Run cloud servers
Write UTF-8 text
Use command-line pipelines
Study operating systems

you are interacting with Thompson’s legacy.

Very few individuals have shaped computing this deeply.

His influence exists beneath the surface of modern technology.

Invisible. Foundational. Permanent.

Final Thoughts

Ken Thompson is one of the true architects of modern computing.

He helped create systems and philosophies that transformed software engineering forever.

What makes his story especially important is this:

He did not chase complexity.
He chased clarity.

He did not build technology just to impress people.
He built systems that worked beautifully.

And that mindset is something every programmer should learn.

Because in the end, the best engineering is often not about adding more.

It is about understanding what can be removed while keeping the system powerful.

That was Ken Thompson’s genius.

GDB Debugger for C and C++ – Complete Guide

Farhad Rahimi Klie — Mon, 04 May 2026 01:52:31 +0000

Introduction

Debugging is a critical skill for any systems programmer working with C or C++. Unlike higher-level languages, C and C++ give you direct access to memory and low-level operations, which makes debugging both powerful and complex. The GNU Debugger (GDB) is one of the most widely used tools for debugging C and C++ programs.

What is GDB?

GDB (GNU Debugger) is a command-line debugging tool used to inspect and control the execution of programs. It allows developers to:

Pause execution (breakpoints)
Step through code line-by-line
Inspect variables and memory
Modify program state at runtime
Analyze crashes and core dumps

GDB works by interfacing with compiled binaries that include debugging symbols.

Installing GDB

Linux (Ubuntu/Debian)

sudo apt update
sudo apt install gdb

macOS (with Homebrew)

brew install gdb

Windows

Use MinGW or WSL:

Install WSL and Ubuntu
Then install GDB inside WSL

Compiling with Debug Symbols

To use GDB effectively, you must compile your program with debug information using the -g flag:

gcc -g program.c -o program
g++ -g program.cpp -o program

Optional flags:

-O0 → disable optimization (recommended for debugging)
-Wall → show warnings

Example:

gcc -g -O0 -Wall main.c -o main

Starting GDB

gdb ./program

Once inside GDB:

(gdb)

Running the Program

run

With arguments:

run arg1 arg2

Breakpoints

Set breakpoint at function

break main

Set breakpoint at line

break 10

Set breakpoint in file

break file.c:25

List breakpoints

info breakpoints

Delete breakpoint

delete 1

Stepping Through Code

Step into (enter functions)

step

Step over (skip function internals)

next

Continue execution

continue

Finish current function

finish

Inspecting Variables

Print variable

print x

Print pointer value

print *ptr

Display automatically

display x

Show all local variables

info locals

Working with Memory

Examine memory

x/4x ptr

Format explanation:

4 → number of units
x → hexadecimal format

Examples:

x/10d ptr   # decimal
x/5c ptr    # characters

Call Stack (Backtrace)

When a crash occurs:

backtrace

This shows the function call chain.

Navigate stack:

frame 0
frame 1

Watchpoints

Watchpoints track variable changes.

watch x

Breaks when x changes.

Conditional Breakpoints

break 20 if x == 5

Modifying Variables

set variable x = 10

Debugging Segmentation Faults

Compile with -g, then run:

gdb ./program
run

When it crashes:

backtrace

Check variables:

print ptr

Common causes:

Null pointer dereference
Out-of-bounds array access
Use-after-free

Core Dumps

Enable core dumps:

ulimit -c unlimited

Run program → crash generates core file.

Analyze:

gdb program core

Debugging Multi-file Projects

Compile all files with -g:

gcc -g main.c utils.c -o app

Then debug normally.

Working with C++ in GDB

GDB supports:

Classes
Objects
Templates
STL containers (with limitations)

Print object:

print obj

Pretty printing (for STL):

set print pretty on

Advanced Features

1. TUI Mode (Text UI)

gdb -tui ./program

2. Layout Commands

layout src
layout asm

3. Disassembly

disassemble main

4. Reverse Debugging (if supported)

reverse-continue

Useful GDB Shortcuts

Command	Description
r	run
c	continue
n	next
s	step
bt	backtrace
p	print

Example Debugging Session

Code (buggy)

#include <stdio.h>

int main() {
    int *ptr = NULL;
    printf("%d\n", *ptr);
    return 0;
}

Steps

gcc -g main.c -o main
gdb ./main
break main
run
next
print ptr

You will see ptr = 0x0 → null pointer → crash.

Best Practices

Always compile with -g
Disable optimization (-O0) while debugging
Use meaningful variable names
Reproduce bugs consistently
Use watchpoints for tricky bugs
Learn keyboard shortcuts

Conclusion

GDB is an essential tool for any C/C++ developer. Mastering it allows you to deeply understand program execution, memory behavior, and runtime issues. While it may feel complex initially, consistent practice will make debugging faster and more efficient.

If you are serious about systems programming, learning GDB is not optional—it is fundamental.

How We Built Our Own Database Engine 🚀

Farhad Rahimi Klie — Sat, 25 Apr 2026 02:28:50 +0000

Building a database engine from scratch might sound intimidating—but it’s one of the most rewarding ways to truly understand how data systems work under the hood. In this article, I’ll walk you through the journey of creating a simple custom database engine, the challenges we faced, and what we learned along the way.

🧠 Why Build a Database Engine?

At first, it might seem unnecessary—after all, we already have powerful databases like MySQL, PostgreSQL, and MongoDB. But building your own gives you:

A deep understanding of data storage and retrieval
Insight into performance optimization
Hands-on experience with memory management
Better problem-solving skills as a developer

This project isn’t about replacing existing databases—it’s about learning how they work.

⚙️ Core Concepts We Needed

Before writing any code, we had to understand the fundamentals:

1. Storage Engine

This is how data is physically stored. We chose a simple file-based system where records are written directly to disk.

2. Data Serialization

We needed a way to convert structured data into a format that can be stored and retrieved efficiently.

3. Indexing

Without indexing, searching would be painfully slow. We implemented a basic indexing mechanism to speed up lookups.

4. Query Processing

Even a minimal database needs to interpret commands like:

INSERT
SELECT
DELETE

🏗️ Architecture Overview

Our database engine consists of several key components:

+---------------------+
|   Query Interface   |
+---------------------+
           |
+---------------------+
|   Query Parser      |
+---------------------+
           |
+---------------------+
| Execution Engine    |
+---------------------+
           |
+---------------------+
| Storage Manager     |
+---------------------+
           |
+---------------------+
| File System         |
+---------------------+

Each layer has a specific responsibility, making the system modular and easier to debug.

💾 Step 1: Designing the Storage Layer

We started by implementing a simple storage mechanism:

Data is stored in binary files
Each record has a fixed size
File offsets are used for quick access

Example idea in C:

typedef struct {
    int id;
    char name[50];
} Record;

We used file operations like fopen, fwrite, and fread to manage data.

🔍 Step 2: Implementing Indexing

To avoid scanning the entire file every time, we added a basic index:

Key → File offset mapping
Stored in memory for fast lookup

This allowed us to jump directly to the record location instead of reading everything.

🧾 Step 3: Query Parser

We created a simple parser that understands commands like:

INSERT 1 Farhad
SELECT 1
DELETE 1

The parser splits input into tokens and maps them to operations.

⚡ Step 4: Execution Engine

The execution engine is the brain of the system:

Receives parsed queries
Calls appropriate functions
Interacts with storage and index

For example:

if (command == INSERT) {
    insert_record(...);
}

🧹 Step 5: Memory Management

Since we were working in C, memory handling was critical:

Manual allocation (malloc)
Deallocation (free)
Avoiding leaks and fragmentation

We also implemented simple block management to reuse freed space.

🚧 Challenges We Faced

1. Data Corruption

A small mistake in file handling could corrupt the entire database.

2. Synchronization

Ensuring data consistency between memory and disk was tricky.

3. Performance

Naive implementations were slow—indexing made a huge difference.

📈 What We Learned

How databases manage data internally
Importance of abstraction and modular design
Low-level memory and file system operations
Trade-offs between simplicity and performance

🚀 Future Improvements

If we were to take this further:

Add B-Tree indexing
Support complex queries (WHERE, JOIN)
Implement transactions (ACID properties)
Add concurrency control

🎯 Final Thoughts

Building your own database engine isn’t just a project—it’s an experience that transforms how you think about data systems. Even a simple implementation teaches concepts that are used in real-world databases at scale.

If you're a developer who enjoys digging deep into systems, this is one of the best projects you can take on.

💡 Bonus Tip

If you’re planning to share your project on GitHub, include:

Clear documentation
Example commands
Screenshots or demos

It makes your project much more attractive and understandable.

Happy coding! 🔥

Binary and Hexadecimal Number Systems — A Complete Guide for Low-Level Programming

Farhad Rahimi Klie — Tue, 21 Apr 2026 09:57:31 +0000

When you work close to hardware—whether in C, C++, embedded systems, operating systems, or reverse engineering—you must think like the machine. And machines do not understand decimal numbers. They operate using binary (base-2). To make binary manageable for humans, we use hexadecimal (base-16).

This article gives you a complete, step-by-step understanding of both systems, with practical insight for real programming scenarios.

1. Why Number Systems Matter in Low-Level Programming

At the hardware level:

Memory stores bits (0 and 1)
CPU processes binary instructions
Registers, pointers, addresses → all binary

But binary is long and hard to read. That’s where hexadecimal comes in—it’s a compact human-friendly representation of binary.

2. Binary Number System (Base 2)

2.1 Definition

Binary uses only two digits:

0 and 1

Each position represents a power of 2.

2.2 Positional Value

Example:

1011₂

Break it down:

1×2³ + 0×2² + 1×2¹ + 1×2⁰
= 8 + 0 + 2 + 1
= 11₁₀

2.3 Binary Table (Important to Memorize)

Power	Value
2⁰	1
2¹	2
2²	4
2³	8
2⁴	16
2⁵	32
2⁶	64
2⁷	128

These are critical for bit manipulation.

2.4 Binary in Memory

A bit = 0 or 1
A byte = 8 bits

Example:

00001010 → 10 in decimal

2.5 Binary Representation of Numbers

Positive Numbers

Stored directly:

5 → 00000101

Negative Numbers (Two’s Complement)

Steps:

Convert to binary
Invert bits
Add 1

Example: -5 (8-bit)

5      = 00000101
Invert = 11111010
+1     = 11111011

2.6 Binary Operations

AND (&)

1 & 1 = 1
1 & 0 = 0

OR (|)

1 | 0 = 1

XOR (^)

1 ^ 1 = 0
1 ^ 0 = 1

NOT (~)

~00000101 = 11111010

2.7 Example in C

#include <stdio.h>

int main() {
    int a = 5;   // 00000101
    int b = 3;   // 00000011

    printf("AND: %d\n", a & b); // 1
    printf("OR : %d\n", a | b); // 7
    printf("XOR: %d\n", a ^ b); // 6

    return 0;
}

3. Hexadecimal Number System (Base 16)

3.1 Definition

Hexadecimal uses:

0–9 and A–F

Hex	Decimal
A	10
B	11
C	12
D	13
E	14
F	15

3.2 Why Hexadecimal?

Binary is long:

11111111

Hex makes it short:

FF

So:

1 byte = 8 bits = 2 hex digits

3.3 Positional Value

Example:

2F₁₆

2×16¹ + 15×16⁰
= 32 + 15
= 47₁₀

3.4 Binary ↔ Hex Conversion (CRITICAL SKILL)

Rule:

Group binary into 4 bits

Example 1: Binary → Hex

10101111

Group:

1010 1111

Convert:

1010 = A
1111 = F

Result:

AF₁₆

Example 2: Hex → Binary

3C

Convert each:

3 = 0011
C = 1100

Result:

00111100

3.5 Hex in Programming

C Example:

int x = 0xFF;  // 255
int y = 0x1A;  // 26

Memory Address:

0x7ffeefbff5c8

4. Binary vs Hexadecimal (Comparison)

Feature	Binary	Hexadecimal
Base	2	16
Digits	0,1	0–9, A–F
Length	Long	Short
Usage	Machine level	Human-friendly

5. Real Use Cases in Low-Level Programming

5.1 Memory Inspection

Debugger output:

0x7fff → address

5.2 Bit Masking

int flags = 0x0F; // 00001111

5.3 Embedded Systems

Registers:

0xFF00 → hardware control

5.4 Networking

IP (hex view):

C0 A8 01 01 → 192.168.1.1

5.5 Assembly Language

MOV AX, 0x1F

6. Conversion Methods (Step-by-Step)

6.1 Decimal → Binary

Divide by 2 repeatedly:

13 ÷ 2 = 6 r1
6 ÷ 2  = 3 r0
3 ÷ 2  = 1 r1
1 ÷ 2  = 0 r1

Result: 1101

6.2 Decimal → Hex

Divide by 16:

47 ÷ 16 = 2 r15 (F)
2 ÷ 16  = 0 r2

Result: 2F

6.3 Binary → Decimal

Multiply powers of 2.

6.4 Hex → Decimal

Multiply powers of 16.

7. Important Patterns to Master

7.1 Hex ↔ Binary Table (Must Memorize)

Hex	Binary
0	0000
1	0001
2	0010
3	0011
4	0100
5	0101
6	0110
7	0111
8	1000
9	1001
A	1010
B	1011
C	1100
D	1101
E	1110
F	1111

8. Common Mistakes

Mixing base systems (e.g., treating hex as decimal)
Forgetting grouping in binary → hex
Ignoring leading zeros
Confusing ASCII vs numeric values

9. How to Master This (Practical Strategy)

Memorize powers of 2
Memorize hex ↔ binary table
Practice conversions daily
Use C programs to verify results
Read memory using debuggers (gdb)

10. Final Insight

Binary is the language of machines.
Hexadecimal is the language of programmers working close to machines.

If you master both:

Bit manipulation becomes easy
Debugging becomes powerful
System programming becomes natural

Mental Models for Programmers: Thinking Beyond Code

Farhad Rahimi Klie — Thu, 16 Apr 2026 03:29:17 +0000

Programming is not just about syntax, frameworks, or algorithms. At its core, it’s about how you think. The difference between an average developer and a great one often lies in the mental models they use to understand problems, design systems, and debug issues.

What is a Mental Model?

A mental model is a simplified way of understanding how something works in the real world. In programming, mental models help you:

Break down complex systems
Predict behavior before running code
Debug efficiently
Design scalable architectures

Think of mental models as your internal “toolkit for thinking.”

1. Divide and Conquer

Core Idea: Break complex problems into smaller, manageable parts.

When you face a large problem, don’t try to solve it all at once. Instead:

Split it into subproblems
Solve each independently
Combine results

Example:
Building a web app:

UI (Frontend)
API (Backend)
Database (Storage)

Each layer can be developed and tested separately.

Why it matters:
Reduces cognitive load and improves maintainability.

2. Abstraction

Core Idea: Hide complexity, expose only what’s necessary.

Good programmers don’t deal with every detail all the time. They create layers.

Examples:

Functions hide implementation details
APIs hide system complexity
Classes encapsulate behavior

int result = add(5, 3);

You don’t care how add works internally — that’s abstraction.

Why it matters:
Makes systems easier to use, understand, and scale.

3. First Principles Thinking

Core Idea: Break problems down to fundamental truths and build from there.

Instead of relying on assumptions:

Ask: What do I know for sure?
Rebuild the solution from basics

Example:
Instead of memorizing how a database index works, understand:

Data storage
Searching cost (O(n) vs O(log n))
Tree structures

Why it matters:
Helps you solve new problems, not just repeat known solutions.

4. Trade-offs (There is No Perfect Solution)

Core Idea: Every decision has a cost.

In programming, you constantly balance:

Speed vs Memory
Readability vs Performance
Simplicity vs Flexibility

Example:

Array → fast access, slow insert
Linked list → slow access, fast insert

Why it matters:
Prevents overengineering and helps you choose the right solution, not the perfect one.

5. DRY (Don’t Repeat Yourself)

Core Idea: Avoid duplication.

If you write the same logic multiple times, it becomes:

Hard to maintain
Error-prone

Instead:

Extract reusable functions
Use shared modules

Bad:

if (user.isAdmin) { ... }
if (user.isAdmin) { ... }

Good:

bool isAdmin(User u) { return u.role == "admin"; }

Why it matters:
Reduces bugs and improves maintainability.

6. KISS (Keep It Simple, Stupid)

Core Idea: Simpler solutions are better.

Avoid unnecessary complexity.

Bad mindset:

“Let’s use microservices, AI, and blockchain for this small app.”

Good mindset:

“What is the simplest solution that works?”

Why it matters:
Simple systems are easier to debug, extend, and scale.

7. YAGNI (You Aren’t Gonna Need It)

Core Idea: Don’t build for the future unnecessarily.

Programmers often over-engineer:

Adding features “just in case”
Designing systems for scale they don’t have

Reality:
Most of those features are never used.

Why it matters:
Saves time and keeps code clean.

8. Feedback Loops

Core Idea: Shorten the cycle between action and result.

Fast feedback improves learning and debugging.

Examples:

Unit tests
Logging
REPL environments

Why it matters:
The faster you see results, the faster you improve.

9. Systems Thinking

Core Idea: Everything is connected.

A bug in one part of the system can affect another.

Example:

Slow database → slow API → bad user experience

Instead of thinking in isolation, think in flows:

Input → Processing → Output

Why it matters:
Helps in designing scalable and reliable systems.

10. Inversion (Think Backwards)

Core Idea: Start from failure and work backward.

Ask:

“How can this system fail?”
“What could go wrong?”

Example:
Instead of only designing login:

What if password is wrong?
What if server is down?
What if user is hacked?

Why it matters:
Leads to more robust and secure systems.

11. Constraints Drive Creativity

Core Idea: Limitations improve solutions.

Constraints like:

Low memory
Slow network
Limited CPU

Force you to think smarter.

Why it matters:
Real-world systems always have constraints.

12. Readability > Cleverness

Core Idea: Code is read more than it is written.

Bad:

int x=!!a<<2|b^c;

Good:

int result = (a ? 1 : 0) * 4 | (b ^ c);

Why it matters:
Your future self (and team) will thank you.

Final Thoughts

Learning programming languages and frameworks is important — but they change constantly.

Mental models, however, are timeless.

If you master how to think:

You learn faster
Solve problems better
Build systems that last

Key Takeaway

Great programmers don’t just write code — they think in systems, trade-offs, and abstractions.

Git Stash — The Complete Guide Every Developer Should Know

Farhad Rahimi Klie — Mon, 13 Apr 2026 02:19:49 +0000

When you're working on a project, it’s very common to start coding something and suddenly realize you need to switch branches, fix a bug, or pull new changes. But your current work is incomplete and not ready to commit.

This is exactly where Git Stash becomes one of the most powerful tools in your workflow.

In this article, we will explore Git Stash in depth — from basics to advanced usage — with real-world scenarios and clear explanations.

🚀 What is Git Stash?

Git Stash temporarily saves your uncommitted changes (both staged and unstaged) so you can work on something else and come back later.

Think of it as a temporary storage (clipboard) for your code changes.

🧠 Why Use Git Stash?

Here are common scenarios:

You are in the middle of work but need to switch branches
You need to quickly fix a bug in production
You want to pull latest changes but your working directory is dirty
You want a clean working tree without committing incomplete work

📦 Basic Usage

1. Save Changes

git stash

This command:

Saves your modified tracked files
Reverts your working directory to the last commit

2. View Stashes

git stash list

Example output:

stash@{0}: WIP on main: 123abc Fix login bug
stash@{1}: WIP on feature: 456def Add new API

3. Apply Stash

git stash apply

This restores the latest stash but keeps it in the stash list.

4. Apply and Remove (Pop)

git stash pop

This:

Applies the stash
Removes it from the stash list

5. Drop a Stash

git stash drop stash@{0}

Deletes a specific stash.

6. Clear All Stashes

git stash clear

⚠️ Warning: This deletes all stashes permanently.

🔍 Stashing Specific Changes

Stash Only Staged Changes

git stash --staged

Stash Including Untracked Files

git stash -u

git stash --include-untracked

Stash Everything (Including Ignored Files)

git stash -a

🏷️ Naming Your Stash

Instead of default messages, you can name your stash:

git stash push -m "WIP: payment integration"

This helps a lot when managing multiple stashes.

🔄 Applying Specific Stash

git stash apply stash@{1}

🔀 Create Branch from Stash

One of the most useful features:

git stash branch new-branch-name

This:

Creates a new branch
Applies the stash
Removes it from stash list

Perfect when your temporary work becomes important.

⚠️ Handling Conflicts

When applying a stash, conflicts may occur if:

The same lines were changed
The codebase has evolved

Git will mark conflicts just like a merge:

<<<<<<< HEAD
Your current code
=======
Stashed code
>>>>>>> stash

You must resolve these manually.

🧩 Internal Working (Advanced)

When you run:

git stash

Git actually creates:

A commit for your working directory
A commit for your index (staged changes)

These are stored in a special reference:

refs/stash

So stash is not magic — it's structured commits behind the scenes.

🔥 Real-World Workflow Example

Scenario:

You're working on a feature:

git checkout feature-auth

You modify files but suddenly:

👉 You must fix a bug in main

Solution:

git stash
git checkout main
# fix bug
git commit -m "hotfix: login issue"
git checkout feature-auth
git stash pop

You’re back exactly where you left off.

💡 Best Practices

Use descriptive stash messages
Avoid keeping too many stashes
Prefer branches for long-term work
Use git stash pop carefully (it deletes stash)

❌ Common Mistakes

Forgetting stash exists → losing track of work
Using stash instead of proper commits
Not naming stashes → confusion later
Clearing stash accidentally

🧠 Pro Tips

Use git stash show -p to see full diff:

git stash show -p stash@{0}

Stash only part of changes (interactive):

git stash -p

Combine with rebase or pull for cleaner workflow

🎯 Conclusion

Git Stash is a powerful, flexible tool that helps you:

Switch context quickly
Keep your work safe
Maintain a clean workflow

But remember:

👉 It’s a temporary solution, not a replacement for commits or branches.

Mastering Git Stash will significantly improve your productivity and confidence when working with Git.

Git Merge vs Rebase — A Complete Guide for Developers

Farhad Rahimi Klie — Thu, 09 Apr 2026 04:07:43 +0000

When working with version control using Git, one of the most important concepts you must master is how to integrate changes from one branch into another. Two primary strategies exist for this: merge and rebase.

Although both achieve the same goal—combining changes—they do so in fundamentally different ways. Understanding these differences is critical for maintaining a clean, understandable project history.

🔹 What is Git Merge?

Concept

Git merge combines two branches by creating a new merge commit. It preserves the complete history of both branches.

How it Works

Imagine this:

A---B---C (main)
     \
      D---E (feature)

When you run:

git checkout main
git merge feature

Git creates a new commit:

A---B---C-------M (main)
     \         /
      D---E--- (feature)

👉 M is the merge commit.

Key Characteristics

Preserves full history
Non-destructive operation
Creates extra commit (merge commit)
Shows exact branching structure

Advantages

Safe and simple
Keeps context of how features were developed
Ideal for team collaboration

Disadvantages

History becomes messy with many branches
Harder to read in large projects

🔹 What is Git Rebase?

Concept

Git rebase moves (or “replays”) commits from one branch on top of another, creating a linear history.

How it Works

Starting from:

A---B---C (main)
     \
      D---E (feature)

Run:

git checkout feature
git rebase main

Result:

A---B---C---D'---E' (feature)

👉 D' and E' are new commits (rewritten history).

Key Characteristics

Rewrites commit history
No merge commit
Creates a linear timeline

Advantages

Clean, linear history
Easier to understand logs
Better for debugging and tracking changes

Disadvantages

Can be dangerous if misused
Rewrites history (problematic for shared branches)
Requires more understanding

🔥 Merge vs Rebase — Side-by-Side

Feature	Merge	Rebase
History	Preserved (non-linear)	Rewritten (linear)
Commit creation	Creates merge commit	No merge commit
Safety	Very safe	Risky if shared
Readability	Can be messy	Clean and linear
Use case	Team collaboration	Clean history before merge

⚠️ When to Use Merge

Use merge when:

Working on shared/public branches
Collaborating with a team
You want to preserve full history
You want a safe operation

Example:

git checkout main
git merge feature

⚠️ When to Use Rebase

Use rebase when:

Cleaning up your local commits
Preparing a feature branch before merging
You want a linear history

Example:

git checkout feature
git rebase main

🚨 Golden Rule of Rebase

Never rebase a shared branch

Why?

Because rebase rewrites history. If others are working on the same branch, rebasing will cause conflicts and confusion.

🔧 Interactive Rebase (Advanced)

One of the most powerful features of rebase is interactive mode:

git rebase -i HEAD~3

This allows you to:

Squash commits
Rename commit messages
Reorder commits
Remove unnecessary commits

Example:

pick 1st commit
squash 2nd commit
reword 3rd commit

🧠 Real-World Workflow

Typical Professional Workflow:

Create feature branch
Work and commit changes
Rebase onto latest main
Merge into main

git checkout feature
git rebase main
git checkout main
git merge feature

🔄 Visual Comparison

Merge History (Non-linear)

A---B---C-------M
     \         /
      D---E---

Rebase History (Linear)

A---B---C---D'---E'

🏁 Conclusion

Both merge and rebase are essential tools in Git, and neither is “better” universally—it depends on your workflow.

Use merge for safety and collaboration
Use rebase for clean, readable history

👉 The best developers know when to use each, not just how.

💬 Final Tip

If you're working in a team, always follow your team's Git strategy. Consistency matters more than preference.

Why Git Rebase Will Change How You Use Git Forever

Farhad Rahimi Klie — Tue, 07 Apr 2026 02:35:30 +0000

Introduction

When working with Git, managing commit history is just as important as writing clean code. One of the most powerful — and sometimes misunderstood — tools for this purpose is git rebase.

What is Git Rebase?

At a high level, git rebase is used to move or “replay” commits from one branch onto another.

Instead of merging branches together (like git merge), rebase rewrites commit history to make it look like your work was built on top of another branch from the beginning.

The Core Idea

Let’s say you have:

main:     A --- B --- C
feature:             D --- E

Now, new commits are added to main:

main:     A --- B --- C --- F --- G
feature:             D --- E

If you run:

git rebase main

Git will:

Temporarily remove commits D and E
Move your branch to G
Replay D and E on top of G

Result:

main:     A --- B --- C --- F --- G
feature:                         D' --- E'

Note: D' and E' are new commits (rewritten versions)

Why Use Rebase?

1. Clean History

Rebase creates a linear commit history, making it easier to read and understand.

Instead of this:

      /--- D --- E
A --- B --- C --- M

You get:

A --- B --- C --- D --- E

2. Better for Code Reviews

Reviewing a clean, linear history is much easier than dealing with merge commits.

3. Avoids Unnecessary Merge Commits

Rebase prevents clutter like:

Merge branch 'main' into feature

Rebase vs Merge

Feature	git merge	git rebase
History	Non-linear	Linear
New commits	Adds merge commit	Rewrites commits
Safety	Safe (no rewrite)	Risky if misused
Collaboration	Preferred	Careful usage needed

Basic Commands

Rebase current branch onto another

git rebase main

Interactive Rebase

git rebase -i HEAD~3

This allows you to:

Edit commits
Squash commits
Reorder commits
Remove commits

Example:

pick 123abc Add login
pick 456def Fix bug
pick 789ghi Improve UI

You can change to:

pick 123abc Add login
squash 456def Fix bug
pick 789ghi Improve UI

What Happens Internally?

When you run rebase:

Git finds the common ancestor
Extracts your commits as patches
Resets your branch pointer
Applies patches one by one

This is why commit hashes change — they are new commits.

Handling Conflicts

During rebase, conflicts may occur.

Git will pause and show:

CONFLICT (content): Merge conflict in file.c

Steps to resolve:

Fix the conflict manually
Stage the file:

   git add file.c

Continue:

   git rebase --continue

If needed:

git rebase --abort

Golden Rule of Rebase

❗ Never rebase public/shared branches

Why?

Because rebase rewrites history, and this can break other developers’ work.

When Should You Use Rebase?

Use rebase when:

Working on local feature branches
Cleaning up commits before pushing
Keeping history linear

Avoid rebase when:

Working on shared branches
The branch is already pushed and used by others

Advanced Example: Squashing Commits

Before:

Add feature
Fix typo
Fix bug
Improve code

After squash:

Add feature (clean version)

Command:

git rebase -i HEAD~4

Common Mistakes

1. Rebasing Shared Branches

This can cause major confusion and broken history.

2. Forgetting Force Push

After rebase, you must push with:

git push --force

(or safer:)

git push --force-with-lease

3. Losing Commits

If something goes wrong:

git reflog

You can recover lost commits.

Mental Model

Think of rebase as:

“Take my changes and pretend I wrote them after the latest version of the branch.”

Conclusion

Git Rebase is a powerful tool that:

Keeps history clean
Improves collaboration (when used correctly)
Helps maintain a professional commit structure

But it must be used with discipline and understanding.

If you master rebase, you move from just “using Git” to truly controlling your project history.

Final Tip

Start using rebase in your local workflow first, then gradually introduce it into team practices with clear guidelines.

Happy coding 🚀

Zig Programming Language — Complete Guide

Farhad Rahimi Klie — Sat, 04 Apr 2026 02:57:47 +0000

If you're a systems programmer—or want to become one—Zig is a language you cannot ignore. It is designed as a modern alternative to C, focusing on simplicity, performance, and control without hidden behavior.

1. What is Zig?

Zig is a low-level, general-purpose programming language designed for:

Systems programming
Embedded development
Performance-critical applications

👉 Created by Andrew Kelley
👉 First released in 2015

2. Design Philosophy

Zig is built on a few strong principles:

1. No Hidden Control Flow

Unlike many languages:

No hidden allocations
No exceptions
No implicit behavior

👉 Everything is explicit.

2. Manual Memory Management

Like C:

You control memory
No garbage collector

But safer and clearer.

3. Simplicity Over Abstraction

Zig avoids:

Complex OOP systems
Heavy abstractions

👉 Focus = clarity + control

4. Compile-Time Execution

Zig has powerful compile-time evaluation:

Code can run at compile time
Enables metaprogramming

3. Installing Zig

Download from:

👉 https://ziglang.org

Check version:

zig version

4. Your First Zig Program

const std = @import("std");

pub fn main() void {
    std.debug.print("Hello, Zig!\n", .{});
}

Run:

zig run main.zig

5. Basic Syntax

Variables

var x: i32 = 10;     // mutable
const y: i32 = 20;   // immutable

Type inference:

const a = 5;

Primitive Types

Integers: i32, u64
Float: f32, f64
Boolean: bool
Void: void

Control Flow

If

if (x > 10) {
    // do something
} else {
    // do something else
}

While

while (x < 100) {
    x += 1;
}

For

for (items) |item| {
    std.debug.print("{}\n", .{item});
}

6. Functions

fn add(a: i32, b: i32) i32 {
    return a + b;
}

Multiple Return (Error Union)

fn divide(a: i32, b: i32) !i32 {
    if (b == 0) return error.DivisionByZero;
    return a / b;
}

7. Error Handling (Very Important)

Zig does not use exceptions.

Instead:

Error Union

const result = divide(10, 2) catch 0;

Try Keyword

const result = try divide(10, 2);

👉 If error → return immediately

Error Sets

error{OutOfMemory, InvalidInput}

8. Pointers

Zig uses pointers like C, but safer.

var x: i32 = 10;
var ptr = &x;

Dereference:

ptr.* = 20;

Nullable Pointer

var ptr: ?*i32 = null;

9. Arrays and Slices

Array

var arr = [5]i32{1,2,3,4,5};

Slice (View into array)

var slice = arr[0..3];

👉 Slices are widely used in Zig

10. Structs

const Person = struct {
    name: []const u8,
    age: u8,
};

Usage:

var p = Person{ .name = "Ali", .age = 20 };

11. Enums

const Color = enum {
    Red,
    Green,
    Blue,
};

12. Memory Management

Zig uses allocators explicitly.

Example

const allocator = std.heap.page_allocator;

var memory = try allocator.alloc(i32, 10);
defer allocator.free(memory);

Key Idea

👉 You always know:

Where memory comes from
Who frees it

13. Defer Keyword

Runs code when scope ends:

defer std.debug.print("Done\n", .{});

14. Compile-Time Programming (Zig Superpower)

comptime

fn square(comptime x: i32) i32 {
    return x * x;
}

Example: Generate Code

inline for (0..5) |i| {
    std.debug.print("{}\n", .{i});
}

👉 Executed at compile time

15. No Preprocessor (Unlike C)

Zig replaces macros with:

Functions
comptime

👉 Cleaner and safer

16. Interoperability with C

Zig can directly use C code.

Import C

const c = @cImport({
    @cInclude("stdio.h");
});

👉 You can:

Call C functions
Use C libraries

17. Build System (Built-in)

Zig includes its own build system.

Example:

const std = @import("std");

pub fn build(b: *std.Build) void {
    const exe = b.addExecutable("app", "main.zig");
    exe.install();
}

Run:

zig build

18. Cross Compilation (Very Powerful)

Zig can compile for different platforms easily:

zig build-exe main.zig -target x86_64-linux

👉 No external toolchains needed

19. Testing in Zig

Built-in testing:

test "addition works" {
    try std.testing.expect(add(2,3) == 5);
}

Run:

zig test main.zig

20. Performance

Zig is:

Comparable to C
No runtime overhead
Zero-cost abstractions

21. Zig vs C

Feature	C	Zig
Memory control	Yes	Yes
Safety	Low	Higher
Build system	External	Built-in
Error handling	Manual	Structured
Compile-time	Limited	Powerful

22. Zig vs Rust

Feature	Zig	Rust
Complexity	Low	High
Safety model	Manual	Ownership
Learning curve	Easier	Harder
Control	High	Medium

23. When to Use Zig

Use Zig for:

OS development
Game engines
Embedded systems
Custom databases
High-performance tools

24. When NOT to Use Zig

Avoid if:

You need large ecosystem
You want rapid prototyping
You prefer high-level abstractions

25. Real-World Use Cases

Zig is used in:

Game development
Compilers
CLI tools
Replacing C in systems

26. Roadmap to Master Zig

If you're serious:

Step 1: Basics

Syntax
Types
Control flow

Step 2: Core Systems Concepts

Memory management
Pointers
Allocators

Step 3: Advanced Zig

comptime
Error handling
Build system

Step 4: Real Projects

File parser
HTTP server
Database engine (perfect for you)

27. Final Thoughts

Zig is not trying to replace everything.

👉 It’s trying to fix what’s broken in C
👉 Without adding unnecessary complexity

Core Philosophy:

"No hidden control flow. No hidden memory allocations. No surprises."

If you're a C programmer building systems (like databases):

👉 Zig is one of the best next steps.