Every realm runs on rules, but the strongest ones are bound by contracts. I used to think of variables as conveniences. A small kindness. A way to avoid repetition and save a few lines of code. That illusion did not survive my first encounter with a stylesheet that had grown without discipline. It was a familiar kind of chaos. Colors that almost matched but never quite aligned. Spacing that shifted unpredictably from section to section. Shadows that seemed to be cast by different light sources entirely. Nothing was broken in isolation, yet nothing belonged together. It felt less like a system and more like a battlefield after too many uncoordinated…
-
-
I used to think CSS was polite. Declarative. Predictable. I would write a rule, refresh the browser, and expect the page to bow respectfully. Instead, it would shrug and do something else. A margin would vanish. A color would refuse to change. A layout would collapse like a tavern table after one too many tankards. What I eventually learned is that CSS is not polite. It is lawful. The cascade is not chaos. It is a rule system. A hierarchy. A quiet tribunal that decides which declaration lives and which one fades into obscurity. Once I stopped fighting it and started studying it like a wizard studies a spellbook, everything…
-
Understanding the rules before bending them. CSS is often treated as unpredictable. Styles override each other. Layout shifts unexpectedly. Developers respond by increasing specificity, rearranging rules, or layering fixes on top of fixes. The problem is rarely CSS itself. The problem is mental models. The CSS Codex is a structured 4 week, 12 part series designed to build a clear, scalable understanding of how CSS actually works. Each article builds on the previous one. Every concept connects forward and backward. By the end, the Codex forms a cohesive system rather than a collection of isolated tips. This is not about tricks.It is about rules.It is about discipline.It is about building…
-
When I started teaching, I thought my job was to know the material. Know it cold. Know it forward and backward. Be ready for every question. What I learned instead is that knowing something and explaining something are two very different skills. That realization followed me back into software development. In the classroom, I could solve a problem in my head in seconds. But when I tried to explain it the same way I solved it – jumping steps, skipping assumptions, compressing logic – I would lose half the room. The students weren’t confused because the material was impossible. They were confused because I had teleported from A to D…
-
For a long time, I treated learning like an endless dungeon crawl. No rests. No pauses. Just door after door, room after room, always pushing forward. If something was labeled advanced, I assumed that’s where I should be heading next. Anything else felt like backtracking – or worse, like I was wasting time. So I skipped ahead. Advanced JavaScript. Advanced frameworks. Advanced patterns. If the topic sounded difficult, prestigious, or slightly intimidating, I convinced myself it was necessary. That’s where real developers lived, right? High-level characters throwing fireballs while I pretended I wasn’t still squinting at the rules. I wasn’t learning badly. I was learning exhausted. And like any party…
