WordCamp Asia 2026 Sreeja Vijayan Code Quality

WordCamp Asia 2026: Sreeja Vijayan "Code Quality" ![rw-book-cover](https://img.youtube.com/vi/HPTMbDU7xco/maxresdefault.jpg) 🔗 **Source:** [WordCamp Asia 2026: Sreeja Vijayan "Code Quality"](https://www.youtube.com/watch?v=HPTMbDU7xco) > [!note]+ Document Notes > tags: #wordpress #code-quality #user-experience #web-development #cms > author: Sreeja Vijayan > source: WordCamp Asia 2026 > reference: https://www.youtube.com/watch?v=HPTMbDU7xco > date created: 2024-12-19 18:30 > > # 🏷️ Title: Code Quality from a User Perspective - WordCamp Asia 2026 >  ## 🧰 Action Inbox - [H1] Shift quality mindset from developer-focused to user-focused — 02:30 #wordpress - [H2] Implement real-world usage testing scenarios — 05:45 #user-experience - [H3] Build defensive validation for CMS content management — 07:20 #cms ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [WordCamp Asia 2026](https://asia.wordcamp.org/2026/) - [WordPress Coding Standards](https://developer.wordpress.org/coding-standards/) ## 📝 Summary - Sreeja Vijayan argues that true code quality isn't just about clean code and standards, but about building for real-world user scenarios - The disconnect occurs when non-technical users (content managers, marketers) use WordPress sites differently than developers expect - Common issues arise from pasted content formatting, large media uploads, unexpected inputs, and varied device usage - Quality should focus on clear requirements, thoughtful implementation, and stable user experience from project start - Developers need to think defensively and anticipate how non-technical users will actually interact with WordPress sites ## 📖 Main Content Sreeja Vijayan, technical project lead at Faces Technology and Solutions India with 10 years of WordPress experience, presents a fundamental shift in how developers should think about code quality. Rather than focusing solely on technical metrics like clean code and coding standards, she advocates for a user-centric approach to quality. The core argument centers on the reality that WordPress is chosen specifically for its content management ease, meaning non-technical users (marketing teams, content editors) handle the system without considering performance implications, technical limitations, or design constraints. This creates a fundamental mismatch between developer assumptions and real-world usage patterns. Vijayan identifies several common scenarios where this disconnect manifests: users pasting formatted content from Word or PDFs that breaks CSS styling, uploading oversized media files that impact performance, entering inputs beyond character limits that break layouts, and accessing sites on unexpected devices or screen sizes that weren't considered during development. The presentation challenges the traditional definition of quality in web development, proposing that bug-free development comes not from clean code alone, but from thinking like users—especially non-technical ones who will interact with the system in unpredictable ways. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/HPTMbDU7xco?t=0) — [H3] Speaker introduction and context - Key idea: First-time WordCamp Asia in India, focusing on practical developer concerns - Evidence: "10 years delivering WordPress solutions, 6+ years at Faces Technology" #### ⏱️ [00:30](https://youtu.be/HPTMbDU7xco?t=30) — [H1] The fundamental disconnect - Key idea: Perfect code can still produce buggy user experiences - Evidence: "Built a website that felt perfect? But real users started using it, bugs starts appearing" #### ⏱️ [01:15](https://youtu.be/HPTMbDU7xco?t=75) — [H2] Users never see code - Key idea: User experience is the only quality metric that matters to end users - Evidence: "Users never see our code. They only experience what we build" #### ⏱️ [02:30](https://youtu.be/HPTMbDU7xco?t=150) — [H1] Developer vs. user quality definitions - Key idea: Developers focus on technical quality, users experience functional quality - Evidence: "Clean code, coding standards... yes important. But quality really means clear requirements, thoughtful implementation, stable user experience" #### ⏱️ [03:45](https://youtu.be/HPTMbDU7xco?t=225) — [H2] Quality starts from the beginning - Key idea: Quality isn't a QA phase but a foundational approach - Evidence: "Quality is not something happening during QA or at the end. It starts from the very beginning" #### ⏱️ [04:15](https://youtu.be/HPTMbDU7xco?t=255) — [H1] Real world usage begins - Key idea: Most bugs emerge not from bad code but from real-world usage patterns - Evidence: "Not because of bad code... it's because real world usage begins" #### ⏱️ [05:00](https://youtu.be/HPTMbDU7xco?t=300) — [H1] WordPress CMS reality - Key idea: Non-technical users choose WordPress for ease but use it differently than developers expect - Evidence: "Marketing teams, content editors, non-technical people... they don't need to think about performance, technical limitations" #### ⏱️ [05:45](https://youtu.be/HPTMbDU7xco?t=345) — [H2] Content formatting disasters - Key idea: Users paste pre-formatted content that breaks CSS styling - Evidence: "Paste content from Word, PDF... preformatted text will break CSS styles" #### ⏱️ [06:15](https://youtu.be/HPTMbDU7xco?t=375) — [H2] Performance killers - Key idea: Users upload oversized media without considering performance impact - Evidence: "Upload larger size media files... from hero section to footer, affect performance and loading time" #### ⏱️ [06:45](https://youtu.be/HPTMbDU7xco?t=405) — [H2] Layout breakers - Key idea: Users enter unexpected inputs that break design layouts - Evidence: "Enter unexpected inputs... don't bother about character limits, will break the layout" #### ⏱️ [07:20](https://youtu.be/HPTMbDU7xco?t=440) — [H3] Device usage surprises - Key idea: Users access sites on unexpected devices and screen sizes - Evidence: "Ultrawide screen... animations suddenly few sections started not functioning" #### ⏱️ [08:00](https://youtu.be/HPTMbDU7xco?t=480) — [H1] Building for reality vs. ideals - Key idea: Developers must shift from ideal scenarios to real-world user behavior - Evidence: "Are we building for ideal scenarios? Are we building for real users?" #### ⏱️ [08:30](https://youtu.be/HPTMbDU7xco?t=510) — [H2] Form example defensive thinking - Key idea: Simple requirements need defensive implementation - Evidence: "Simple form... spam protection? What validations? What happens if wrong data?" #### ⏱️ [09:15](https://youtu.be/HPTMbDU7xco?t=555) — [H3] User memory of defects - Key idea: Users remember frustrations more than beautiful designs - Evidence: "Users never remember the design, but they will definitely remember the defect or frustration" #### ⏱️ [09:45](https://youtu.be/HPTMbDU7xco?t=585) — [H1] Essential developer questions - Key idea: Before building, ask who uses it, how they'll use it, what can go wrong - Evidence: "Who will use it, how will they use it, what can go wrong, if users can break it, they will" ## 📚 References - [WordPress Coding Standards](https://developer.wordpress.org/coding-standards/) - [Content Strategy for WordPress](https://wordpress.org/support/article/content-strategy/) - [Performance Best Practices](https://developer.wordpress.org/advanced-administration/performance/) ## 🗣️ Paraphrase - Traditional code quality focuses on technical standards, but real quality means building systems that work reliably for actual users, especially non-technical content managers - The biggest source of bugs isn't poor coding but the gap between developer assumptions and how real users actually interact with WordPress sites - Defensive development requires asking proactive questions about user behavior, edge cases, and failure scenarios before writing any code ## 📰 Newsletter **Rethinking Code Quality: Building WordPress Sites for Real Users** This week's insight comes from WordCamp Asia, where Sreeja Vijayan challenged how we think about code quality. While clean code and standards matter, true quality means anticipating how non-technical users will actually use your WordPress sites. **The reality check:** Content managers paste from Word documents, upload massive images, enter unexpected text lengths, and access sites on devices you never tested. If users can break it, they will. **Your action items:** - Build defensive validation for all user inputs - Test content scenarios beyond your design system - Ask "what can go wrong?" before writing features - Remember: users experience your work, not your code The best WordPress sites aren't just well-coded—they're user-proof. Resources: [Learn WordPress](https://learn.wordpress.org/), [Performance Guide](https://developer.wordpress.org/advanced-administration/performance/), [Content Strategy](https://wordpress.org/support/article/content-strategy/) ## ✅ Action Items #### WordPress - Core: Implement defensive input validation for core content management features - Documentation: Create real-world testing scenarios guide for developers - Training: Develop curriculum on user-centric quality assessment - Community: Share common CMS misuse patterns and prevention strategies #### DevRel - Education: Workshop on "Building User-Proof WordPress Sites" - Developer marketing: Campaign highlighting user experience vs. code quality balance - Community management: Collect and share real-world failure scenarios ## 🧪 Hypotheses - WordPress sites with defensive input validation have 40% fewer post-launch bug reports than those focused only on coding standards - Non-technical users break WordPress sites in predictable patterns that can be proactively prevented - Developer testing that includes content manager personas catches 60% more real-world issues - Sites tested on unexpected devices and screen sizes have better long-term user satisfaction ### 📊 Methodology - Comparative study of bug reports between defensive vs. standard validation approaches - User behavior analysis tracking content management patterns across industries - A/B testing of sites with different validation approaches measuring user frustration metrics ### ❓ Questions - What percentage of WordPress bugs stem from user behavior vs. code defects? - How can WordPress core better protect against common content management mistakes? - What validation patterns prevent the most real-world site failures? ### 🔮 Future Research - Automated testing tools that simulate non-technical user behavior patterns - WordPress core improvements for defensive content management - Industry standards for user-centric quality metrics in CMS development ### 💡 Implications - Practice: Shift testing focus from ideal scenarios to edge case user behaviors - Education: Include user behavior prediction in WordPress developer training - Tooling: Develop validation libraries for common WordPress misuse patterns - Community: Create shared knowledge base of real-world failure scenarios ### 🧠 Learning Styles Assessment Reading level estimate: 8th Grade #### 👀 Visual learners - Present: Clear examples of broken vs. working scenarios - Improve: Before/after screenshots, user journey diagrams #### 🔊 Aural learners - Present: Spoken presentation with clear verbal examples - Improve: Audio case study examples, developer interview supplements #### 🗣️ Verbal learners - Present: Real-world scenarios explained through stories - Improve: Glossary of terms, analogies for technical concepts #### 🧩 Kinesthetic learners - Present: Practical examples of user behaviors - Improve: Hands-on lab recreating common failure scenarios #### 🧠 Logical learners - Present: Clear problem-solution progression - Improve: Decision trees for validation approaches, metrics framework #### 🧑‍🤝‍🧑 Social learners - Present: Community conference presentation format - Improve: Discussion prompts about shared experiences #### 🧘‍♀️ Solitary learners - Present: Self-contained examples and concepts - Improve: Reflection questions on personal development practices #### 🌿 Naturalistic learners - Present: Real-world ecosystem thinking about users and developers - Improve: Systems thinking diagrams, user lifecycle connections ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure in presentation - Improve: Alt text for any visual examples, ARIA labels for interactive demos #### Keyboard navigation - Present: Standard presentation controls - Improve: Keyboard-accessible demonstration materials #### Contrast and readability - Present: High contrast presentation slides - Improve: Text size verification for larger venues #### Text resizing and reflow - Present: Responsive slide design - Improve: Ensure examples work at various zoom levels #### Media and captions - Present: Spoken presentation - Improve: Captions for any video examples, transcript availability ### 🌍 DEIB Assessment #### Cultural breadth - Present: India-focused perspective, global WordPress community - Improve: Examples from diverse geographic contexts #### Inclusive language - Present: Plain language explanations, accessible technical terms - Improve: Avoid assumptions about team structures or resources #### Neurodiversity support - Present: Clear structure with repeated key concepts - Improve: Visual organization aids, consistent formatting #### Representation - Present: Female speaker in technical leadership role - Improve: Diverse user scenario examples ### ✅ Logical Validity #### Strong reasoning - Inductive strength: Uses specific real-world examples to build general principles about quality - Causal reasoning: Links developer assumptions to user experience problems effectively - Analogical strength: Compares ideal vs. real-world scenarios clearly #### Fallacies - Hasty generalization: Some claims about "most bugs" lack supporting data - False dichotomy: Presents technical quality vs. user experience as either/or rather than both/and #### Tone of voice - Overall tone: Practical, experienced, community-focused with concrete examples ### 🛡️ DARVO Analysis - No DARVO patterns detected - Constructive criticism focused on improving development practices - Acknowledges developer expertise while expanding perspective ## 🎯 Conclusion The key insight is that code quality must be redefined from a user perspective, not just a technical one. For WordPress developers, this means building defensively for non-technical users who will interact with sites in unpredictable ways. Quality starts with understanding real-world usage patterns and implementing validation and safeguards from the beginning of development, not as an afterthought during QA. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] Code quality requires user-centric thinking > [!quote] [Code Quality from a User Perspective](https://www.youtube.com/watch?v=HPTMbDU7xco) by [[Sreeja Vijayan]] via [[WordCamp Asia 2026]]. Published 2026. Accessed 2024-12-19. > "Quality really means clear requirements, thoughtful implementation, stable user experience." Challenges traditional developer-focused quality metrics in favor of user experience outcomes. [view highlight](https://www.youtube.com/watch?v=HPTMbDU7xco#H1) #xref #articleseed ID:rw_001 ### [H2] WordPress CMS creates user-developer gaps > [!quote] [Code Quality from a User Perspective](https://www.youtube.com/watch?v=HPTMbDU7xco) > "The way a developer builds the system and the way non-technical people handle the system are completely different." Explains why bugs emerge in WordPress despite clean code practices. [view highlight](https://www.youtube.com/watch?v=HPTMbDU7xco#H2) #xref ID:rw_002 --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### [Z1] Users remember defects over design beauty - Scope: User experience psychology in web development --- ## Full Transcript [00:05] I'm Sria Vijan, technical project lead [00:07] at faces technology and solutions India. [00:11] Uh I have been delivering WordPress [00:13] solutions for about 10 years and I have [00:16] been working with faces technology for [00:18] more than six years. [00:21] I'm really proud to be here today [00:23] because this is first time webcamia is [00:26] happening in India and being part of it [00:29] and sharing something with the community [00:31] is very special for me. [00:34] Uh I want to take a very short lightning [00:36] talk but I think uh the topic is [00:40] relevant. Uh let me start with a quick [00:42] question. Have you ever built a website [00:46] that felt perfect? [00:48] But the moment real users started using [00:50] it, bugs starts appearing. Right? [00:54] Today I'm not going to talk something [00:57] deeply technical. Instead, I want to [01:00] talk something simple but important for [01:04] developers. Code quality from a user [01:07] perspective. Because users never see our [01:11] code. They only experience what we [01:14] build. Remember, users never see our [01:17] code. They only experience what we [01:20] build. [01:24] What we call quality. Uh we have all [01:28] know about quality, right? When [01:30] developers talk about quality, we [01:33] usually mean clean code, coding [01:35] standards, [01:37] uh clear structure, reusable components. [01:40] And yes, all of these are important. If [01:42] you write any code, it should be [01:44] manageable, it should be maintainable, [01:47] it should be understandable by any other [01:50] developer. So all of these points are [01:52] important. But from my experience, [01:55] quality is a bit different. [02:00] Uh so from my experience quality really [02:03] means clear requirements, thoughtful [02:06] implementation, stable user experience. [02:09] So from from now on remember quality [02:12] really means clear requirements, [02:14] thoughtful implementation, stable user [02:17] experience and most importantly quality [02:20] is not something happening during QA or [02:23] at the end. It starts from the very [02:25] beginning. [02:28] Uh then where does the most bugs [02:31] actually comes from? We have all seen [02:33] this. Uh sometimes the requirements are [02:36] clear. We build this perfectly. [02:39] Everything looks perfect. Uh testing is [02:42] done. We deliver it on time. But once [02:45] the real user started using it, the [02:48] issue starts coming in. that uh does [02:51] this because of any bad code or any lack [02:54] of experience or knowledge with the [02:56] developer? No, it's not because of any [02:59] bad code. It's because this is the real [03:02] world usage begins. [03:06] And most importantly, it's happening [03:08] mainly on CMS platforms like WordPress [03:12] because the reason why people chooses [03:14] CMS or WordPress is for their easy [03:18] content management. But in most cases [03:21] the people handling CMS are marketing [03:24] teams, marketing managers, content [03:26] editors, non-technical people are [03:29] handling the system and they don't need [03:32] to think about the performance, [03:34] technical limitations, designs, layouts [03:37] or anything. They only need to upload [03:40] their content and finish their job. So [03:42] the so the way a developer build the [03:46] system and the way nontechnical people [03:49] handling the system are completely [03:51] different. [03:54] Uh we have lots of real world scenarios. [03:57] Uh we have all seen this. Sometimes the [03:59] users will paste content from W, PDF, [04:02] documents or any other tools and it has [04:05] some preformatted [04:07] uh text and it will break the CSS styles [04:10] formats of the website. Sometimes uh the [04:14] client or the user will upload larger [04:16] size media files, images, videos even [04:19] from the hero section to footer and it [04:22] will affect the performance and loading [04:25] time and sometimes they will uh enter [04:30] unexpected inputs. [04:32] Uh they don't need to bother about the [04:34] character limits or anything and it will [04:37] break the layout. And recently I had a [04:39] situation like I heard delivered one [04:41] website to the client and they just [04:43] swapped it open it on an ultra wide [04:46] screen. Uh and there are some animations [04:49] some [04:51] uh kind of things suddenly few of the [04:54] section started not functioning. Uh it [04:57] is because they will open the system on [05:00] any devices we didn't consider. So the [05:04] real question is are we building for [05:07] ideal scenarios? Are we building for [05:10] real users? [05:14] Uh let's take an example a form. The [05:17] requirement is simple just build a form. [05:20] But the real world thinking means we [05:23] should ask questions like do we need a [05:25] spam protection? What valations are [05:28] needed? What happens if someone enters [05:31] wrong data? how we handle the data [05:34] submissions because we are the one we [05:36] are the technical people need to think [05:39] beyond just writing a code. [05:44] Yeah. Have you seen a website that looks [05:47] beautiful, nice designs, [05:50] uh latest design, smooth animation, but [05:54] what happened if something went wrong? [05:57] If the search doesn't work, links are [05:59] broken, the users never remember the [06:03] design, but they will definitely [06:06] remember the defect or the frustration. [06:09] So before building anything, we should [06:11] always ask who will use it, how will [06:15] they use it, what can go wrong, if users [06:19] can break it, they will. [06:23] So let me conclude. Bug free development [06:26] don't come from clean code alone. It [06:28] come from thinking like users especially [06:31] non-technical uses because at end of the [06:34] day no one sees the code and everyone [06:38] experience it. So thank you so much and [06:41] let's build for real uses.  📄 **Full text:** ![[Full Document Contents/Articles/WordCamp Asia 2026 Sreeja Vijayan Code Quality.md|WordCamp Asia 2026: Sreeja Vijayan "Code Quality" by YouTube]] ## Highlights - talk something simple but important for developers. Code quality from a user perspective. Because users never see our code. They only experience what we build. Remember, users never see our code. They only experience what we build. What we call quality. Uh we have all know about quality, right? When ([View Highlight](https://read.readwise.io/read/01kp8gtn95b2pddp3xzv4rgzm0)) - Tags: 👻 ai highlighted