Intro

At a technical conference about 20 years ago, a keynote speaker observed that most people know who influenced their favorite band members than who influenced their team members, or who an athlete played with before their current team. He challenged us to know that level of influence and history about our own team members and industry thought leaders. It was a challenge that’s stuck with me. Over the years, I have been conscious about who influences me, what influenced them, and how these influences transfer.

Lately, I challenged myself to get that list out of my head and into a list. I’ve tried that in the past, but typing (or speaking) always ended up too long. It’s still too long for most blog posts, but for me, it’s too short for the amount of gratitude I have for the influence the following people and ideas had on me, my career, and my life.

I am, quite literally, who I am because of these people and ideas.

Nature

Momma Nature is my oldest learning partner (and play friend). When I go to the woods, I cannot hold a conversation, and I can’t even think through a problem. The verbal and executive functions of my brain have to shut down because the other parts are so active. I am observing at a non-verbal/non-rational level. Occasionally, those levels will throw an observation up to my frontal cortex (i.e. why some plants sprout green leaves while others add chlorophyll only after the leaf has matured), but, like sleeping, I find that when I tend to the non-rational part of my brain, the rational part works better.

People

Tim O’Reilly, Randal Schwartz, Larry Wall and Damian Conway — Tim created an ecosystem (then called O’Reilly & Associates) where Randal’s technical expertise could teach Perl to the newly emerging web developers a handy tool — starting with Learning Perl1 and Programming Perl.2 During the Perl 5 → Perl 6 transition, Larry wrote the Apocalypses — design documents for each major feature of Perl 6. Damian wrote the Exegeses — detailed explorations and implementations for the rest of us. High rigor. High entertainment. A lively public design argument that proved genuinely productive. Larry was deliberate about Perl being both a technical language and a community of practitioners. Damian balanced the computer’s need for technical rigor and the human brain’s reliance on metaphor and intuition. They designed a language for human brains that also worked in computer CPUs. I know programming better for having been engaged in those public discussions.

Bjarne Stroustrup and the C++ community taught me something about the value of backward compatibility and community-driven design. C++ is not a clean language. It carries 40 years of decisions, some of them wrong. But the discipline of not breaking existing code — and the community process for adding to the language carefully — created something durable. I respect that more than I respect elegance. (See also: Larry Wall and Damian Conway above.)

David Bernstein,34 Michael Feathers,5 Kent Beck,6789 Arlo Belshee, Llewellyn Falco, Woody Zuill, Emily Bache10 — These technical coaches were able to think deeply about software then communicate it effectively to others. In most cases, they did not invent the technical practices or team practices, but they (like my walks in the woods - see “Momma Nature”) were able to immerse themselves in the practices, observe patterns, distill them to a nugget, then share it with people who often said “Oh yeah. We do something like that, but we never had a phrase for what that was”. Although the practices (as noun) are documented in books and conference talks, it is the practice (as verb and vocabulary) that distinguishes these contributions.

Organizations

AT&T Bell Labs (Kernighan, Ritchie, and the Unix creators at Murray Hill) gave us the philosophy of small tools that do one thing well and compose with other tools. That philosophy has outlasted every “integrated solution” that was supposed to replace it. The shell pipeline is still one of the most powerful programming models ever invented.

O’Reilly & Associates (now O’Reilly Media) made technical knowledge accessible. The animal books were not just reference material — they were an argument that learning hard things could be pleasurable. That matters more than it sounds.

The Free Software movement (later rebranded Open Source) introduced me to the idea that sharing knowledge is a civic act, not just a commercial strategy.11 Code shared under a license that preserves your right to study, modify, and redistribute it is infrastructure. It has rights and responsibilities attached, like a road or a water system. The community that grew around that idea built the internet we use today, and did it mostly without being paid.

Entertainment

JMU Marching Royal Dukes. Two hundred people. Early morning practices in the fall cold. The half-time show is twelve minutes. To get twelve minutes right, you run it for weeks. The phrase I carried away: Good, better, best. Never let it rest, until your good is better and your better is best. That is not about perfectionism. It is about the discipline of continuous improvement in service of something collective. When it worked, two hundred people moved as one thing. That is not a metaphor for teamwork — it is teamwork, in its most literal and visceral form.

