Posts Tagged ‘Positron’
[PyDataGlobal2025] Tools, Empathy, and the Craft of Building Delightful Data Experiences
Lecturer
Isabel Zimmerman is a Senior Software Engineer at Posit, PBC (formerly RStudio). She was the first full-time Python open-source hire at the company and began her tenure building MLOps packages before shifting focus to the Python experience inside interactive development environments. Her current work centers on Positron, a next-generation data-science IDE. Beyond computing she is an avid fantasy reader and bookbinder, interests that inform her view of tools as objects that can carry quiet power across generations of users.
Abstract
Every practitioner occupies a position on the continuum between tool user and tool builder. This keynote explores that continuum through the dual lenses of technical excellence and human empathy. Drawing on concrete examples from the Positron IDE and the broader open-source Python ecosystem, it articulates a set of “hard skills” (modularity, reproducibility, flexibility) and “soft skills” (knowing the user, discoverability, small improvements with large impact, and explaining one’s work). The argument is that tools become delightful only when both categories are deliberately cultivated, and that the barrier to becoming a builder has never been lower.
From Consumer to Creator: Reframing Everyday Practice
A tool is defined simply as anything that carries out a particular function. Under that definition most data scientists already build tools—whether a Git alias that corrects a habitual typo, a reusable function shared in Slack, a dashboard that informs business decisions, or a private utility that solves a personal measurement problem. The psychological barrier that prevents many practitioners from identifying as builders is therefore largely artificial. Framing the act of extraction and encapsulation as tool construction lowers that barrier and simultaneously improves personal productivity and future reproducibility.
The transition from pure consumer to occasional creator is further eased by contemporary language models. Functions that once required manual packaging can now be sketched in natural language and refined iteratively. The resulting artifacts need not be public; a private package that accelerates one’s own daily workflow is already a contribution to the wider ecosystem because it reduces friction for at least one user—oneself.
Hard Skills of Tool Design
Three technical properties form the backbone of robust tools. Modularity allows a system to grow with its users. By leaning on existing community infrastructure—FastAPI for REST endpoints, Code OSS for the editor substrate—builders can concentrate effort on the distinctive value they wish to add. The same modular surface also supplies clear extension points, encouraging specialized packages that solve narrow, high-value problems.
Reproducibility remains a foundational requirement of trustworthy science. Graphical exploration interfaces are powerful, yet they risk introducing non-reproducible click sequences. Positron’s data explorer illustrates one resolution: every filter and sort operation is internally represented so that a single button can emit executable code that recreates the identical view. The cycle of exploration is thereby closed inside a language rather than left as a sequence of manual steps.
Flexibility must be tempered by the Zen of Python’s preference for simplicity. Functions that accept an ever-expanding union of input types quickly become unmaintainable. Preferring a small number of well-defined entry points and composing them later yields systems that remain extensible without collapsing under their own complexity. Context windows supplied to language models follow the same principle: start with a carefully chosen default set of information and allow the user to add or remove context explicitly.
Soft Skills and the Human Side of Interfaces
Technical excellence alone does not produce tools that people love. Empathy for the intended user is equally decisive. Data work is characterized by iterative exploration of uncharted territory, whereas classical software engineering often constructs well-specified structures in known domains. An interface optimized solely for the latter will frustrate the former. Permanent, always-available consoles, column-aware completions, and language-server optimizations tuned to data-frame idioms are concrete expressions of that empathy.
Discoverability ensures that high-impact features do not remain secret passages. Action bars that surface “render on save,” one-click code-cell insertion, and help panes that render richly formatted docstrings bring frequently needed capabilities into immediate view. Small ergonomic improvements—running a Streamlit or Dash application with the correct launcher rather than a plain Python invocation—accumulate into large reductions in daily friction.
Finally, the act of explaining one’s work closes a vital feedback loop. Writing documentation, type annotations, or even lightweight notes in a project file forces clarity of thought. The same artifacts later serve both future collaborators and future selves. The principle “if your writing helps even one person it is worth doing, especially if that person is you” applies equally to private architectural notes and public getting-started guides.
Closing the Loop Between Building and Using
Tools improve through continuous cycles of use, observation of pain points, and iterative refinement. Feedback—whether GitHub issues, hallway conversations, or structured user testing—supplies the raw material for those cycles. Because every practitioner is simultaneously a consumer and a potential contributor, each unique perspective enriches the shared ecosystem. The mission is not the construction of a final, perfect package but the ongoing cultivation of experiences that feel beautiful, empowering, and precisely fitted to the work at hand.