A polished, client-side only reference page for GitHub Pages. Browse timeless coding rules, classic programming laws, famous bug species, and golden developer quotes — all filterable without any backend.
Core ideas that keep code readable, maintainable, scalable, and slightly less haunted.
| Rule | Meaning | Quick Dev Translation |
|---|---|---|
|
DRYDon’t Repeat Yourself
|
Avoid duplication in logic, structure, and knowledge. | If you copied it three times, the code is already judging you. |
|
KISSKeep It Simple, Stupid
|
Prefer simple solutions over complicated cleverness. | The best code is the one nobody has to decode. |
|
YAGNIYou Aren’t Gonna Need It
|
Don’t build features before they are actually needed. | Stop writing phase 9 architecture for a phase 1 button. |
|
SLAPSingle Level of Abstraction
|
Keep code in a function at one abstraction level. | Don’t mix business logic, SQL, regex, and existential pain in one method. |
|
4CsClean Code over Clever Code
|
Readable and maintainable code beats smart-looking tricks. | Future you would like fewer wizard spells and more plain English. |
|
SOCSeparation of Concerns
|
Split responsibilities into distinct parts. | Your controller should not also be therapist, database, and template engine. |
|
GRASPGeneral Responsibility Assignment Software Patterns
|
Patterns for assigning responsibilities to classes and objects properly. | Put logic where it actually belongs instead of wherever it first compiled. |
|
SRPSingle Responsibility Principle
|
A class or module should have one reason to change. | If one file handles login, billing, PDF export, and weather, something went wrong. |
Classic rules, planning traps, and hard-earned observations from software development culture.
“If it works, don’t touch it.”
“If it breaks, it was the guy who left most recently.”
Anything that can go wrong will go wrong, usually during a live demo.
A computer will do exactly what you write, not what you want.
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
Adding manpower to a late software project makes it later.
The first 90% of the code accounts for the first 90% of the development time. The remaining 10% accounts for the other 90%.
Any piece of software reflects the organizational structure that produced it.
Every program eventually expands until it can read mail.
With enough eyes, bugs are easier to spot.
Software slows down faster than hardware speeds up.
Complex, buggy systems are often just bad imitations of Common Lisp.
Fixing one bug causes two new ones to appear.
If software is useless, it will have to be documented. If it is useful, it will have to be changed.
The ultimate argument that ends every bug discussion — until production disagrees.
Any code you haven’t looked at for 6 months might as well have been written by someone else.
Code with so many thin abstraction layers that each one merely passes the call along, creating an unreadable stack.
If you liked it, then you should have put a CI test on it.
There is always one more bug.
The probability of a flawless demo is inversely proportional to the number of viewers and directly tied to the amount of money involved.
If builders built houses the way programmers write programs, the first woodpecker to come along would destroy civilization.
“Don’t call us, we’ll call you.” A classic way to describe inversion of control in frameworks.
No book is ever truly lost by lending — except the ones you actually wanted to keep.
Data expands to fill all available memory.
Nine programmers cannot deliver a baby in a month — a warning against naïve linear staffing assumptions.
Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.
Never worry that something doesn’t work. If everything worked perfectly, you wouldn’t have a job.
Every project contains at least one module that nobody understands, yet nobody dares to remove.
The most serious bug appears exactly 5 minutes before the end of your Friday shift.
If a bug “should practically never happen,” it will happen to the most important client within the first hour after deployment.
The unofficial software bestiary: rare, cursed, expensive, and occasionally profitable.
A bug that accidentally generates money.
A bug you present when someone reports a bug that they themselves caused.
A bug that everyone has tried to fix, but nobody has proven worthy enough to pull from the stone.
A bug that disappears or changes behavior when you try to inspect it.
A hypothetical bug inferred from weird logs and user folklore, but impossible to reliably reproduce.
A catastrophic bug that destroys data, confidence, and probably the weekend.
A feature that seems both fine and broken until someone opens the code, after which it becomes definitely broken.
A protocol bug where one message causes many more, each triggering the same bug again.
A customer-reported bug that keeps returning no matter how many times you prove it isn’t there.
A language made only of spaces, tabs, and newlines. Printed out, the program looks like a blank page.
It has only 8 commands. Writing “Hello World” looks like randomly headbutting the keyboard.
Short truths from the trenches: support debt, debugging guilt, and caffeine-powered software engineering.
“Programming is like sex: one mistake and you have to support it for the rest of your life.”
“Debugging is like being the detective in a crime movie where you are also the murderer.”
“A programmer is a machine that turns caffeine into code.”
“Most programmers spend 10% of their time writing code and 90% wondering why what they wrote doesn’t work.”
“If your code works the first time, you’re probably testing it the wrong way.”
“There are 10 types of people: those who understand binary, and those who don’t.”
“There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”
From AI-era jargon to local classics, debugging rituals, cursed code styles, esolangs, and absurd bug types and project situations.
A style of work where the developer does not write code line by line, but only gives the vibe — describes intent to an AI chatbot and accepts what the model outputs without deep analysis.
A rhetorical question aimed at someone who sounds too synthetic or mindlessly repeats AI-generated answers.
A conscious decision to write something manually, without Copilot or ChatGPT.
Something that looks brilliant and deep at first glance, but after inspection turns out to be empty, AI-generated nonsense.
When a developer does not understand why the code works, but is afraid to change anything so as not to “jinx it.” Fixes happen through ritual copying from Stack Overflow.
Blindly copying design patterns or libraries just because “that’s what Google does,” without understanding whether they fit the project.
Code so tangled and unstructured that changing an icon color causes a database failure in another country.
Code with so many layers of abstraction that getting to the real logic takes all day.
Code that is flat, huge, and served in slices because nobody can understand it as a whole.
A debugging method where you explain the problem step by step to a rubber duck on your desk. Halfway through, you solve it yourself, and the duck contributes exactly as planned: nothing.
Writing conditions like if (4 == foo). It sounds like Yoda and is used to avoid
accidental assignment instead of comparison.
The “catch them all” strategy: using an empty try-catch that captures every
error and ignores it instead of fixing anything.
A team spends three hours arguing about the button color because everyone understands it, while ignoring the critical database architecture bug because that part is hard.
A bug seen only once by one person in their lifetime and never reproduced again under controlled conditions.
A bug that has been in the system so long that users got used to it and now treat it as an official feature. Fixing it triggers customer protests.
Project management by panic, deadlines moved to yesterday, and threats of being fired — resulting in the worst code in company history.
A situation where the program does exactly what the client asked for, but the feature turns out to be completely useless in the real world.
Code looks like a cooking recipe. If the program compiles, in theory you can also cook it.
A cat-meme language where you begin with HAI, end with KTHXBYE, and errors sound like a meme in production.