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? > ## 🧭 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 t Full text of this document omitted because this document is a PDF [Download original file →](https://readwise.io/reader/document_raw_content/507211532), What Is an End-User Software Engineer?, Steven Clarke, 01m4pdd571ktzcp0tnsrj03c0q.