software-engineering slang / jargon / idioms

Repetitive setup or scaffolding code required by frameworks.

😕 Slightly negative

Messy, tangled code with no clear structure or flow.

🚫 Negative

Code with too many layers of abstraction (opposite of spaghetti).

😕 Mildly negative

Many tiny, isolated modules — good modularity, but can overcomplicate.

😅 Mixed

A single class that “does everything.” Violates separation of concerns.

🚫 Very negative

A change that forces you to modify many files or modules at once.

🚫 Negative

When a developer uses one familiar tool or pattern for every problem.

😕 Often negative

A sign of deeper design problems (e.g., long methods, duplicated logic).

😕 Warning

Shortcuts or poor design choices that cause problems later.

🚫 Negative if unmanaged

Rewriting code to improve design without changing behavior.

✅ Positive

Doing a chain of trivial tasks just to get to your real goal. (“To fix X, I first need to…”)

🚫negative

Raw numeric constants in code without explanation.

🚫 Bad practice

Explaining your code out loud (to a person or even a duck) to find bugs.

✅ Positive / funny

Fixing performance before it matters.

Don’t Repeat Yourself vs. Write Everything Twice.

Monolith

A single large application with all logic in one deployable.

Neutral / can be negative

Microservices

Many small, independent services communicating over APIs.

✅ Trendy, complex

Modular Architecture

Encapsulated, reusable components.

✅

Layered Architecture

Presentation / Application / Domain / Infrastructure.

✅

Separation of Concerns

Keeping different responsibilities in different parts of the code.

✅ Best practice

Loose Coupling

Modules/components depend on each other minimally.

✅ Good design

High Cohesion

A module’s parts all relate closely to one purpose.

✅ Good design

Bus Factor

How many people need to “get hit by a bus” before the project is in trouble (low = bad).

🚫 Risk metric

Premature Optimization

Over-optimizing before knowing what’s actually slow.

🚫 Negative

Not Invented Here (NIH)

Refusing to use external tools/libraries, insisting on building everything in-house.

😕 Negative

Dependency Hell

When libraries conflict, break, or are impossible to upgrade.

😩 Very negative

Inversion of Control (IoC)

Framework controls execution flow (e.g., via DI container).

✅ Technical pattern

Event-Driven

Architecture reacting to emitted events instead of direct calls.

✅ Modern approach

Domain-Driven Design (DDD)

✅

CI/CD

Continuous Integration / Continuous Deployment — automated testing & delivery.

✅ Positive

Pipeline

Automated steps (build, test, deploy) for code delivery.

✅ Neutral

Infrastructure as Code (IaC)

Managing servers/config via code (Terraform, etc.).

✅ Positive

Snowflake Server

A server that can’t be easily recreated because it’s manually configured.

🚫 Negative

Immutable Infrastructure

Servers are replaced, not modified in place.

✅ Modern best practice

12-Factor App

Guiding principles for building scalable cloud apps.

✅ Best practice

Bike-Shedding

Spending too much time arguing over trivial details (e.g., variable names).

🚫Negative

Cargo Cult Programming

Copying code/patterns without understanding why they work.

🚫 Negative

Rubber-Stamp Review

Approving code reviews without really looking.

🚫 Negative

Silver Bullet

A mythical “one solution that fixes everything.”

🚫 Unrealistic

MVP (Minimum Viable Product)

The simplest usable version of a product to test ideas.

✅ Neutral/positive

Fail Fast

Design philosophy: detect errors early, not later.

✅ Positive

Bus Factor

(# of people whose loss would endanger the project).

⚠️ Risk indicator

Dogfooding

Using your own product internally to test it.

✅ Positive

A bug that disappears or changes when you try to debug it.

🚫 Funny

Two threads/processes access shared data unexpectedly.

⚠️ Serious

Processes waiting on each other forever.

🚫 Serious

Debugging by explaining code to someone (or something).

✅  Positive

A day devoted to cleaning up code.

✅ Healthy practice

Execute asynchronously and don’t wait for result.

⚙️ Technical term

Old code nobody wants to touch — sometimes critical.

😕 Often negative

New project built from scratch.

✅ Exciting

Project built on top of old systems.

😬 Challenging

The ideal scenario where nothing goes wrong.

✅ Neutral

Rare or extreme input that can break assumptions.

⚠️ Important