The Folk Project. Contradancing. Callers and musicians and dancers who need each other. The caller says “balance and swing” and every pair in the room does the same thing at the same moment. Balance — acknowledge your partner, find your center. Swing — move together, let momentum carry you. I have thought about those two words a lot. They say something about what matters in life beyond survival: play, community, movement, music. What we choose to do when the necessities are covered.

November Project.12 A free fitness movement that meets in parks. No gym, no fee, no excuses — just show up. If jumping up and down at 6:29 am doesn’t get you going, the camaraderie will. And if nothing else goes well for you that day, you know that at the very least — before 7:15 — you had fun, exercise, and a confidence booster marked complete. That guaranteed win early in the morning is not a small thing. It changes the whole day.

Communities of Practice

Perl. A language community that matched the language: eclectic, argumentative, generous, and surprisingly productive. The Perl 5 → Perl 6 transition was a years-long public design conversation that I watched closely and learned from. See also: Larry Wall and Damian Conway above.

Sustainable Ballard.13 Three peace activists, frustrated that the Iraq War was driven in part by oil dependence, got tired of being against things and asked: What are we for? That question sparked chickens, potluck meals, goats, local banking as a service rather than extractive usury — and a neighborhood-scale demonstration that a different future was possible to build. Founded in 2003, it became the first neighborhood sustainability group in Seattle and a founding organization of SCALLOPS (Sustainable Communities All Over Puget Sound). Not protesting. Not opposing. Making. The proof-of-concept approach to civilization: if you want to live in a different world, start living in it.

Human Interactions

Liberating Structures (Keith McCandless and the Seattle user group) gave me a framework I didn’t know I was missing.1415 Human interaction at work is designed — either intentionally or by default. Most organizations accept the default: status meetings, presentations, open discussions dominated by the loudest voices. Liberating Structures is a catalog of alternative structures: small precise formats that change who talks, when, and to whom, producing outcomes the defaults cannot reach. This is not soft stuff. It is engineering applied to conversation.

Core Protocols (Jim and Michelle McCarthy) decompose the behavior inside a meeting into small named protocols: Check In, Investigate, Propose, Decider. It is an odd idea until you try it. Breaking “meeting” into component parts lets a group examine and improve each part separately, the same way you refactor code. I found the Decider protocol alone worth the price of admission.

Non-Violent Communication (NVC) showed me that aggression in conversation is often invisible to the person using it.16 When you assume a win/lose framework, your language encodes that assumption — in requests that are really demands, in observations that are really accusations, in “feedback” that is really judgment. NVC offers a different frame: everyone’s needs are legitimate; the question is whether we can find a path where everyone’s needs get met. Maybe not everyone’s wants. But their needs. That shift in assumption changes what is possible.

Lean Coffee (Jeremy Lightsmith and Jim Benson).17 Kanban for conversations. Born in Seattle in 2009 — no predetermined agenda, no speakers, no steering committee. Participants write topics, dot-vote on what they most want to discuss, then work through the list with a timer. Let smart, curious people self-select and self-direct a conversation on the topics that matter most to the assembled group, and you spark passion. Contain it with the lightest possible structure and you get something as elemental as duct tape or bailing twine for human creativity and enlightenment. It spread worldwide and kept going for years because it works.

Open Space Technology (Harrison Owen).18 The principle: whoever shows up are the right people; whatever happens is the only thing that could have. Open Space removes the predetermined agenda entirely and trusts the assembled group to create the sessions they need. It sounds like it would produce chaos. It produces the opposite — focused, energetic, self-organized conversations that a traditional conference format cannot match. AONW (Agile Open Northwest)19 applies Open Space to the agile community in the Pacific Northwest, and is one of the best gatherings of its kind.

Ideas

The GNU Manifesto.11 Richard Stallman’s argument was not primarily about software. It was about the responsibility of skilled people to build shared infrastructure, even when the market would not pay for it. Libraries, roads, scientific research — these things exist because we agreed, as a society, to fund them outside of market logic. The GNU Manifesto applied that argument to software. I don’t agree with all of it. But the core question — what do you owe the community that made your skills possible? — is one I keep returning to.

Reinventing Organizations (Frederic Laloux).20 Different organizations operate in genuinely different modes — not better or worse along a single axis, but different, with different assumptions about control, purpose, and trust. Laloux’s contribution was to name these modes and show how each is internally consistent. An organization running in one mode will experience another mode as threatening or incomprehensible. That explains a lot of organizational friction I had previously chalked up to bad management.

