The Developer's Glossary: Terms I Wish I Knew Sooner
(...and used for years without realizing!)

Search for a command to run...
(...and used for years without realizing!)

No comments yet. Be the first to comment.
Database connection pooling is a technique used to improve the performance of applications that access a database. Connection pooling allows an application to reuse existing database connections, instead of creating a new connection each time it need...

As web applications continue to grow in popularity, the need for secure API endpoints becomes increasingly important.One mechanism that is often used to protect these endpoints is Cross-Origin Resource Sharing (CORS). However, it is important to unde...

AWS S3 lifecycle configuration allows users to automatically manage the storage and deletion of objects in their S3 buckets. By creating and applying lifecycle rules, users can ensure that their data is stored in the most cost-effective way possible,...

Next.js is a popular framework for building server-rendered React applications. It provides a powerful set of tools and features that make it easy to create high-performance and SEO-friendly web applications. In this article, we will explore some tip...

Hi everyone. If you're like me, you've probably built entire features thinking "I know how this works... but what's the fancy name for it?" After years of shipping code by intuition, I finally sat down to decode the jargon. Here's my expanded cheat sheet – with examples from our daily grind.
1. Compilation
What I did: "Turning my Python/Java into something the computer understands"
The term: Converting human-readable code → machine-executable binary.
# Compile C code
gcc hello.c -o hello # Creates executable 'hello'
Key insight: Syntax errors caught here (missing braces, type mismatches).
2. Runtime
What I fought: "It works until I click that button!"
The term: When your code is executing (post-compilation).
print(10 / 0) # Compiles fine → crashes at runtime
3. Serialization/Deserialization
What I built: "Saving user data to a file or API"
The term: Object ↔ storable format (JSON/XML).
import json
user = {'name': 'Alice', 'active': True}
# Serialize
json_str = json.dumps(user) # → '{"name": "Alice", "active": true}'
# Deserialize
data = json.loads(json_str) # → Python dict
4. Recursion
What I implemented: "Function that calls itself"
The term: Solving problems by self-referential calls.
function factorial(n) {
return (n <= 1) ? 1 : n * factorial(n - 1);
}
factorial(5); // 120
Watch for: Stack overflows without base cases!
5. Polymorphism
What I used: "Same method, different behaviors"
The term: Objects responding differently to the same call.
interface Shape { double area(); }
class Circle implements Shape { area() { /* πr² */ } }
class Square implements Shape { area() { /* side² */ } }
// Same method call:
shape.area(); // Works for Circle/Square
1. Indexing
What I thought: "Magic that makes queries faster"
The term: Search-optimized lookup structures (like book indexes).
-- Without index: Full table scan (slow)
SELECT * FROM users WHERE last_name = 'Smith';
-- Add index
CREATE INDEX idx_lastname ON users(last_name);
-- With index: Direct lookup (fast)
Trade-off: Faster reads, slower writes (indexes update on write).
2. Sharding
What I built: "Splitting the database when it gets huge"
The term: Horizontal partitioning across servers.
Shard 1 (USA): UserID 1-10M
Shard 2 (EU): UserID 10M-20M
Why: Distribute load, scale writes.
3. Normalization
What I did: "Organizing data to avoid duplicates"
The term: Structuring databases to minimize redundancy.
# Before:
Orders [OrderID, CustomerName, CustomerPhone...]
# After normalization:
Orders [OrderID, CustomerID]
Customers [CustomerID, Name, Phone]
4. ACID Transactions
What I needed: "Bank transfers that won't lose money"
The term:
Atomicity: All-or-nothing execution
Consistency: Valid state after transaction
Isolation: Concurrent ops don’t interfere
Durability: Survives crashes
1. Sanitization
What I fixed: "Stopped SQL injection attacks"
The term: Cleaning user inputs to prevent exploits.
// UNSAFE:
$query = "SELECT * FROM users WHERE email = '$_POST[email]'";
// SANITIZED:
$email = mysqli_real_escape_string($_POST['email']);
$query = "SELECT * FROM users WHERE email = '$email'";
2. Hashing
What I implemented: "Storing passwords safely"
The term: One-way transformation of data → fixed-size string.
import hashlib
hashlib.sha256("password123".encode()).hexdigest()
# → "ef92b778bafe771e8..." (stored instead of plaintext)
3. Middleware
What I coded: "Auth check before processing requests"
The term: Intercepting HTTP requests/responses.
// Express.js middleware
app.use((req, res, next) => {
if (!req.user) return res.status(401).send("Unauthorized");
next(); // Proceed if authenticated
});
1. Overfitting
What I saw: "Model aced training data but failed with new inputs"
The term: Memorizing noise instead of learning patterns.
Fix: Regularization, dropout layers, more data.
2. Embeddings
What I used: "Turning words into numbers"
The term: Dense vectors capturing semantic meaning.
# "King" - "Man" + "Woman" ≈ "Queen"
embedding_king = [0.8, -0.2]
embedding_man = [0.6, 0.1]
result = embedding_king - embedding_man + [0.9, 0.3]
# ≈ [1.1, 0.0] → Near "Queen"
3. Gradient Descent
What I tuned: "Slowly adjusting model weights to reduce error"
The term: Optimization algorithm following error slopes.
Analogy: Finding valley by walking downhill.
1. Circuit Breaker
What I built: "Stop calling downed services"
The term: Fail-fast pattern to prevent cascading failures.
if errorRate > 70% {
openCircuit() // Block requests
time.Sleep(30 * time.Second)
retry()
}
2. Pub/Sub
What I designed: "Decoupled service communication"
The term: Publishers → Topics ← Subscribers.
Payment Service → (order_created) →
↓ ↓
Email Service Analytics Service
3. CAP Theorem
What I debated: "Can a distributed system be perfect?"
The term: Choose 2 of 3:
Consistency (all nodes see same data)
Availability (every request gets response)
Partition tolerance (works despite network failures)
1. CORS
What I debugged: "Blocked by Same-Origin Policy"
The term: Browser mechanism for cross-domain requests.
# Response header allowing your frontend
Access-Control-Allow-Origin: https://your-app.com
2. SSR vs CSR
What I compared:
SSR (Server-Side Rendering): Pre-render HTML on server (Next.js)
CSR (Client-Side Rendering): Build DOM in browser (React/Vue)
| My Old Description | Official Term | Realization |
| "Making data fit in 0-1" | Normalization (ML) | Scale features for stable training |
| "Caching DB queries" | Materialized Views | Pre-computed results stored as table |
| "AI seeing cats everywhere" | Overfitting | Model memorizes instead of generalizing |
| "Retrying failed API calls" | Exponential Backoff | Wait 2s → 4s → 8s → ... between retries |
| "Turning configs into code" | Infrastructure as Code | Terraform/CloudFormation |
"Knowing terms won't make you a better developer – but communicating ideas and understanding docs will save hours of reinventing wheels."
Bookmark this. Share it with your team. Next time someone says "We need to shard with consistent hashing after JIT compilation," you’ll nod instead of frantic-Googling. 😉
[Drop a comment with terms that once confused you!]