What Is an End-User Software Engineer?  🔗 **Source:** [What Is an End-User Software Engineer?](https://readwise.io/reader/document_raw_content/507211532) > [!note]+ Document Notes > tags: [end-user-programming, developer-personas, developer-experience, usability-research, software-engineering] > author: Steven Clarke > source: Steven Clarke (PDF) > reference: Reader PDF 507211532 > date created: 2026-10-12 13:53 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: What Is an End-User Software Engineer? > <!-- deep-read:sections start --> ## 🧭 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-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--what-is-an-end-user-software-engineer) ## 📝 Summary This is a descriptive reading of a short PDF saved to Reader (raw-content id 507211532, about 964 words, 35 labeled paragraphs). The text is a first-person position paper: the author, Steven Clarke of Microsoft Corporation (¶2), argues from the experience of a Visual Studio .Net user-experience team (¶4) and ends with a one-item reference list (¶34-¶35). It has no abstract, no method section and no results table, which fits a workshop position statement or a short submission titled with a question. The text names no venue, workshop, date or year. The latest dated source it cites is April 2005 (¶35), so it was written in or after 2005. This analysis doesn't guess more than that. It is a short expert-experience argument, not a study, and it makes no commercial pitch for a product. - **What happened.** The author describes three personas that a Microsoft team built from about 12 months of observation in usability labs and workplaces (¶12): the Systematic, Pragmatic and Opportunistic developer (¶14-¶25). The paper then asks whether those personas also describe "end user software engineers" (¶32). - **The claim.** Personas should separate people by work style, motivation and characteristics, not by expertise or education (¶10, ¶28). The author saw no relationship between job title and work style among people who build software at work, including a "Rocket Scientist" and a "Surveyor" (¶31). So the end-user versus professional line may not predict how people work, and findings could transfer between the two research communities (¶32). - **Why it matters.** If work style cuts across job titles, then tool and documentation design aimed at "beginners" or "professionals" misses the real split: people who study a technology first versus people who learn only enough to solve the business problem (¶16, ¶20, ¶24). - **Key stakeholders.** Microsoft's Visual Studio .Net user-experience team and product teams (¶4, ¶28), customers who inherit the personas (¶28), researchers in end-user software engineering and in professional developer tools (¶32), and, by extension for Courtney, anyone who writes documentation for people who build software without calling themselves developers. - **Risks and tradeoffs.** The post-hoc claim that the personas generalize to end users is stated as a possibility ("it is possible", ¶32), and it rests on one outside study (¶33). The 12-month observation gives no sample size, no coding method and no count of how many people fit each persona (¶12). The "invaluable" verdict after four or five years of use (¶26) is the team's own judgment, with no outcome measure. - **Bottom line.** A compact, useful reframing: segment by what people do and want, not by how skilled they are. The strongest part is the observation that job titles didn't predict work style (¶31). The weakest part is the evidence base, which is a single team's observation and one cited study. ## 📖 Main content **Context (¶1-¶7).** The author works in a multi-disciplinary team that designs the user experience for the Visual Studio .Net suite (¶4). The suite includes code profilers, debuggers, bug tracking tools, testing tools, code editors and compilers, and it supports Visual Basic .Net, C# and C++. The team designs for a wide range of users and scenarios, from small web applications to large distributed enterprise applications, and the users differ in work style as much as the scenarios differ (¶5). To build shared understanding, the team wrote personas that describe work styles, characteristics and motivations, and that humanize users to raise team empathy (¶6-¶7). **Two points of interest (¶8-¶10).** The author flags two things about the personas: the team needs more than one persona (¶9), and the team doesn't separate personas by expertise, experience or educational background (¶10). **Multiple personas (¶11-¶26).** The personas came from about 12 months of observing people in usability labs and in their own workplaces, across multiple scenarios. Work styles, characteristics and motivations that recurred across many observations formed three personas (¶12-¶13). - The Systematic Developer writes code defensively, protecting it from untrusted parallel processes. This persona develops a deep understanding of a technology before using it and takes pride in elegant solutions (¶14-¶17). - The Pragmatic Developer writes code methodically, learns enough about a technology to use it, and takes pride in building applications that hold up (¶18-¶21). - The Opportunistic Developer writes code in an exploratory way, learns enough to see how a technology solves a business problem, and takes pride in solving business problems (¶22-¶25). The team has used the personas for four or five years and calls them an invaluable resource for a shared picture of the user (¶26). **Work styles, not expertise (¶27-¶28).** The hardest part of spreading the personas inside Microsoft and among customers is correcting the assumption that the three personas map to skill levels or education (¶28). The team chose work styles because they change less over time than expertise does. Observation showed the same work styles in people at varied expertise and education levels, and nobody moves from opportunistic to pragmatic as experience grows (¶28). **Transfer of learning (¶29-¶33).** The observed population was anyone who said they used the team's products or other tools to develop software at work, with no filter on job role or title (¶30-¶31). Many didn't call themselves software engineers. Titles included "Rocket Scientist," "Surveyor," "Customer support," "Software engineer" and "Software developer," and the team saw no link between title and work style (¶31). The author concludes that one or more personas might apply to end-user software engineers, and that finding the commonalities with professional engineers would help transfer learning between the two research communities (¶32). As an example, Beckwith et al (2005) report that females were less willing than males to use new debugging features and spent their time editing spreadsheet formulas instead. The author likens this to opportunistic developers who focus on the business problem over learning a feature, and names a shared challenge: how to get people to use tools that help solve the business problem (¶33). **References (¶34-¶35).** One entry: Beckwith, Burnett, Wiedenbeck, Cook, Sorte and Hastings, on end-user debugging features and gender, from the ACM Conference on Human Factors in Computing Systems, April 2005 (¶35). ## 🗒️ Notes #### 📄 ¶1-¶3 Title, author and opening heading - ¶1: the title is a question, "What is an end-user software engineer?" The paper never gives a one-line definition. It answers by describing how people who build software at work behave. - ¶2: the author's affiliation is Microsoft Corporation. The affiliation sets the perspective: a product team's experience, not an academic study. - ¶3: the Introduction heading. There's no abstract in the capture. #### 📄 ¶4-¶5 The product and the range of users - ¶4: Visual Studio .Net is a suite of profilers, debuggers, bug trackers, testing tools, editors and compilers, across Visual Basic .Net, C# and C++. - ¶5: two example projects, small web applications and a large distributed enterprise application, with users who differ in work style as much as the scenarios do. #### 📄 ¶6-¶8 Why the team built personas - ¶6-¶7: the purpose is a shared understanding of users across a multi-disciplinary team. Personas humanize users and raise empathy among team members. The sentence breaks across two paragraph labels in the capture ("The personas help us" then "communicate these characteristics"), which is a page-break artifact. - ¶8: the author promises to expand on two points, which ¶9 and ¶10 state. #### 📄 ¶9-¶10 The two points of interest - ¶9: one persona isn't enough to cover the work styles, motivations and characteristics observed. - ¶10: the team doesn't split personas by expertise, experience or educational background. This is the thesis the rest of the paper defends. #### 📄 ¶11-¶13 How the personas were built - ¶12: about 12 months of observation in usability labs and in people's own workplaces, across multiple scenarios. Recurring patterns became three personas. - ¶12: no participant count, no sampling description and no analysis method appears in the capture. The result is a qualitative synthesis. - ¶13: the three personas are listed next, "briefly." #### 📄 ¶14-¶25 The three personas - ¶14-¶17, Systematic: defensive code, deep prior understanding of a technology, pride in elegant solutions. - ¶18-¶21, Pragmatic: methodical code, enough understanding to use a technology, pride in applications that hold up. - ¶22-¶25, Opportunistic: exploratory code, enough understanding to see how a technology solves a business problem, pride in solving business problems. - The three differ on three axes: how they code, how much they learn first, and what they take pride in. None of the bullets mention years of experience, degrees or titles. #### 📄 ¶26 Four to five years of use - ¶26: the team has used the personas for four or five years and calls them invaluable for building a shared understanding of the user. - The only evidence offered for that verdict is the team's own continued use. No adoption or outcome figure appears. #### 📄 ¶27-¶28 Differentiate on work styles, not expertise - ¶28: the recurring misreading is that the personas are skill levels. The team chose work styles because they are less liable to change over time than expertise or education. - ¶28: the team's observation is that each work style shows up across expertise and education levels, and there's no path from opportunistic to pragmatic with experience. - This is the paper's most testable claim, and the paper supplies no counts for it. #### 📄 ¶29-¶31 Job titles don't predict work style - ¶30-¶31: the team observed anyone who said they used its products or other tools to develop software at work, and didn't distinguish job roles or titles. - ¶31: titles included Rocket Scientist, Surveyor and Customer support next to Software engineer and Software developer, and the team found no relationship between title and work style. #### 📄 ¶32-¶33 Transfer of learning to end-user software engineers - ¶32: the author suggests one or more personas might apply to end-user software engineers, and that mapping the commonalities with professional engineers would help transfer learning between the two research communities. - ¶33: the example is Beckwith et al (2005), where females were less willing than males to use new debugging features and spent time editing spreadsheet formulas. The author sees the same pattern in opportunistic developers and names the shared challenge as getting people to use tools that help solve the business problem. #### 📄 ¶34-¶35 References - ¶34-¶35: one reference, the Beckwith et al paper from the ACM Conference on Human Factors in Computing Systems, April 2005. It's the only citation in the capture. ## 📚 References The link list for this PDF is empty: the markup has no links and no images, and the PDF has no web URL (Reader raw-content id 507211532). Nothing below comes from a link. The entries are the paper's one printed citation and primary sources for the named entities. **The document** - "What Is an End-User Software Engineer?" by Steven Clarke, Microsoft Corporation. Saved to Reader as a PDF, id 507211532. No URL, venue or year appears in the text. **Cited in the paper (¶33, ¶35)** - Beckwith, L., Burnett, M., Wiedenbeck, S., Cook, C., Sorte, S., and Hastings, M.: Effectiveness of end-user debugging software features: are there gender issues? ACM Conference on Human Factors in Computing Systems, April 2005. This is the printed reference in ¶35. The paper's claim about the study (¶33) is a summary by the author. The study itself is not in the captured text, so this analysis can't confirm the summary. **Primary sources for named entities (not linked in the PDF)** - Visual Studio .Net, Microsoft's development tool suite (¶4). The paper describes the suite as a set of profilers, debuggers, bug trackers, testing tools, editors and compilers. - The persona technique (¶6): a documented design method for describing user groups. The paper's own account of its personas is the only source used here. **Claims with no source in the captured text.** The 12-month observation period (¶12), the four-to-five-year use of the personas (¶26) and the claim that no relationship exists between job title and work style (¶31) rest on the author's team and have no cited data. The captured text has no link or footnote for any of them. ## 🗣️ Paraphrase A Microsoft user-experience team built three personas of people who write code with its tools. After about a year of watching people in labs and at work, the team found three recurring styles. The Systematic developer studies a technology deeply first and writes defensive, elegant code. The Pragmatic developer learns enough to use the technology and writes methodical, dependable code. The Opportunistic developer explores, learns just enough to solve a business problem, and measures success by that problem. The paper stresses that the three personas aren't skill levels. The team saw each style at every level of expertise and education, and nobody grows out of one style into another. It also saw no link between job title and style: the people it watched included a rocket scientist, a surveyor and customer support staff as well as people called software engineers. So the author suggests these styles may describe end-user software engineers too, and that researchers on each side could share findings. The example is a 2005 study in which females were less willing than males to use new debugging features and spent their time editing spreadsheet formulas instead. The author compares that to opportunistic developers, who put the business problem ahead of learning a feature. ## 📰 Newsletter **Job titles don't tell you how someone builds software.** In a short position paper, Steven Clarke of Microsoft describes three personas that the Visual Studio .Net user-experience team built after about 12 months of observing people at work: Systematic, Pragmatic and Opportunistic. The split is by work style, motivation and characteristics, not by expertise or education. The team saw each style at every skill level, and it found no relationship between job title and style among people who build software at work, from "Rocket Scientist" to "Surveyor" to "Software engineer." Why it matters if you write documentation or build developer tools: a "beginner versus expert" split may be the wrong axis. The Opportunistic persona learns just enough to solve the business problem, so a long conceptual page may lose them while a task-first page keeps them. The paper suggests these personas may also describe end-user software engineers, which it leaves as a possibility, not a result. The evidence is one team's observation and one cited 2005 study, with no sample sizes. Treat it as a good question and a usable segmentation idea, then test it with your own readers. ## ✅ Action items These items concern documentation, developer experience and community practice. They don't assess whether the paper's claims are true. #### DevRel - Developer advocacy: when you describe your audience, name work styles (study first, learn enough, solve the problem) next to or instead of experience levels, and say which one a talk or tutorial targets. - Education: draft one tutorial in task-first form for the Opportunistic reader (¶24-¶25) and one concept-first form for the Systematic reader (¶16), then compare which one readers finish. - Developer experience: audit one onboarding flow for a hidden assumption that a newcomer is a junior engineer. The paper's ¶28 says style, not seniority, is the axis. - Developer marketing: avoid "for beginners" and "for experts" labels in copy unless the content really differs by prerequisite knowledge. - Community management: when you ask members how they build things, ask about approach and goals, not job title (¶31). - Internal/external: if you cite this paper, say it is a position paper with no stated venue or year in the capture and that its sample is unreported. #### OSPO - Policy and governance: no direct action from this source; nearest relevance is that contributor-role definitions based on title may miss people who build software without the title (¶31). - License compliance: no direct action from this source. - Security management: no direct action from this source; nearest relevance is the Systematic persona's defensive coding (¶15), which maps to security-minded contributors. - Software inventory: no direct action from this source. - Developer support: write support replies that work for a reader who wants the fix and the reader who wants the reason, with the fix first. - Community engagement: no direct action from this source. - Strategic alignment: no direct action from this source. #### Community - Maintainers: check contribution guides for language that assumes a software-engineer background, since the paper's observed population included people with titles like Surveyor (¶31). - Contributors: no direct action from this source. - Sponsors: no direct action from this source. - Ecosystem: no direct action from this source. #### WordPress - Core: no direct action from this source. - Core Performance: no direct action from this source. - Core AI: no direct action from this source. - Core Program Team: no direct action from this source. - Mobile: no direct action from this source. - Playground: nearest relevance is that a runnable sandbox serves the exploratory, try-it-first style the Opportunistic persona describes (¶23). No action needed. - Community: no direct action from this source. - Training: consider whether lessons assume that learners are studying a technology first (Systematic) or solving a problem now (Opportunistic), and add a task-first path where they don't. - Marketing: no direct action from this source. - Support: no direct action from this source. - Design: no direct action from this source; nearest relevance is the paper's use of personas to build team empathy (¶7). - Documentation: tag pages by the reader's goal (do a task, understand a concept) and check that a task page doesn't force a concept read first. Many WordPress users build sites with code and don't call themselves developers, which matches ¶31. - Photos: none. - TV: none. - Polyglots: no direct action from this source. - Accessibility: no direct action from this source. - Meta: no direct action from this source. - CLI: none. - Hosting: no direct action from this source. - Tide: none. - Openverse: none. - Themes: no direct action from this source. - Plugins: no direct action from this source. #### The WPOCC - Programs: no direct action from this source. - Projects: no direct action from this source. - Funding experiments: none. ### FAIR - Technical independence: no direct action from this source. - Policies and covenants: no direct action from this source. - Productized governance artifacts: no direct action from this source. ## 🧪 Hypotheses 1. Readers of developer documentation sort more reliably by work style (study first, learn enough, solve the problem) than by self-reported experience level, when predicting which page format they finish. 2. Job title doesn't predict work style among people who write code at work, on a larger sample than the paper reports (¶31). 3. Task-first documentation raises completion rates for readers who self-identify with the Opportunistic description, and concept-first documentation doesn't. 4. A reader's work style stays stable across a year of increased experience, so people don't move from opportunistic to pragmatic as they gain skill (¶28). 5. People who build software at work and don't hold a developer title show lower adoption of new debugging or quality features than people with a developer title, and the gap depends on work style more than on title. ## 📊 Methodology - **H1.** Show 60 readers a short description of the three work styles and the same three documentation formats, then record which format each finishes in a timed reading task. Compare prediction accuracy of style against self-reported years of experience. - **H2.** Survey at least 300 people who say they write code at work, with job title, a short work-style instrument built from ¶15-¶25, and education. Test the association between title and style with a chi-square test and report the effect size. - **H3.** A randomized A/B test on one tutorial: task-first versus concept-first, with a one-question style self-description at the start. Measure completion and time to first working result. - **H4.** Re-survey the same respondents from H2 at 12 months and compare style assignment, with the instrument held constant, to check the claim at ¶28 that styles are stable. - **H5.** Record adoption of one new tool feature across title groups and style groups in telemetry or a structured field study. Fit a model with both predictors and compare their contribution. ## ❓ Questions - How many people did the team observe in the 12 months (¶12), and how many fit each persona? - How did the team code an observation into a persona, and did a second researcher check the coding? - If styles are stable (¶28), is a person's style fixed across tasks, or does the same person act opportunistically on one task and systematically on another? - Does the Opportunistic persona describe a preference or a constraint, such as time pressure at work? - Which of the three personas matches the end-user software engineers in the Beckwith study (¶33), and what did the author base the match on? - Why is the gender finding in ¶33 compared with a work-style persona, when the two use different variables? - Did any of the people with titles such as Surveyor (¶31) fall into the Systematic persona? - What did the team change in the product after adopting the personas, and how did it measure the effect that ¶26 calls invaluable? ## 🔮 Future research - **Style instruments.** Build and validate a short questionnaire for work style, so the three personas can be measured and not only described. - **Documentation formats.** Test whether task-first, concept-first and example-first pages differ in completion by work style. - **End-user populations.** Compare personas built from professional developers with personas built from spreadsheet and scripting users, using one shared method. - **Style stability.** Follow the same people for a year or more to check whether style shifts with experience, which the paper denies (¶28). - **Tool adoption.** Study what gets Opportunistic users to adopt a feature that doesn't solve their immediate problem, which is the shared challenge ¶33 names. ## 💡 Implications - **Practice.** Segment documentation readers by goal and approach, not by seniority. The paper gives three approaches that map to three page designs: concept-first for the Systematic reader, procedure-first for the Pragmatic reader, and example-or-task-first for the Opportunistic reader. - **Policy.** Don't gate contributor or reader programs on a job title. The paper observed people with titles from Rocket Scientist to Surveyor writing software at work (¶31). - **Security.** The Systematic persona writes defensively (¶15), and the Opportunistic persona learns just enough to solve the problem (¶24). Security guidance written only as a deep concept page may not reach readers in the second group. Put the safe default in the code sample. - **Education.** Teach the same material in more than one entry path, and don't tie a path to a level label such as beginner. The author reports that readers misread personas as skill levels (¶28), and level labels invite the same misreading. - **Funding.** The paper reports no cost. Building personas took about 12 months of observation (¶12), which is the real price of the method. A smaller team could start with 10 interviews and a reader-goal tag on its docs. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch Reading Ease of about 40 and Flesch-Kincaid Grade Level of about 13, from the average sentence length of 21 to 25 words in the prose paragraphs (¶4-¶5, ¶12, ¶28, ¶31-¶33) and a syllable count that includes terms like "characteristics," "motivations" and "opportunistic." The persona bullets (¶15-¶25) score near grade 8. These are heuristic estimates, not a tool run. #### 👀 Visual learners - Present: none in the capture. The text has no figures, tables or images, and the three personas appear as three headed bullet lists (¶14-¶25). - Improve: add a three-column table comparing how each persona codes, how much each learns first and what each takes pride in. #### 🔊 Aural learners - Present: none; the capture is text only. - Improve: a short audio walk-through of the three personas with one spoken example each. #### 🗣️ Verbal learners - Present: plain declarative prose with short headed sections (Introduction, Multiple personas, Differentiate on work styles, Transfer of learning). - Improve: define "end user software engineer" in one sentence early, since the title asks the question and the text never states a definition. #### 🧩 Kinesthetic learners - Present: none; no exercise or scenario to try. - Improve: give a 5-minute exercise in which a reader sorts three of their own recent tasks into the three personas. #### 🧠 Logical learners - Present: the paper states its two points up front (¶9-¶10) and returns to each in a matching section (¶11-¶28), which makes the argument easy to follow. - Improve: report counts (how many people per persona, how many titles) so the claim in ¶31 can be checked. #### 🧑‍🤝‍🧑 Social learners - Present: the paper is about shared team understanding (¶6) and about learning shared between two research communities (¶32). - Improve: add a discussion question for a team to answer about its own users. #### 🧘‍♀️ Solitary learners - Present: the paper is short, linear and self-contained, and a reader can finish it in about five minutes. - Improve: add a closing summary of the three personas for later reference. #### 🌿 Naturalistic learners - Present: observation in people's own workplaces (¶12) is a field-based method, though the text doesn't describe it in detail. - Improve: describe two or three real workplace observations in a sentence each. ## 📊 Accessibility assessment Judged from the captured text only. The source is a PDF, and the capture shows no layout, tagging, fonts or colors. What the PDF's real structure offers (tags, reading order, alt text, language) can't be seen from this capture. #### Screen reader semantics - Present: section titles are separate short lines (¶1-¶3, ¶11, ¶14, ¶18, ¶22, ¶27, ¶29, ¶34), which suggests headings in the source. The capture renders them as "##" lines, which comes from the pipeline and doesn't prove a tagged PDF. - Improve: confirm the PDF has tags and a logical reading order (WCAG 2.2 AA 1.3.1 Info and Relationships, 1.3.2 Meaningful Sequence). One sentence breaks across two labeled paragraphs (¶6-¶7), and another across ¶30-¶31, which points to a page break splitting text, so verify the reading order across the page break. The document language should be set (3.1.1 Language of Page). #### Keyboard navigation - Present: no interactive controls in the capture. - Improve: if the PDF has links or a table of contents, check that they reach by keyboard (2.1.1 Keyboard). The capture shows none. #### Contrast and readability - Present: unknowable from text. The capture is plain paragraphs and short bullet lists. - Improve: verify text contrast of at least 4.5:1 (1.4.3 Contrast (Minimum)) in the original PDF. #### Text resizing and reflow - Present: a fixed-layout PDF often doesn't reflow, and the capture can't show this one's behavior. The bullets suggest a simple one-column page. - Improve: check that the PDF reflows at 400% zoom or 320 CSS px without two-way scrolling (1.4.4 Resize Text, 1.4.10 Reflow). Reader's text view of the same content serves as a fallback. #### Media and captions - No media referenced in the captured text. The paper has no figures, so there's no image needing alt text (1.1.1 Non-text Content), and no audio or video needing captions. #### Forms and interactions - No forms or interactive elements appear in the capture. #### Standards reference - Likely checks for a PDF of this kind against WCAG 2.2 AA: **1.3.1** and **1.3.2** for tags and reading order across page breaks (the splits at ¶6-¶7 and ¶30-¶31), **3.1.1** for document language, **1.4.3** for contrast, **1.4.10** for reflow. The writing uses uncommon words such as "opportunistic" without a definition, which touches AAA 3.1.3 Unusual Words, and is a plain-language suggestion, not an AA failure. ## 🌍 DEIB assessment #### Cultural breadth - Present: the paper draws on users across many scenarios and job titles (¶5, ¶31) and covers three programming languages (¶4). All examples come from one company's tool suite and one research tradition, and the capture states no region or language of the observed people. - Improve: say where the observations took place and in which languages the people worked, so a reader can judge how far the personas travel. #### Inclusive language - Present: the personas use singular "they" forms ("Prides themselves," ¶17, ¶21, ¶25), and the text avoids gendered pronouns for the personas. - Improve: the gender finding in ¶33 uses "females" and "males" as the groups, and the capture gives no information on non-binary participants. The wording belongs to the cited study as the author reports it, so check the original before repeating it. The word "fictional users" (¶7) is neutral. The phrase "so called professional software engineers" (¶32) sets up a status line the paper is trying to loosen, and "software engineers who work in a company" would be plainer. #### Neurodiversity support - Present: short sections, three parallel three-bullet lists (¶14-¶25) and a clear point-by-point structure help a reader hold the argument. - Improve: add a summary table of the personas and a one-paragraph abstract, since there isn't one. Define "end-user software engineer" up front. #### Representation - Present: the paper names one author and one cited study with six authors (¶35). The observed people appear through job titles, such as Rocket Scientist and Surveyor (¶31), which widens who counts as a builder of software. - Improve: the capture gives no demographic information about the observed people, so the reader can't tell whose work styles the personas reflect. State it. #### Psychological safety - Present: the personas are written as neutral descriptions with pride attached to each (¶17, ¶21, ¶25), and none ranks one style above another. The paper rejects a skill ladder (¶28). - Improve: the one gendered example (¶33) says females were "less willing to use new debugging features." Without context, a reader could take that as a deficit in a group. Say that the paper's own point is that the behavior matches a work style, and that the study's framing is the cited authors'. ## ✅ Logical validity #### Strong reasoning - **Clear thesis and two supports, ¶9-¶10.** The paper states two claims and then defends each with its own section (¶11-¶28), so the reader can check structure against promise. - **Reason for the design choice, ¶28.** The team gives a mechanism for splitting on work style: styles are "less liable to change over time" than expertise. That is a stated reason, and a testable one. - **Observation that cuts against a common assumption, ¶31.** The team reports no relationship between title and style, using concrete titles (Rocket Scientist, Surveyor, Customer support). - **Hedged transfer claim, ¶32.** The author writes "it is possible" and not "it is true" for applying the personas to end-user software engineers, which matches the thin evidence. - **Naming a shared challenge, ¶33.** The comparison with the Beckwith study identifies one shared problem, encouraging the use of tools that help solve the business problem. #### Fallacies No formal fallacy dominates a short position paper. I checked each inference against what the text supports. These are gaps and risks: - **Unsupported generalization, ¶31.** "In addition we did not observe any relationship between job titles and work styles." No counts, no test and no sample size appear in the capture. The claim is plausible and stays an assertion. Fix: report the sample size and the distribution of titles across personas. - **Appeal to own experience, ¶26.** "We have been using these personas for four or five years now and have found them to be an invaluable resource." Continued use isn't evidence of effect. Fix: name one decision the personas changed and the result. - **Weak analogy, ¶33.** The author compares a result about gender and debugging features with the behavior of opportunistic developers: "These results are similar to observations we make." Gender and work style are different variables, and the comparison rests on a surface resemblance. Fix: state which variable in the Beckwith study maps to work style and why. - **Possible confound, ¶28.** The author says styles are less likely to change over time, and that nobody moves from opportunistic to pragmatic with experience. A cross-sectional observation across 12 months can't show that. Fix: follow the same people longer, or soften to "we saw no sign of." - **Scope jump, ¶32.** The paper moves from observed professional and workplace developers to end-user software engineers on the basis that the observed group included some people who don't call themselves software engineers. The hedge ("it is possible") limits the harm, and the observed group's definition of end user isn't given. The captured text contains no instructions addressed to an AI, an assistant or "the reader." The one imperative-like framing is the author's promise to expand on two points (¶8), which is ordinary exposition. #### Tone of voice - Plain, first-person and professional, with an industry practitioner's confidence ("invaluable," ¶26). The viewpoint is an argument for work-style segmentation from inside a product team. The author works for the company that makes the tools described, so the paper carries an employer perspective, and nothing in it sells a product. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response pattern to an accusation. This is a position paper with no accusation in it. Each prong is still checked. - **Deny.** None. The paper doesn't deny fault or contest another party's claim. - **Attack.** None. It addresses a "misreading" of the personas (¶28) as an assumption, not as an attack on a person, and the "so called professional software engineers" phrasing (¶32) is a mild framing, not an attack. - **Reverse victim and offender.** None. No party is cast as a victim or offender. - **Reporter's voice.** The author's voice is expository and advisory, with one hedged conclusion (¶32). ## 🎯 Conclusion This is a short first-person position paper by Steven Clarke of Microsoft, from a Visual Studio .Net user-experience team. It describes three personas, Systematic, Pragmatic and Opportunistic, built from about 12 months of observation (¶12), and it argues that personas should split on work style, not expertise or education (¶10, ¶28). It reports that job titles didn't predict work style among people who develop software at work (¶31), and it suggests that the personas may carry over to end-user software engineers and let two research communities share findings (¶32-¶33). The text names no venue or year, and its latest cited source is April 2005 (¶35). What the paper doesn't establish: the number of people observed, how observations became personas, whether the three styles are stable over time, or whether they describe end-user software engineers at all. The 2005 comparison (¶33) links two different variables. The value is the reframing: segment by what people are trying to do and how much they need to learn to do it. **Next steps for readers who write documentation:** tag each page by the reader's goal and approach, write a task-first path next to a concept-first path for one high-traffic topic, and measure which one readers finish. Treat the personas as hypotheses about your own audience until you've checked them with your own readers. ## 🔄 Refactor Appendix — What Is an End-User Software Engineer? > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: the persona bullet > lists and the reference entry were dropped as descriptive detail. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Personas split by work style, not expertise > [!quote] [¶10] > We do not differentiate personas on expertise, experience or educational background. **Context & use**: - ¶10, the paper's second point of interest and its central design choice. - Use it as the starting claim when asking how a docs or tools team segments its readers. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Work styles change less than expertise > [!quote] [¶28] > We chose to represent work styles, motivations and characteristics as these are less liable to change over time **Context & use**: - ¶28, the stated reason for the choice in H1. It is a testable claim about stability, with no data in the paper. - Pair with H1 so the choice and its reason travel together. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H3] Job titles don't predict work style > [!quote] [¶31] > In addition we did not observe any relationship between job titles and work styles. **Context & use**: - ¶31, the paper's strongest empirical statement. The observed people held titles from Rocket Scientist to Surveyor to Software engineer. - No counts are given in the capture, so cite it as the author's observation. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H4] Shared traits could transfer findings across communities > [!quote] [¶32] > Identifying the commonalities between end user software engineers and so called professional software engineers would help enormously in identifying opportunities for transfer of learning **Context & use**: - ¶32, the paper's hedged answer to its own title question and its reason for caring. - It states a possibility, and the paper doesn't test it. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H5] Tool adoption is the shared challenge > [!quote] [¶33] > The challenges are the same for both groups – how to encourage the use of tools that will help solve the business problem. **Context & use**: - ¶33, the author's takeaway from the Beckwith et al comparison. - Use it as the design question for any docs or feature-discovery work: how does a reader who is focused on the task find the tool that helps? **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Segment readers by approach, not seniority **Claim** (one sentence, Courtney's voice): When I write documentation, I should segment readers by how they approach a problem (study first, learn enough, solve the task) and not by seniority, because seniority labels invite the misreading that one style is a lower skill level. **Evidence pointer**: [[#H1]] · [[#H2]] · [[#H3]] **Scope & conditions**: Holds for audiences that include people who build software without a developer title. Weakens where prerequisite knowledge truly differs, such as a page that needs a working Git setup. The paper gives no counts, so I treat the three styles as hypotheses to test with my own readers. **Links**: - [[Documentation audience segmentation]] — because extends - [[Task-first versus concept-first documentation]] — because applies-in a page built for the Opportunistic reader - [[Skill-level labels in docs]] — because contrasts on beginner and expert labels versus goal labels <!-- atomicity: 1 idea ✓ --> #### [P2] Make the helpful tool findable from the task **Claim** (one sentence, Courtney's voice): A tool or feature that helps a reader solve their problem still goes unused if finding it means leaving the task to learn it, so documentation should surface the feature inside the task page. **Evidence pointer**: [[#H5]] · [[#H4]] **Scope & conditions**: Holds for readers focused on a business problem, such as the Opportunistic persona. Counterexample: readers who study a technology first (¶16), who may want the concept page ahead of the task. The paper's support is one cited study and the author's own observation. **Links**: - [[Feature discovery in developer tools]] — because extends - [[Contextual help in documentation]] — because applies-in task pages that link to the one relevant feature - [[Concept pages as the default entry]] — because contrasts on where a reader starts <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Find the Beckwith et al (2005) paper and check whether the gender-and-debugging finding in ¶33 matches how the author summarizes it #fleeting #inbox - [F2] Open question: what sample size lies behind "no relationship between job titles and work styles" (¶31)? #fleeting #inbox - [F3] Try the three personas as tags on one docs section and see which pages match which style #fleeting #inbox - [F4] Article seed: "Stop labeling docs for beginners," using the work-style argument as the example #fleeting #inbox #articleseed - [F5] Look up where and when this paper appeared, since the PDF text names no venue or year #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Tag five high-traffic docs pages by reader goal and approach, then compare task-first and concept-first versions of one — test the persona idea on real readers #things - [ ] Find the original Beckwith et al (2005) paper and read the gender finding before citing it — verify the ¶33 summary #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/What Is an End-User Software Engineer.md|What Is an End-User Software Engineer? by Steven Clarke]] ## Highlights - - We do not differentiate personas on expertise, experience or educational background. ([View Highlight](https://read.readwise.io/read/01m4rm5e416bph15j15hdca2fj)) - Note: [H1] Personas split by work style, not expertise - Tags: atom/literature/h1 - One of the big challenges we've faced in spreading the word about these personas throughout Microsoft (and amongst our own customers) is correcting the assumption that the three personas describe developers with different levels of skill and educational backgrounds. We chose to represent work styles, motivations and characteristics as these are less liable to change over time as opposed to levels of expertise, educational background etc. Our observations have shown us that the work styles we described in the personas are shared by people with varying levels of expertise and educational background. It is not the case that someone starts out as an opportunistic developer then becomes a pragmatic developer after gaining a certain level of experience and expertise. ([View Highlight](https://read.readwise.io/read/01m4rm5gp20qfbw115hppts0cp)) - Note: [H2] Work styles change less than expertise - Tags: atom/literature/h2 - titles of the people that we observed. Instead, we simply made observations of people who said that they used our products or other tools to develop software while at work. Many of these people did not describe themselves as software engineers. The variety of job titles that people used included 'Rocket Scientist', 'Surveyor', 'Customer support' as well as 'Software engineer', 'Software developer' etc. In addition we did not observe any relationship between job titles and work styles. ([View Highlight](https://read.readwise.io/read/01m4rm5k7bk991an92aw4ckr47)) - Note: [H3] Job titles don't predict work style - Tags: atom/literature/h3 - Given this, it is possible that one or more of the personas we developed would apply equally as well in discussions of end user software engineers. Identifying the commonalities between end user software engineers and so called professional software engineers would help enormously in identifying opportunities for transfer of learning between research focused on either community. ([View Highlight](https://read.readwise.io/read/01m4rm5p1aqc2230yqt3swqgkg)) - Note: [H4] Shared traits could transfer findings across communities - Tags: atom/literature/h3 - For example, Beckwith et al (2005) describe an investigation into the effect of gender on the effectiveness of end user debugging features and report that females were less willing to use new debugging features than males. In addition, females spent their time editing spreadsheet formulas as opposed to learning how to use the new debugging features. These results are similar to observations we make of opportunistic developers who focus on solving the business problem rather than learning how a particular feature works. The challenges are the same for both groups – how to encourage the use of tools that will help solve the business problem. ([View Highlight](https://read.readwise.io/read/01m4rm5rsbj6aqxj36zrshkcwm)) - Note: [H5] Tool adoption is the shared challenge - Tags: atom/literature/h3