Congratulations! You found an easter egg not linked to anywhere on this site at present.

Some Basic Practices (aka Consultant Fallschirm)

Serious advice. Try these approaches to prioritize and present your work:

• Distinguish Between Urgent and Important Tasks (Eisenhower Decision Matrix).
• Run an Architectural Significance Test and fill out the checklist in the Architectural Decision Definition of Done.
• When grouping information items such as requirements, decision drivers or component responsibilities, apply the MECE Principle to make the group mutually exclusive and collectively exhaustive.
• Apply Ockham’s Razor to remove unnecessary redundancies: “Plurality must never be posited without necessity”.
  • "Pluralitas non est ponenda sine necessitate".

Possibly useful but can turn into anti-pattern. If you run out of questions during a presentation or workshop, you can always ask:

1. Who is the target audience of your work (persona, role)? Which design/research problem is solved?
2. Can you give a larger/more concrete example of/for concept A (A can be a principle, pattern, technology and so on)?
3. How does concept A relate to B? Hasn’t this been done before, how does your work differ from C?
4. What about security? Caution: this one does not work well in Q&A part of a security talk; try performance instead.
5. How did you test/validate your work? What are your next steps?

Handle with even more care. Don’t know a term or the answer to a question? Need to gain time?

• Ask a counter question, for instance: This term has different meanings, which one do you mean? and use the answer to prepare yours. Beware:
  • You might get a counter-counter question which is even harder to answer than the first one.
  • Or you are forced to answer the original question if your communication partner knows the tactic (or has also found this page). 😉
• Start a discussion on methods or method adoption.
• Check out xkcd Comic Strips.
• Use phrases from The Hitchhiker’s Guide to the Galaxy or find one on Wikiquote.
• Resist the temptation to mimic the behavior of the BOFH.

Back to serious advice. Many hints about technical writing and conferences can be found in the posts that belong to the authoring category of my blog The Concerned Architect. More writing and research project management hints can be found in this presentation (page 48 onwards).

Computer Sciences Jokes (Stub Form)

If you have met me in person, chances are that you have heard one or more of these:¹

The “ZIO hype bucket model” is simpler than Gartner’s five-phase hyle cycle:

1. “Early” phase: initial momentum, blog posts appearing
2. “Buzz” phase: peak of euphoria, e-mags released
3. “Over” phase: semantic diffusion, (some kind of) product support claimed

How do certain types of computer scientists read books?

• Database specialist: looks at the index first, of course
• Compiler craftsman: starts with table of content
• IT architect: reads overview section of each chapter and then hands book over to developers
• UX designer: only looks at the cover (and the figures, possibly)
• Agile practitioner: n/a, prefers blogs over books.²

Certainly not mine, but I do use it often:

Two hard things: naming things, cache invalidation, avoiding off-by-one errors

To be continued. Stay tuned!