Posts Tagged ‘Textual’
[PyConUS2025] Lessons from 503 Days of Full-Time Free and Open-Source Software Development
Lecturer
Rodrigo Girão Serrão is a Python educator, author, and independent trainer. He maintains an extensive body of writing on Python, programming, and mathematics at mathspp.com and has published multiple independently produced books on these subjects. Serrão has spoken at major conferences including PyCon US, EuroPython, and various European national PyCons. In late 2024 he established a Guinness World Record for the largest programming lesson. He previously spent 503 consecutive days as a full-time contributor to the Textual terminal-user-interface framework. His professional site is https://mathspp.com and his GitHub handle is rodrigogiraoserrao.
Abstract
Drawing on a continuous year-and-a-half of full-time employment on the Textual open-source project, Rodrigo Girão Serrão reflects on non-technical lessons acquired in that environment. The presentation examines the role of public online activity in obtaining technical work, the management of personal ego within a stronger team, constructive responses to error and code review, the practical demands of user and contributor interaction, and strategies for navigating a large codebase that exceeds individual working memory. The account is explicitly subjective yet offers transferable observations for anyone collaborating on substantial software, whether proprietary or free.
Obtaining Work and Managing Ego in Collaborative Settings
Serrão begins by stressing that every public artifact—blog posts, code repositories, conference talks, social-media interactions—functions as a continuous advertisement of one’s capabilities and temperament. In his own case, sustained technical writing created intermittent contact with the eventual employer; over time that contact matured into an offer of full-time open-source employment. He is careful to acknowledge the element of chance while simultaneously insisting that chance can be cultivated: consistent public output raises the probability that a future opportunity will intersect with an existing relationship. Attendance at events such as PyCon further multiplies those intersections.
Once inside a team that contained stronger Python practitioners than himself, Serrão confronted the necessity of subordinating ego. Previously the sole Python developer in smaller organizations, he had been simultaneously the best and the worst practitioner by definition. The new environment inverted that status. Rather than experience the change as loss, he reframed it as an accelerated learning opportunity. The presence of more experienced colleagues meant that disagreements could be treated as tuition rather than threats. Code reviews, in particular, became occasions to inquire why a particular solution was preferred, thereby converting potential confrontation into knowledge transfer. The discipline required is emotional as much as technical: one must deliberately set aside the impulse to defend one’s first draft and instead treat every requested change as data about better practice.
Honest mistakes are inevitable and, within a healthy team, permissible; repetition of the same mistake is not. Serrão illustrates the point with self-deprecating examples, including a pull-request history that initially appeared to worsen rather than improve and an issue report whose essence reduced to the complaint that “Python ran when I ran Python.” The episode, quickly closed in embarrassment, underscores both the ubiquity of error and the protective value of a non-punitive culture. The operative rule is simple: never make the identical error twice.
Interacting with Users and Navigating Large Codebases
Users are simultaneously the justification for open-source labor and a persistent source of friction. Interaction consumes time and emotional energy, especially when bug reports lack minimal reproducible examples or when pull requests ignore project conventions. Serrão’s central recommendation is the creation of a thorough contributing guide, not because contributors will read it voluntarily, but because the document can be cited in responses. Issue templates that solicit terminal version, operating-system details, and other project-specific context further reduce diagnostic cycles. The first reply to any issue or pull request should be rapid—even if it consists only of an acknowledgment and a pointer to the guide—because prolonged silence communicates indifference and can discourage first-time contributors.
Kindness that borders on the excessive is advised. Textual communication strips away tone; what feels playful to the writer may read as curt or sarcastic to the recipient. Over-compensation with explicit warmth therefore functions as insurance. When a pull request must be declined, Serrão attempts to extract any salvageable fragment, open a new pull request containing that fragment, and credit the original author as co-author. The gesture preserves the contributor’s sense of impact and avoids the appearance of appropriation.
A large codebase cannot be held entirely in working memory. Serrão therefore maintains four persistent heuristics while making changes: (1) prioritize the experience of the end user over the convenience of the implementer; (2) attend to the spirit rather than the letter of an issue description; (3) accept the burden of tedious or difficult work so that downstream developers face fewer obstacles; and (4) evaluate every design decision for the reasonable future possibilities it might foreclose. Before opening a pull request he converts it to draft status and performs a self-review, catching many defects before they reach colleagues. Finally, he insists on running the full test suite; the project’s complexity guarantees that untested changes will break something.
The cumulative effect of these practices is a posture of continuous, ego-light learning. Public writing may open doors; humility and systematic kindness keep them open. A contributing guide and disciplined self-review protect both the project’s quality and the psychological safety of its participants. Although Serrão no longer works full-time on open source, the habits formed during those 503 days continue to shape his work as an educator and independent practitioner.