tl;dr When doing a presentation, there should always be some kind of “story” to the presentation. It doesn’t have to be a full-blown Shakespearean “Things get worse, things get a little better, then things get way worse, and either they eventually get better (a comedy) or they just end worse (a tragedy)” plot arc, but your audience needs to have a narrative arc to the talk that they can sort of hang on to while you’re doing your thing. And, as it turns out, you need it as much as they do.

tl;dr In the wake of the recent Simone Biles “scandal”, it’s important for people who are in like situations to stand up and be counted. So, although this is something I’ve never really kept a secret, it’s well past time to ‘fess up and admit: I, too, have been diagnosed with ADD.

tl;dr I spoke at Seattle Code Camp last weekend, and I wanted to make links to the slides available for anyone who was interested in consuming them.

More than a decade ago, I published Effective Enterprise Java, and in the opening chapter I talked about the Ten Fallacies of Enterprise Computing, essentially an extension/add-on to Peter Deutsch’s Fallacies of Distributed Computing. But in the ten-plus years since, I’ve had time to think about it, and now I’m convinced that Enterprise Fallacies are a different list. Now, with the rise of cloud computing stepping in to complement, supplment or replace entirely the on-premise enterprise data center, it seemed reasonable to get back to it.

At first, it was called “DLL Hell”. Then “JAR Hell”. “Assembly Hell”. Now, it’s fallen under the label of “NPM-Gate”, but it always comes back to the same basic thing: software developers need to think about their software build and runtime dependencies as a form of Supply Chain Management. Failure to do so—on both the part of the supplier and the consumer—leads to the breakdown of civilization and everything we hold dear.

For many years, I’ve quietly mentored a few speakers in the industry. As I slow down my own speaking career, I’ve decided to put some of that mentoring advice into Internet form. And one of the key things I advise new speakers to do is to sit on both sides of the mentoring fence.

For many years, I’ve quietly mentored a few speakers in the industry. As I slow down my own speaking career, I’ve decided to put some of that mentoring advice into Internet form. I’ve seen numerous speakers bring notes to themselves up to the podium, and reference them during the presentation.

For many years, I’ve quietly mentored a few speakers in the industry. As I slow down my own speaking career, I’ve decided to put some of that mentoring advice into Internet form. One of the most important things, although it seems like a good idea at first, is to never, never, EVER memorize your talk. And that includes having a script for it.

For many years, I’ve quietly mentored a few speakers in the industry. As I slow down my own speaking career, I’ve decided to put some of that mentoring advice into Internet form. In this installment, we talk about speaking—and by that, I mean pacing.

For many years, I’ve quietly mentored a few speakers in the industry. Nothing big, nothing formal, just periodically I’d find somebody that wanted to get in front of audiences and speak, and either they’d ask me some questions or I’d get the feeling that they were open to some suggestions, and things would sort of go from there. Now, as I start to wind down my speaking career (some), I thought I’d post some ideas and suggestions I’ve had over the years. This time, it’s to critique (not criticize!) others speaking. And ask for their critique in return.