Writing WordPress code that survives the next developer.

WordPress core is written for maximum compatibility, which means loose typing, string-keyed arrays, and mixed-type parameters are normal throughout the ecosystem. That was a reasonable choice for a CMS built to run anywhere. It is not a reasonable default for a plugin you intend to maintain.

This topic covers the engineering practices we apply to our own plugins and client code: strict types, typed properties, PHPDoc as an enforceable contract rather than decoration, and a static analysis toolchain that runs on every push. It also covers architectural decisions honestly — where a modern approach genuinely earns its complexity and where it is a modernity signal that will cost the next developer a week. The through-line is maintainability under real conditions: onboarding someone new, surviving a core dependency change, and debugging a production edge case at the point the wrong data was passed rather than three layers downstream.