Skip to content
My Learning Curve

The Developer Acronym Bingo

- Last update: - 4 min read - 800 words
Edouard Misset
Edouard Misset
Full Stack Web Developer

Introduction

Section titled “Introduction”

Welcome to the Developer Acronym Bingo. The rules are simple: print this page, take it to your next architectural review or sprint planning, and cross them off as you hear them. If you get a full row, stand up and shout “REFACTOR!” (Disclaimer: I am not responsible for you getting fired).

Developers love our acronyms. Sometimes we use them to communicate complex ideas efficiently. Other times, we use them to sound smart while explaining why we’re rewriting the entire codebase for the third time this month.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

~ Martin Fowler (who probably has a high Bingo score)

1. DRY (Don’t Repeat Yourself)

Section titled “1. DRY (Don’t Repeat Yourself)”

The Theory: Every piece of knowledge must have a single representation.
The Reality: If you copy-paste that function one more time, I’m gonna loose it.
In TypeScript, this means using Generics instead of writing UserResponse, ProductResponse, and CatResponse interfaces that look exactly the same.

2. KISS (Keep It Simple, Stupid)

Section titled “2. KISS (Keep It Simple, Stupid)”

The Theory: Systems work best if they are kept simple.
The Reality: Stop trying to use a Strategy Pattern to add two numbers.

// Bad (The "Look at me, I'm an Architect" approach)
class StringPrinterFactory {
  static createPrinter(type: 'console') {
    return new ConsoleStringPrinter();
  }
}
// ... 5 files later ...
printer.print("Hello");


// Good (KISS)
console.log("Hello");

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

Section titled “3. YAGNI (You Aren’t Gonna Need It)”

The Theory: Implement things only when you actually need them.
The Reality: No, you do not need to build a generic, plugin-based, AI-powered CMS engine for your personal blog. Just write the markdown file.

4. SOLID

Section titled “4. SOLID”

The Theory: Five principles for maintainable software design.
The Reality: The reason your PR was rejected.

  • Single Responsibility: Your function does one thing (and hopefully does it well).
  • Open/Closed: Open for extension, closed for modification.
  • Liskov Substitution: If it looks like a duck and quacks like a duck, it shouldn’t explode when you ask it to swim.
  • Interface Segregation: Don’t force clients to depend on methods they don’t use.
  • Dependency Inversion: Depend on abstractions, not concretions. (aka “Why we have so many interfaces”).

5. SOC (Separation of Concerns)

Section titled “5. SOC (Separation of Concerns)”

The Theory: Separating a program into distinct sections.
The Reality: Keep your database queries out of your React components! In a full-stack world, this is why we don’t write SQL inside our useEffect hooks.

6. DDD (Domain-Driven Design)

Section titled “6. DDD (Domain-Driven Design)”

The Theory: Focusing on the core domain and domain logic.
The Reality: Spending 3 weeks arguing about what a “User” actually is before writing a single line of code. In TypeScript, this usually manifests as a folder structure so deep you need a map and a compass to find user.entity.ts.

7. TDD (Test-Driven Development)

Section titled “7. TDD (Test-Driven Development)”

The Theory: Write tests before code (Red -> Green -> Refactor).
The Reality: Writing the code, realizing it works, then writing a test that passes, and pretending you did it in the right order.

8. BDD (Behavior-Driven Development)

Section titled “8. BDD (Behavior-Driven Development)”

The Theory: Describing software behavior in human-readable terms.
The Reality: “Given I am a user, When I click the button, Then nothing happens because the backend is down. 🤣“

9. CRUD (Create, Read, Update, Delete)

Section titled “9. CRUD (Create, Read, Update, Delete)”

The Theory: The four basic functions of persistent storage.
The Reality: 90% of your career. You are a glorified pipe-fitter moving JSON from a database to a frontend and back again. Embrace it.

10. ACID (Atomicity, Consistency, Isolation, Durability)

Section titled “10. ACID (Atomicity, Consistency, Isolation, Durability)”

The Theory: Properties ensuring reliable database transactions.
The Reality: The reason you use PostgreSQL instead of storing everything in a giant JSON file. It ensures that when you send money, it actually leaves your account and arrives in the other one, rather than vanishing into the void.

Resources

Section titled “Resources”
Tags: