Clean Code & Principles
Principles for code that's easy to read, change and trust.
Backend Engineer track
Junior
Write correct code, ship small changes safely, ask good questions.
Core: start here
- Clean CodeCode that's easy to read, change and trust.
- Code SmellA surface sign that the design may have a deeper problem.
- DRY (Don't Repeat Yourself)Every piece of knowledge should have one authoritative place.
- KISS (Keep It Simple)Prefer the simplest solution that works.
- ReadabilityCode is read far more often than it's written.
- Technical DebtThe future cost of shortcuts taken now.
- YAGNI (You Aren't Gonna Need It)Don't build things before you need them.
8 more junior concepts
- Boy Scout RuleLeave the code a little cleaner than you found it.
- ConsistencyDoing similar things the same way across a codebase.
- Dead CodeCode that never runs and should be deleted.
- Deep NestingToo many levels of ifs and loops; flatten them with guard clauses.
- Long MethodA function doing too much; one of the most common smells.
- Premature OptimizationOptimizing before you know where the real bottleneck is.
- Separation of ConcernsEach part of the program handles one distinct concern.
- Structured ProgrammingBuilding programs from sequence, selection and loops instead of goto.
Mid-level
Own a feature end to end without hand-holding.
Core: start here
- CohesionHow closely the parts of a module belong together; more is better.
- CouplingHow much modules depend on each other's internals; less is better.
- Single Responsibility Principle (S)A module should have one reason to change.
- SOLID PrinciplesFive object-oriented design principles for maintainable code.
21 more mid-level concepts
- Broken Windows TheorySmall neglected messes invite bigger ones.
- Chesterton's FenceDon't remove something until you know why it was put there.
- Command-Query SeparationA method should either change state or return data, not both.
- Convention over ConfigurationSensible defaults so you only configure what's unusual.
- Cyclomatic ComplexityA count of independent paths through code; a rough complexity measure.
- Dependency Inversion Principle (D)Depend on abstractions, not concrete implementations.
- Encapsulate What VariesIsolating the parts that change from the parts that stay the same.
- Feature EnvyA method more interested in another class's data than its own.
- God ObjectA class that knows and does too much.
- IdempotenceDoing something twice has the same effect as doing it once.
- Interface Segregation Principle (I)Clients shouldn't depend on methods they don't use.
- Law of DemeterOnly talk to your immediate neighbors; avoid a.b().c().d().
- Liskov Substitution Principle (L)Subtypes must work anywhere their parent type is expected.
- Open/Closed Principle (O)Open for extension, closed for modification.
- Premature AbstractionGeneralizing before you have enough examples, creating the wrong abstraction.
- Primitive ObsessionUsing raw strings and ints where a small domain type belongs.
- Principle of Least AstonishmentCode and APIs should behave the way people expect.
- Program to an InterfaceDepending on what something does rather than which class it is.
- Rule of ThreeTolerating duplication until the third time, to avoid the wrong abstraction.
- Shotgun SurgeryOne change requiring edits in many scattered places.
- Tell, Don't AskTell objects what to do instead of querying their state and deciding for them.
Senior
Own a system, its failure modes, and its trade-offs.
Core: start here
- Hyrum's LawWith enough users, every observable behavior becomes something someone depends on.
4 more senior concepts
- Functional Core, Imperative ShellPure logic in the middle, side effects at the edges.
- Gall's LawComplex systems that work evolved from simple systems that worked.
- Keep Framework Code at the EdgesKeeping business logic free of framework details so it survives framework changes.
- Postel's LawBe conservative in what you send and liberal in what you accept.
Staff
Shape how many teams build, across systems.
- Conway's LawSystems mirror the communication structure of the organizations that build them.
Principal
Set technical direction for the organization.
Nothing here yet.
Data Engineer track
Junior
Build and fix pipelines from clear specs; write correct SQL.
Core: start here
- Clean CodeCode that's easy to read, change and trust.
- Code SmellA surface sign that the design may have a deeper problem.
- DRY (Don't Repeat Yourself)Every piece of knowledge should have one authoritative place.
- KISS (Keep It Simple)Prefer the simplest solution that works.
- ReadabilityCode is read far more often than it's written.
- Technical DebtThe future cost of shortcuts taken now.
- YAGNI (You Aren't Gonna Need It)Don't build things before you need them.
8 more junior concepts
- Boy Scout RuleLeave the code a little cleaner than you found it.
- ConsistencyDoing similar things the same way across a codebase.
- Dead CodeCode that never runs and should be deleted.
- Deep NestingToo many levels of ifs and loops; flatten them with guard clauses.
- Long MethodA function doing too much; one of the most common smells.
- Premature OptimizationOptimizing before you know where the real bottleneck is.
- Separation of ConcernsEach part of the program handles one distinct concern.
- Structured ProgrammingBuilding programs from sequence, selection and loops instead of goto.
Mid-level
Own pipelines and models end to end, including their quality.
- Broken Windows TheorySmall neglected messes invite bigger ones.
- Chesterton's FenceDon't remove something until you know why it was put there.
- CohesionHow closely the parts of a module belong together; more is better.
- Command-Query SeparationA method should either change state or return data, not both.
- Convention over ConfigurationSensible defaults so you only configure what's unusual.
- CouplingHow much modules depend on each other's internals; less is better.
- Cyclomatic ComplexityA count of independent paths through code; a rough complexity measure.
- Dependency Inversion Principle (D)Depend on abstractions, not concrete implementations.
- Encapsulate What VariesIsolating the parts that change from the parts that stay the same.
- Feature EnvyA method more interested in another class's data than its own.
- God ObjectA class that knows and does too much.
- IdempotenceDoing something twice has the same effect as doing it once.
- Interface Segregation Principle (I)Clients shouldn't depend on methods they don't use.
- Law of DemeterOnly talk to your immediate neighbors; avoid a.b().c().d().
- Liskov Substitution Principle (L)Subtypes must work anywhere their parent type is expected.
- Open/Closed Principle (O)Open for extension, closed for modification.
- Premature AbstractionGeneralizing before you have enough examples, creating the wrong abstraction.
- Primitive ObsessionUsing raw strings and ints where a small domain type belongs.
- Principle of Least AstonishmentCode and APIs should behave the way people expect.
- Program to an InterfaceDepending on what something does rather than which class it is.
- Rule of ThreeTolerating duplication until the third time, to avoid the wrong abstraction.
- Shotgun SurgeryOne change requiring edits in many scattered places.
- Single Responsibility Principle (S)A module should have one reason to change.
- SOLID PrinciplesFive object-oriented design principles for maintainable code.
- Tell, Don't AskTell objects what to do instead of querying their state and deciding for them.
Senior
Design the platform's storage, processing and modeling choices.
- Functional Core, Imperative ShellPure logic in the middle, side effects at the edges.
- Gall's LawComplex systems that work evolved from simple systems that worked.
- Hyrum's LawWith enough users, every observable behavior becomes something someone depends on.
- Keep Framework Code at the EdgesKeeping business logic free of framework details so it survives framework changes.
- Postel's LawBe conservative in what you send and liberal in what you accept.
Staff
Shape how the whole organization produces and uses data.
- Conway's LawSystems mirror the communication structure of the organizations that build them.
Principal
Set data strategy and architecture across the company.
Nothing here yet.
Frontend Engineer track
Junior
Build UI that works, ship small changes safely, ask good questions.
Core: start here
- Clean CodeCode that's easy to read, change and trust.
- Code SmellA surface sign that the design may have a deeper problem.
- DRY (Don't Repeat Yourself)Every piece of knowledge should have one authoritative place.
- KISS (Keep It Simple)Prefer the simplest solution that works.
- ReadabilityCode is read far more often than it's written.
- Technical DebtThe future cost of shortcuts taken now.
- YAGNI (You Aren't Gonna Need It)Don't build things before you need them.
8 more junior concepts
- Boy Scout RuleLeave the code a little cleaner than you found it.
- ConsistencyDoing similar things the same way across a codebase.
- Dead CodeCode that never runs and should be deleted.
- Deep NestingToo many levels of ifs and loops; flatten them with guard clauses.
- Long MethodA function doing too much; one of the most common smells.
- Premature OptimizationOptimizing before you know where the real bottleneck is.
- Separation of ConcernsEach part of the program handles one distinct concern.
- Structured ProgrammingBuilding programs from sequence, selection and loops instead of goto.
Mid-level
Own a feature end to end without hand-holding.
Core: start here
- CohesionHow closely the parts of a module belong together; more is better.
- CouplingHow much modules depend on each other's internals; less is better.
- SOLID PrinciplesFive object-oriented design principles for maintainable code.
22 more mid-level concepts
- Broken Windows TheorySmall neglected messes invite bigger ones.
- Chesterton's FenceDon't remove something until you know why it was put there.
- Command-Query SeparationA method should either change state or return data, not both.
- Convention over ConfigurationSensible defaults so you only configure what's unusual.
- Cyclomatic ComplexityA count of independent paths through code; a rough complexity measure.
- Dependency Inversion Principle (D)Depend on abstractions, not concrete implementations.
- Encapsulate What VariesIsolating the parts that change from the parts that stay the same.
- Feature EnvyA method more interested in another class's data than its own.
- God ObjectA class that knows and does too much.
- IdempotenceDoing something twice has the same effect as doing it once.
- Interface Segregation Principle (I)Clients shouldn't depend on methods they don't use.
- Law of DemeterOnly talk to your immediate neighbors; avoid a.b().c().d().
- Liskov Substitution Principle (L)Subtypes must work anywhere their parent type is expected.
- Open/Closed Principle (O)Open for extension, closed for modification.
- Premature AbstractionGeneralizing before you have enough examples, creating the wrong abstraction.
- Primitive ObsessionUsing raw strings and ints where a small domain type belongs.
- Principle of Least AstonishmentCode and APIs should behave the way people expect.
- Program to an InterfaceDepending on what something does rather than which class it is.
- Rule of ThreeTolerating duplication until the third time, to avoid the wrong abstraction.
- Shotgun SurgeryOne change requiring edits in many scattered places.
- Single Responsibility Principle (S)A module should have one reason to change.
- Tell, Don't AskTell objects what to do instead of querying their state and deciding for them.
Senior
Own an app's architecture, performance, and failure modes.
Core: start here
- Hyrum's LawWith enough users, every observable behavior becomes something someone depends on.
4 more senior concepts
- Functional Core, Imperative ShellPure logic in the middle, side effects at the edges.
- Gall's LawComplex systems that work evolved from simple systems that worked.
- Keep Framework Code at the EdgesKeeping business logic free of framework details so it survives framework changes.
- Postel's LawBe conservative in what you send and liberal in what you accept.
Staff
Shape how many teams build, across apps.
- Conway's LawSystems mirror the communication structure of the organizations that build them.
Principal
Set technical direction for the organization.
Nothing here yet.