English · 00:28:40 Jan 23, 2026 5:13 PM
Writing less code (by understanding your priorities) - Wildflower
SUMMARY
Aydah Wildflower, a Trinidadian Clojure developer, presents on writing less code through clear prioritization, illustrated by her four-year evolution of text editors from poetry-specific tools to the general Paperbalm app.
STATEMENTS
- Writing less code avoids unnecessary burdens like securing data, maintaining libraries, and documenting unused functions, emphasizing the full lifecycle of software.
- Prioritization in programming involves rating limited resources such as time, compute, storage, and marketing budget to decide what features to implement.
- Developing perspective means understanding the problem, application boundaries, and security to confidently reject even good ideas that don't align.
- Identifying necessary complexity guides decisions on building in-house, importing libraries, or using external APIs, rather than defaulting to the easiest option.
- Over four years, Wildflower created four text editors, each with evolving perspectives on specificity, generality, project-based vs. individual documents.
- Applications like Microsoft Word are general and individual-document focused, while Obsidian is general and project-based; Scrivener is specific and project-based; ABC music tools are specific and individual.
- Her first tool, Poetry Journal, was highly specific for single poems without storage; Giant Heart Poetry added cloud-based collections for poetry journals.
- Writing Recipes, a CLI tool using Babashka and NBB, was more general but limited to single documents to enable quick shipping and feedback.
- Paperbalm is a general, project-based web/desktop app supporting various writing recipes, developed only after clarifying priorities to manage feature creep.
- Blurry perspective led to premature optimization for collaboration in Giant Heart Poetry, while clear scope in Writing Recipes allowed useful testing.
IDEAS
- Avoiding user data collection entirely eliminates security needs, highlighting how non-implementation can be the simplest solution.
- Programmers' time is a scarce resource akin to limited goods, making prioritization essential for allocating effort wisely.
- Modular Clojure web development, often seen as a limitation, actually enables better prioritization by allowing custom functions over full library imports.
- Evolving perspectives on apps—from specific single-use to general multi-workflow—reveals how rewriting codebases tests new boundaries without endless feature additions.
- Plotting apps on specificity/generality and project/individual axes clarifies architectural decisions, like choosing databases for collections vs. none for singles.
- Prematurely optimizing for unneeded features, such as collaboration in a personal journal, stems from visionary company-building over product-shipping focus.
- Command-line tools like Writing Recipes, bounded to single files, accelerate learning and feedback by time-boxing scope from the start.
- Custom poetry editors with line-level operations and syllable counts represent necessary complexity when off-the-shelf options fall short for core user needs.
- Importing vetted libraries like next journal markdown saves effort on non-core tasks, but requires checking dependencies to avoid past pitfalls.
- Browser APIs like hashchange events can handle simple routing needs without heavy libraries, integrating seamlessly into existing architectures for minimal code.
INSIGHTS
- True efficiency in coding arises not from more features but from ruthless boundary-setting that aligns architecture with the problem's essence.
- Perspectives evolve through iterative rewrites, turning initial narrow tools into broader ones only when priorities crystallize to prevent scope explosion.
- Necessary complexity is domain-specific: build custom when it touches core creativity, like poetry lines, but leverage platforms for commoditized needs like routing.
- Prioritization empowers saying no to good ideas, transforming limited resources into focused products that users actually value and adopt.
- Blurry visions lead to over-engineering; clear scopes enable rapid prototyping, as seen in CLI limits fostering quick validation over perfection.
- Practical user experience fixes, like back-button routing, demonstrate that caring through minimal, integrated solutions often trumps feature-rich imports.
QUOTES
- "The easiest way to solve a problem is to avoid the circumstance entirely."
- "You don't need to document code that was never written."
- "When you're defining the boundaries of these applications... these are like considerations that would come about."
- "Poetry the fundamental unit is the line. It isn't like the entire stanza."
- "Sometimes it's not about building the perfect solution. It's about making practical choices that show that you care."
HABITS
- Actively reflect on problem boundaries and security before coding to build courage for rejecting misaligned ideas.
- Vet third-party libraries thoroughly, checking dependencies based on past experiences to minimize maintenance risks.
- Time-box projects by setting strict scopes, like single-document operation, to ship quickly and gather feedback.
- Prototype iteratively by rewriting codebases when perspectives shift, testing new ideas without bloating old ones.
- Integrate browser or platform APIs first for simple needs, reading official docs like MDN to avoid over-relying on libraries.
FACTS
- Clojure's modularity allows forgoing full routing libraries like Reitit in favor of a few custom functions for basic navigation.
- Over four years, Wildflower developed four distinct writing apps in ClojureScript, each refining from poetry-specific to multi-purpose tools.
- Hashchange events in browsers enable lightweight routing for single-page apps, firing on back-button presses without full history API complexity.
- Next journal markdown library converts to Clojure Hiccup syntax, ideal for integrating Markdown support with minimal custom parsing.
- Obsidian treats a "vault" as its core unit, making it project-based and general for knowledge management across audiences.
REFERENCES
- Giant Heart Poetry (https://giantheart.co), a cloud-based poetry journal app.
- Paperbalm (https://paperbalm.com), a web/desktop writing tool with recipes.
- Writing Recipes, a CLI app on GitHub using Babashka and NBB.
- Reitit, a Clojure routing library considered but not used for simple needs.
- MDN documentation on hashchange events for browser routing.
HOW TO APPLY
- Define your perspective by mapping the problem's boundaries: specify the audience, tasks, and security needs to guide what to include or exclude.
- Plot your app on axes of specificity/generality and project/individual to visualize scope and anticipate architectural choices like storage.
- Identify necessary complexity by questioning if a feature is core to the domain—build custom for irreplaceable elements, like poetry line editing.
- Evaluate tradeoffs for libraries or APIs: assess costs in maintenance vs. development time, vet dependencies, and prefer platform natives when possible.
- Test user flows early, like back-button behavior, and implement minimal fixes—use event listeners to integrate with existing code without full overhauls.
- Iterate by rewriting when perspectives evolve: start narrow for quick validation, then expand only after clarifying priorities to avoid feature creep.
ONE-SENTENCE TAKEAWAY
Prioritize ruthlessly by defining perspectives and necessary complexity to write minimal, impactful code that truly serves users.
RECOMMENDATIONS
- Begin projects with a clear perspective graph to align features and prevent premature optimizations unrelated to core needs.
- Limit initial scopes, such as single-document focus, to enable rapid prototyping and real-user feedback before scaling generality.
- Build custom components only for domain-specific necessities, like creative writing aids, while importing vetted tools for standard tasks.
- Leverage browser APIs and official docs for simple integrations, reducing library bloat and easing long-term maintenance.
- Regularly reflect on past blurry decisions to refine prioritization, turning painful lessons into habits for shipping usable products faster.
MEMO
In the bustling world of software development, where lines of code multiply like unchecked ambitions, Aydah Wildflower offers a counterintuitive manifesto: write less to achieve more. At Clojure/Conj 2025 in Charlotte, North Carolina, the Trinidadian programmer from Richmond, Virginia, shared her decade-long journey with Clojure and ClojureScript, turning personal frustrations into a philosophy of prioritization. Wildflower's talk, "Writing Less Code (by Understanding Your Priorities)," wasn't a dry lecture on efficiency but a vivid case study drawn from her four-year odyssey creating text editors—tools born from her dual passions for poetry and climbing. By avoiding unnecessary code, she argued, developers sidestep the hidden costs of maintenance, security, and documentation, freeing resources for what truly matters.
Wildflower's evolution began modestly with a Poetry Journal, a web tool laser-focused on crafting single poems without storage or collections—users simply copied their work and moved on. This specificity was deliberate, embodying her belief that the easiest solutions often evade problems altogether. Expanding ambitions led to Giant Heart Poetry, a cloud-based service storing entire journals in databases, still tailored to poets but now wrestling with architectural choices like data persistence. Here, blurry perspectives crept in: she once optimized for collaborative editing in a solitary journaling app, a misstep driven by dreams of a larger company rather than the product's immediate needs. Such detours, she reflected, highlight how undefined boundaries inflate complexity, turning promising prototypes into unwieldy beasts.
A soul-searching pivot came with Writing Recipes, a command-line app built swiftly using Babashka and NBB. More general than its predecessors, it supported diverse writing like essays or dream logs but enforced a single-document boundary to keep the project time-boxed. This restraint allowed quick shipping and feedback from friends, whose workflows revealed the limits of poetry-centric designs. Culminating in Paperbalm—a versatile web and desktop app for "writing recipes" with structured surfaces like pros/cons lists or syllable-counting poetry editors—Wildflower demonstrated how clear priorities tame feature creep. In a live demo, she showcased surfaces that guide users past blank-page paralysis, inserting dates or rendering Markdown via imported libraries, all while minimizing custom code.
Yet Paperbalm's success hinged on discerning necessary from unnecessary complexity. For poetry, she handcrafted line-level deletions and syllable tracking, deeming it indispensable for her craft where "the fundamental unit is the line." Markdown support, however, leaned on the vetted next journal library, avoiding the folly of parsing from scratch. Routing in this single-page app posed another test: ignoring browser back-button behavior frustrated users, like her wife, prompting a lightweight hashchange event listener over a full Reitit import. Integrated into her rules-engine architecture, this minimal fix—saving state, updating history—proved that practical choices signal care more than perfection.
Wildflower's insights extend beyond her tools, challenging programmers to treat time as a scarce commodity and perspectives as evolving maps. In an era of bloated apps, her approach—iterating through rewrites, saying no to good ideas, and embracing modularity—offers a blueprint for human-centered development. As she fielded questions on adapting Paperbalm for technical writing or music notation, her openness underscored a final truth: prioritization isn't isolation but invitation, empowering creators to build what users need, not what visions dictate.
Like this? Create a free account to export to PDF and ePub, and send to Kindle.
Create a free account