A strategy for more frequent posts

I have many incomplete threads on distributed systems. How do I balance my desire for complete and correct presentations with the need to post more frequently?

When are "motivating" images useful in a presentation?

Note: I’m writing this post to clarify my thinking about an issue in presentation design. I’m using a stream-of-consciousness format, with little editing. You might want to skip this one if you are looking for careful, reasoned arguments.

This post considers the style of figures and images that complement the ones I discussed in the figure failures post. Where that post considered figures that represent concepts geometrically, this post considers images intended to surprise, inspire, and motivate the audience. When should I use them? When shouldn’t I use them? Are they of any use at all?

Figure failures (and successes!)

Well-designed figures are invaluable for presenting technical detail, including architectural diagrams, timing diagrams, data visualizations, category hierarchies, and many other forms. Yet the simplicity and directness of a successful figure belies the complexity of all the design decisions underlying it. Those decisions were specific to the original context. Pulling a figure from that context and inserting it into a very different context such as lecture slides will likely fail. This short post lists the many ways that such appropriation can fail.

A class is a story: Fitting content to sessions

Any given class is a story. It has a beginning, middle, and end. It arcs toward a conclusion. The story can be deliberate and designed or it can be inadvertent and confused. Ultimately, the story will be different for everyone in the room. The best that I can do as instructor is the best any performer can do: Create an environment in which the audience can participate, hoping that their outcomes approximate those I had in mind. But what do I do with a prior “story” when the class I designed for an hour and a half session last year is scheduled this year for a sesssion of one hour?

Roles vs. Silos, Contribution vs. Technology

With the developing maturity of chaos engineering techniques, I see people taking the job title, “Chaos Engineer”. Although I think chaos engineering is a truly useful field based upon important principles, I am wary of defining one’s job in those terms. It confuses technology with contribution, creates a silo where we want a role. I prefer a title like Site/Service Reliability/Resilience Engineer, which emphasizes the bearer’s contribution to the organization. An SRE may very well have training in chaos engineering and spend much of their time using those methods but their role is to improve system reliability.