The Design of Everyday Things (Don Norman).21 Objects have affordances — built-in signals about how to use them. A door that should be pushed has a flat plate, not a handle. A dial that should be turned is round. When affordances are well-designed, they are invisible: you just use the thing correctly without thinking. When they are wrong, you pull when you should push, and you feel briefly stupid, and that is the designer’s fault, not yours. Norman’s argument is that this is not trivial — it is a language operating below spoken language, and it shapes safety, efficiency, and whether people feel competent or foolish. I cannot look at software interfaces the same way after reading this book.

Standards. Unglamorous and underrated. Mail servers interoperate because SMTP is a standard. Electric plugs fit outlets because committees agreed on dimensions. Threads on a bolt match the threads in a nut because someone specified the ratio. Standards are the shared infrastructure of the physical and digital world, built by committees, usually invisible, noticed only when missing.

Design Patterns

Design Patterns (the Gang of Four book).22 The patterns themselves are useful. What changed my practice more was the idea that a vocabulary for design is itself a tool. Before the book, talking about code structure required long explanations or code samples. After it, you could say “that’s a Strategy pattern” and a conversation that would have taken twenty minutes took two. Names create shared understanding, and shared understanding enables collaboration at a higher level.

Introduction to VLSI Systems (Mead and Conway).23 They found the underlying simplicity in integrated circuit design at a moment when it seemed impossibly complex, wrote a textbook, and in doing so created an open infrastructure for chip design. The result was a generation of custom chips designed by people who had not previously been able to afford entry to that field. It is a story about how a well-placed abstraction can open up an entire industry.

Ashley’s Book of Knots (Clifford Ashley).24 Over 3,800 knots. Every one hand-drawn. Ashley spent eleven years on it. A knot, like a well-written subroutine, is an elegant solution to a specific problem in a specific context. The book is a catalog of those solutions, and also a work of art — the kind of sustained, devoted attention to craft that makes you want to bring that same attention to your own work, whatever it is.

The Ants (Bert Hölldobler & E.O. Wilson).25 The definitive work on ants, by a quantum leap. Won the Pulitzer Prize for General Nonfiction in 1991 — the only professional science work ever to do so. Like Ashley’s Book of Knots: meticulous observation, nearly a thousand hand-drawn illustrations, decades of devoted attention to one small corner of the world. Wilson was no one-trick pony: he also founded sociobiology, coined “biodiversity,” and won a second Pulitzer independently. What I took from it: some people spend a lifetime becoming the world’s foremost authority on one small thing, and in doing so illuminate everything.

Platforms

GitHub.26 The town square. The bazaar. The flea market where you find reusable parts to build something bigger. Version control became social: open exchange of ideas, with vetting, forking, and composing. The pull request workflow changed how open source collaboration worked — not just technically but culturally. Visibility, asynchronous review, a record of decisions. Enabled much bigger steps by making reuse visible and trustworthy.

Open Source. See Organizations above. Worth naming separately as a platform because it is: a set of licenses, norms, and tooling that makes shared code infrastructure possible at scale.

Emacs. Not just an editor. A platform — one I have not outgrown in forty-plus years. Most tools solve a problem and are done. Emacs is a substrate for building the tool you need, and then building another one on top of that, indefinitely. What I took from it is the distinction between a tool that solves a problem and a platform that supports an ever-changing way of working. That distinction applies far beyond editors.

Technical Practices

Test-Driven Development (TDD). The name makes it sound like it’s about testing. It isn’t — or not primarily. Test-first is a discipline of thinking before doing: you have to know what you want before you can write the test that will confirm you got it. The tests are the artifact, but the practice changes how you design. I wrote worse code before TDD. Not because I was less skilled, but because I was not forced to think clearly about intent before implementation.

Refactoring. The discipline of changing code structure without changing its behavior, in small safe steps. Not cleanup. Not rewriting. Small, verified, reversible steps. Michael Feathers, Emily Bache, and Llewellyn Falco each found different ways into this practice and made it teachable. The insight that you can improve code you did not write, incrementally, without breaking it, without a big rewrite — that is one of the most practically useful things in software.

Dojo. The learning format, not the place. Knowledge workers learn best by doing, alongside others, with feedback. Not from a sage on a stage. The coding dojo — working through a problem together, rotating driver and navigator, talking through decisions — is a model for learning that respects how people actually build expertise. It does not scale from assembly-line assumptions about work, which is part of why it is underused.

Themes

Looking back across these thirty-two entries, a few patterns recur.

Shared infrastructure beats private ownership. Free Software, open source licenses, standards, Bell Labs, SMTP, GitHub, Mead & Conway opening chip design to the world — the things that have scaled and lasted were built in common and kept in common. Society and civilization are built in public, by the public, for the public.

Design for humans first. Larry Wall designed Perl for human brains, not compiler convenience. Don Norman designed doors for human instinct. Liberating Structures redesigned meetings for how people actually talk. NVC made aggression visible by starting from how human needs work. The best-designed systems start with the human, not the machine.

Names are important. Shared vocabulary enables collaboration. Before “Strategy pattern” existed, describing it took twenty minutes and a whiteboard. The name didn’t just label the idea — it made collaboration around it possible. Design Patterns, Liberating Structures, Core Protocols, Reinventing Organizations — each is a vocabulary as much as a framework.

Small reversible steps beat heroic leaps. Rewriting everything from scratch is a process. It is repeatable. And has a predictible outcome - dumpster fire on a train wreck. Building (or rebuilding) in small steps is repeatable and predictible, and has a much better historical track record. Clifford Ashley spent eleven years on 3,800 knots. The JMU marching band drilled the half-time show in daily practice sessions. TDD asks you to think clearly before you act. Mastery is disciplined attention to small details, not a grand theatric inspiration.

Platforms outlast tools. Emacs is forty years old. The Unix shell is even older. A good platform allows users to perform actions the designer never envisioned.

References

  1. Schwartz, R. L. (1993). Learning Perl (1st ed.). O’Reilly & Associates. Expanded through 7 editions; current ed.: Schwartz, Phoenix, & foy (2016). ↩

  2. Wall, L., & Schwartz, R. L. (1991). Programming Perl (1st ed.). O’Reilly & Associates. Expanded through 3 editions; current ed.: Wall, Christiansen, & Orwant (2000). ↩

  3. Bernstein, D. S. (2015). Beyond legacy code: Nine practices to extend the life (and value) of your software. Pragmatic Programmers. ↩

  4. Bernstein, D. S. (2024). Prompt engineering for everyone: A comprehensive guide to unlock the potential of ChatGPT and AI-language models (2nd ed.). ↩

  5. Feathers, M. (2004). Working effectively with legacy code. Prentice Hall PTR. ↩

  6. Beck, K., & Andres, C. (2004). Extreme programming explained: Embrace change (2nd ed.). Addison-Wesley. ↩

  7. Beck, K. (2002). Test driven development: By example. Addison-Wesley. ↩

  8. Beck, K. (2007). Implementation patterns. Addison-Wesley. ↩

  9. Beck, K. (2023). Tidy first?: A personal exercise in empirical software design. O’Reilly Media. ↩

  10. Bache, E. (2013). The coding dojo handbook. (ISBN 919811803X) ↩

  11. Free Software Foundation. (1985). The GNU Manifesto. https://www.gnu.org/gnu/manifesto.html ↩ ↩2

  12. https://november-project.com ↩

  13. Sustainable Ballard. (n.d.). Neighbors working together for a strong and healthy community [Home page]. https://www.sustainableballard.org/ ↩

  14. Lipmanowicz, H., & McCandless, K. (2014). The surprising power of liberating structures: Simple rules to unleash a culture of innovation. Liberating Structures Press. ↩

  15. https://www.liberatingstructures.com ↩

  16. Center for Nonviolent Communication. https://www.cnvc.org ↩

  17. http://leancoffee.org ↩

  18. Owen, H. (2008). Open space technology: A user’s guide (3rd ed.). Berrett-Koehler Publishers. ↩

  19. https://www.agileopennorthwest.org ↩

  20. Laloux, F. (2014). Reinventing organizations: A guide to creating organizations inspired by the next stage in human consciousness. Nelson Parker. ↩

  21. Norman, D. A. (2013). The design of everyday things (Rev. and expanded ed.). Basic Books. (Original work published 1988) ↩

  22. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns: Elements of reusable object-oriented software. Addison-Wesley. ↩

  23. Mead, C., & Conway, L. (1980). Introduction to VLSI systems. Addison-Wesley. ↩

  24. Ashley, C. W. (1944). The Ashley book of knots. Doubleday. ↩

  25. Hölldobler, B., & Wilson, E. O. (1990). The ants. Harvard University Press. ↩

  26. https://github.com ↩