The funny seminar
Have you ever been in a classroom-like setting, on a Friday morning, with 10 random people taking turns reading "funny" (as in not funny) names of sport clubs to each other? Such as Dunkin' Donut for a basketball group (get it?)
Neither have I, until the middle of November. I was participating in a "comedy writing" class, at Berlin's Volkshochschule Mitte. Three days, Friday to Sunday. The teacher a full-time comedy writer for 20 years, not famous - but well in business.
I will spare you my creations, but what I have to share with you is my experience of being led to three days of simple enough creative exercises. And it was all about quantity. And about limiting time. And about not trying to be clever.
- “Give me 9 funny names for first-name last-name combinations”
- “Write down 30 adjectives”
- “Think of 5 situations and inappropriate reactions in those situations”
- ...
Of course much of what we produced was not particularly funny, some seemed forced. Yet, every time, there were a few results that had us seriously laughing. From varying people, not just the funny ones.
What I found fascinating (for the purposes of this text) beyond learning insights into what is funny and how to manufacture that was to experience a creative process more as a physical challenge than some lofty thought process. Much as a sport coach might yell: “Give me ten rounds around the court”, here I was filling the paper with 10 ideas for a punch line.
The brain is an association muscle. Start writing down a few ideas and just looking at them will spark some variations, add-ons, forks.
And I hear you saying: "Sure, that is what they tell us in any workshop where somebody introduced brainstorming". Which, of course, is true. But I can say for myself that I have still been too restrained in getting into this “doing laps” mode of creativity. Overthinking_ is a thing.
Playing Tic-Tac-Toe
The second occasion, with a similar realization, was preparing a coding kata at work called "Test-driven development as if you meant it". Keith Braithwaite, the creator of this Kata, has toured many software conferences and there are two blog posts [1] [2] by Gojko Adzic, where he reflects on the the intent behind the Kata and how he ran one himself.
The Kata has very specific, simple requirements for implementing a simple game (usually Tic Tac Toe). You are supposed to just work on the requirements and nothing else in the order provided and following strict TDD rules (write functional code in test first, only extract into test file first, ...). An example for a first requirement for Tic Tac Toe would be a game is over when all fields are taken.
At the risk of spoiling the "a-ha" moment when you go through the Kata yourself, the main point is this: You must try hard to not bring your pre-existing assumptions to the task. When you begin with the Kata, there is no talk of a board or a 3x3 grid in any of the requirements. Yet, that is where many people focus their attention on. As the facilitator, it was my job to tell the participants to delete such code. The point of this exercise is of course to let the implementation being driven by the test(s) at hand and not by your own brain thinking too far ahead. Which is at the heart of "test-driven design".
There is much to learn about TDD in such a Kata. But besides that, I felt it an instance of creativity as an exercise, much as in the comedy writing situation.
Follow a simple system without overthinking. Get to writing and refine from there.
Having implemented the Kata myself in preparation for the work session, I can say working in the spirit of TDD as if you meant it leads reliably to programming flow.
Watching too much (Clojure) TV
My last observation of the same pattern came when I was watching a talk from this year’s Clojure Conj, the main conference on Clojure: Rapid Prototyping for Software Development by Sara Kimmich (video) (conference entry).
Rapid Prototyping is nothing new in software, of course. Sara makes the point that the typical agile approach these days does not iterate fast enough:
[F]or may problems, products and solution architecting the best way is to fail fast. Faster than Agile.
With her ideas you can iterate on an idea several times a day. No need to wait for two weeks (or whatever your typical sprint length is, if you are doing Scrum). Iterating often in very small increments resonates well with TDD. Creating many (similar) ideas reminds me of the comedy writing approach.
Sara makes one other important point (that also applies to the TDD): Creating something and testing it allows us to make observations. This is very different from discussing ideas before implementation where everything is a conjecture. Showing a real-life user even just a paper prototype will generate more valid feedback than having a long exchange of opinions.
Conclusion
I am sure the things I have talked about in this post have been discussed many times in different areas. Actually, I am pretty sure that a lot of advise about any type of (creative / academic / journalistic) writing promotes similar ideas. What was remarkable for me was to see such a pattern pop up in three unrelated parts of my life over a short period of time. This really got my attention and flipped some switches in my brain.
So, no more deep thoughts?
Obviously, that would be a silly notion. This post itself is a reflection about some observations that I made and took a bit for me to be happy with. My personal challenge is trying to be clever and witty in situations.
In closing, the best answer I can give is to refer to the (double) diamond introduced by the Design Council. Design consists of both divergent and convergent phases. The former producing ideas, exploring options in the design space and the latter consolidating those ideas and filtering out those that should be looked at further. The trick might be to understand when to do what and to have the discipline to put the mind in the right setup for each.
Top comments (0)