Learn to recognise pattern languages

Learning to recognise patterns was part of the original movement, but identifying where languages might be hiding could be even more worthwhile. We should move away from the pattern-hunting mode of the original movement and instead look for pattern languages that are either already present or growing in a new domain. To do this, we should hunt for big, hairy problems rather than clever solutions.

We should now know we cannot look for a pattern language in a programming language, as there is no high-level problem to solve. Pattern languages solve problems. Python, JavaScript, and C++ are not problems. I may need to rethink that last statement … Regardless, they do not present a well-defined problem that can be solved. They are the tools to solve problems, as are frameworks and libraries such as Rails, React, Boost, pandas, and Flask. None of these are problems.

Within a problem domain, look for a pattern language. However, do not name it; instead, look at the existing practices and bring some pattern structure to the language. You can try mining for new patterns or redefining the tutorials and how-to guides in the documentation into categories of context, problem to be solved, and related problems and consequences.

Look to the work of Takashi Iba on pattern mining[Iba2021b] and pattern language writing[IbaHtWP21]. I have read three of their pattern language books, and each shows a set of patterns forming a language that solves a problem. The first book I read was Presentation Patterns[PresentationP14], which includes a pattern language for developing presentations. It contains many patterns that also apply to writing, but the point of a pattern language is to concentrate on a particular problem.

Their other books, Collaboration Patterns[CollaborationP14] and Learning Patterns[LearningP14], show the same structured approach to mining, refining, and structuring. In each case, the problem was mined by talking to many people who solved these kinds of problems. The results were collected and organised to find repeating and related elements. Core actions were identified, and patterns to support these actions were then connected to them.

If we look at the creation of websites, we can use Iba’s method to mine for all the core actions of a web developer—the design and creation of the database and the design of the user flow and page views. I am not a web developer, but what little I know leads me to believe that many common core activities have project-specific determinations waiting for resolution.

We can start from the realm of existing documentation. Documentation exists to solve problems. From there, new pattern languages can emerge. Those with the discernment for patterns can detect them. They can invite those with the documenting skills to elevate the content.