25 Lessons  - Author: [[forwp.dev]] - Full Title: 25 Lessons - URL: https://25.forwp.dev/ ## Full Document [[Full Document Contents/Articles/25 Lessons.md|See full document content →]] ## Document Notes --- tags: - #wordpress - #developer-advocacy - #open-source Author: Ross Wintle Source: forwp.dev Reference: https://25.forwp.dev/ date created: 2025-09-25 00:00 --- # Title: 25 Lessons from 25 Years in 25 Minutes (LoopConf 2025) — Notes ## Table of Contents: - 🔗 [📝 Summary](#-summary) - 🔗 [📖 Main Content](#-main-content) - 🔗 [🗒️ Notes](#-notes) - 🔗 [📖 References](#-references) - 🔗 [🗣️ Paraphrase](#-paraphrase) - 🔗 [📰 Newsletter](#-newsletter) - 🔗 [✅ Action Items](#-action-items) - 🔗 [🧪 Hypotheses](#-hypotheses) - 🔗 [📊 Methodology](#-methodology) - 🔗 [❓ Questions](#-questions) - 🔗 [🔮 Future Research](#-future-research) - 🔗 [💡 Implications](#-implications) - 🔗 [🧠 Learning Styles Assessment](#-learning-styles-assessment) - 🔗 [📊 Accessibility Assessment](#-accessibility-assessment) - 🔗 [🌍 DEIB Assessment](#-deib-deib-assessment) - 🔗 [✅ Logical validity](#-logical-validity) - 🔗 [🔍 DARVO Analysis Prompt](#-darvo-analysis-prompt) - 🔗 [🔍 SEO Evaluation](#-seo-evaluation) - 🔗 [🎯 Conclusion](#-conclusion) ### References: Include a list of sources consulted and cited in the article. ## 📝 Summary: A concise, practical set of 25 lessons distilled from Ross Wintle’s career in engineering, management, and WordPress. Themes: humility around opinions, communication, feedback, standards, testing, inclusivity, ergonomics/productivity, and sustainable craft. Emphasis on team dynamics, actionable habits, and balanced skepticism toward novelty vs. mature tools. ## 📖 Main Content: - Opinions vs facts; cultivate curiosity, evidence, and reversible experiments. - High standards, low expectations: do the right thing consistently without entitlement. - Engineering as a team sport: communication, collaboration, management literacy. - Diversity as strength: better problem-solving, user empathy, and culture. - Practice kindness and specificity in praise and feedback; learn to solicit/give. - Code quality habits: read your own code, avoid over-cleverness, prevent bugs. - Embrace standards, static analysis, tests, and linting to reduce toil. - Learn operators deeply; know precedence/coercion pitfalls and mitigate. - Value old/mature tech; beware novelty churn. - Look outside your bubble; import tools/practices from adjacent ecosystems. - Software can be “finished”; small/static apps; write to forget and to think. - Mentorship: ask for it; movement/ergonomics; invest in quality gear if possible. - Reduce micro-friction: snippets, launchers, hyper-keys, automations. - Maintain an “Awesome/Achievement Log” to track impact and morale. ### 🗒️ Notes - 1. Don’t submit “fun” talk ideas; take talks seriously; coaching helps (Jill Binder). - 2. Opinions are good but not facts; favor open-ended questions; curiosity over adversity. - 3. Opinions can change; use data and demonstrations; run time-limited tests with rollback. - 4. High standards, low expectations (James Clear); keep doing the right thing. - 5. Engineering is a team sport; communication and management literacy matter. - 6. Diversity is strength; implement inclusive hiring, pay equity, training, safe culture. - 7. You don’t know what’s going on with people; give grace. - 8. Say nice things; be specific in praise. - 9. Feedback is fuel; seek/give specific, solicited feedback; Radical Candor concepts. - 10. Read your own code before review/deploy; you’ll catch issues. - 11. Don’t be too clever; optimize for clarity over terse tricks. - 12. Don’t fix bugs—avoid them; requirements, static analysis, tests, linting, standards. - 13. Standards are good; automate style to avoid debate; use PHPCS/Prettier/WordPress rules. - 14. Learn operators deeply; beware precedence/associativity/coercion; mitigate with linting and parentheses. - 15. Old things can be good; mature tools handle edge cases; WordPress/PHP longevity. - 16. Novelty trap critique; tool churn creates new problems. - 17. Look outside your bubble; borrow from Laravel, JS, Go, etc.; tools like Tinkerwell, Ray, AlpineJS. - 18. Software can be finished; small/static app manifesto. - 19. Write to forget; externalize memory; documentation builds institutional knowledge. - 20. Ask for mentorship; be proactive. - 21. Move around; alternate sit/stand; Pomodoro micro-workouts. - 22. Buy good gear if possible; ergonomics and reliability are personal. - 23. Type less, smile more; remove micro-friction with snippets/launchers/shortcuts. - 24. Command-line and browser workflow resources; Wizard Zines, Efficient Linux, bookmarklets. - 25. You are awesome; keep an Achievement Log; private, impact-focused. ## 📖 References: - Radical Candor overview on YouTube - WordPress Coding Standards; PHP CodeSniffer (maintained by Juliette) - PHPStan proposal discussion for WordPress - Smashing Magazine articles on documentation and modern web dev churn - Carl Alexander on testing in WordPress - Prettier “Why Prettier?” and option philosophy - BBC podcasts: Space Shuttle; standing desks - Tinkerwell, Ray, AlpineJS; Basecode Field Guide - Wizard Zines; Efficient Linux at the Command Line ## 🗣️ Paraphrase: - Original idea: “High standards, low expectations… Life is easier when you expect a lot of yourself and little of the world.” Paraphrase: Hold yourself to a high bar, but don’t rely on others or the universe to do the same. Focus on your own craft and consistency; release expectations that the environment will conform. - Original idea: “Don’t fix bugs. Avoid them… requirements, static analysis, testing, linting, code standards.” Paraphrase: Prevent defects upstream. Clarify what you’re building, enforce correctness with analyzers and linters, and validate behavior with tests. Shared standards reduce ambiguity and rework. ## 📰 Newsletter: This week in WordPress and Open Source: Learning, shipping, and thriving. We’re spotlighting Ross Wintle’s “25 Lessons from 25 Years,” a rapid-fire masterclass in sustainable dev: treat opinions as hypotheses, run reversible experiments, keep standards automated, and prefer clarity over cleverness. For learners: revisit testing basics in WordPress (see Carl Alexander’s primers) and explore static analysis with PHPStan alongside WordPress Coding Standards via PHPCS. Community highlight: diversity isn’t a checkbox—it’s a performance multiplier. Audit your hiring, pay practices, and onboarding to widen the contributor pipeline. Tools we’re loving: Tinkerwell, Ray, and AlpineJS to sharpen your debugging and UI edges; plus micro-friction slayers like snippets, command palettes, and hyper-keys. Health check: alternate sit/stand every 30 minutes and sprinkle Pomodoro “micro-workouts.” Pro tip: keep an Achievement Log—future you (and your CV) will thank you. Links: WordPress Coding Standards; Prettier philosophy; Radical Candor overview; BBC on standing desks. ## ✅ Action Items: - For advocacy: Frame “standards are good” as a contributor-experience win; propose PHPCS + WordPress rules + Prettier defaults in contributor guides with pre-commit hooks. - For engagement: Run a “feedback is fuel” workshop using Radical Candor principles; create praise templates emphasizing specificity. - For education: Build a short course on “Avoiding Bugs by Design” covering requirements refinement, static analysis, and unit testing in WP (PHPUnit) with examples. - For OSPO trajectory: Draft a policy on coding standards, security scanning, and documentation (“write to forget” principle) to institutionalize knowledge and reduce risk. - For DEIB: Publish an inclusive hiring checklist (structured interviews, pay transparency, bias mitigation) and offer mentorship pairing (“ask for mentorship” normalized). - For sustainability: Pilot “finished software” criteria for internal tools; prefer small/static deliverables where viable. - For productivity enablement: Provide team licenses for launchers (Raycast/Alfred), snippet tools, and training on keyboard-driven workflows. - Alignment: These actions advance open-source health (quality gates), grow contributors (mentorship, inclusive practices), and strengthen transparency (docs, standards), directly supporting OSPO leadership goals. ## 🧪 Hypotheses: - H1: Automating c ## Highlights - A lot of my thinking on this is wrapped up in my "[manifesto for small, static, web apps](https://rosswintle.uk/2024/02/a-manifesto-for-small-static-web-apps/)". And yes, this site follows those principles. It could be considered "finished". ([View Highlight](https://read.readwise.io/read/01k609dtm2hptmd44h2ncy33sq)) - Tags: