Subscribe: Interoperability Happens
Added By: Feedage Forager Feedage Grade B rated
Language: English
add adhd  don  ldquo  mdash  much  put  rdquo ldquo  rdquo  speakers  speaking  talk  thing  things  time  work  years 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Interoperability Happens

Ted Neward's Blog

Recent content on Ted Neward's Blog

Last Build Date: Thu, 13 Oct 2016 01:34:07 -0700


Revisiting Rotor

Thu, 13 Oct 2016 01:34:07 -0700

tl;dr As part of preparing for a workshop next week in Poland, I’ve been diving back into the CLR source code—which takes me back to my old friend, Rotor.

For those of you who came to the CLR late, back in 2002 Microsoft offered up an open-source version of the CLR called the Shared Source CLI. (“CLI”, for those who don’t know, is the official ECMA Specification describing the virtual machine that .NET uses as its runtime. The “CLR” is the commercial name for Microsoft’s implementation of the Common Language Infrastructure specification.) I can still remember the feeling of shock and awe when I heard that Microsoft was actually going to release the source—albeit with some of the core parts simplified for easier research purposes—to what it considered its flagship technology for the coming decade. Wow.

And then I got to write a book on it. Double wow.

And then Microsoft decided to pay me to follow up on the first edition with a second edition, which they would give away for free. Which, by the way, you can get off of my professional site here.

Triple wow.

But I want to call out something I wrote eight years ago, in the Prologue to the second edition:

“[T]he book also marks a turning point, as well: with the release of the FCL source to the wider world of the development community and the lack of significant changes to the execution engine since v2, the Rotor distribution has effectively been “cut loose” by its original creators, to stand on its own within the community, as every open source project must do at some point. This is not a cause for alarm or concern—-the Mono project continues full force, and Microsoft‘s growing comfort with the open-source community leads to the distinct possibility that the commercial CLR source will, one day, stand where Rotor once stood.”

It’s probably bad form to smirk as hard as I am right now. But I’m still doing it.

Thank you, David Stutz, for blazing the trail that Rotor could go down, and in doing so start the avalanche that would eventually become Microsoft’s engagement in the larger world of open source. We in the Microsoft community owe you a pretty big debt.

Speaking Tips: Tell A Story

Mon, 19 Sep 2016 00:49:15 -0700

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. Too often, when an apprentice speaker shows me their outline, it’s a wonderfully crafted entity of logic, detailing a lovely introduction to the thing, three core aspects of teh thing, and a conclusion that describes the thing and wraps up the talk. It’s a carefully-crafted Aristotelian arc, following the ancient Churchillian formula of “Tell ‘em what you’re going to tell ‘em, tell it to ‘em, then tell ‘em what you just told ‘em.” It’s also boring as shit. The key element that many novice presenters forget is that sitting in chairs for an hour-plus is an actual battle of willpower. The body wants to remain in motion—it hates being constrained to one place for any length of time. It’s why humans fidget in their chairs, take out their laptops, check their phones, and all the other little (distracting) things that people do during talks. Here’s the ugly little secret that nobody wants to tell you: they’re bored. And when people are bored, their bodies start to create physical stimulation so as to alleviate some of the boredom. Sometimes they’ll be polite about it and keep it to a minimum, but not always. Now, I’ll grant you, not all motion is an indicator of boredom—some people like taking notes, be it longhand on paper or in computerized (or, more recently, tabletized) fashion. But in those cases, those people will be otherwise very still—they are concentrating on what you’re saying, and they won’t be engaging in some of the other physical movement that alleviates the boredome. And, of course, this is a gross stereotype; everybody is a little bit different. However, keep this in mind as you gaze out across the room as a whole. If lots of people are fidgeting, it’s pretty likely that you’re boring them. How, then, do we not be boring? Stories vs facts Consider this: “Mary left her house at 7:30 am. She walked to the store. She purchased a ham, some asparagus, and some cooking spices. She returned to her house at 9am. She began to clean, and at noon she went out with some friends for lunch. When she returned at 1:30, she began preparing dinner for her husband. He did not arrive until 10pm, and the two of them began to argue.” Meh. Boring. But now, consider it this way: “Mary woke up in the morning, determined to not let the events of the previous day ruin her plans for today, the anniversary of when she and her husband, Tom, first met. She went to the store, picking out the things for the special dinner she was going to make for the two of them that night, and when she got back, she began to clean the house so that she could surprise him with a candlelit dinner in the living room. She went out with some friends, who were all just as excited about the evening’s plans as she was, and when she got back from lunch, she began to cook.” You know, I don’t know that I even have to tell you how this one ends. You already know. What’s the difference between the first rendition and the second? Easy: emotions. Feelings. The reader can put themselves into a story, whereas plain facts just rest on the paper. Either you’re Mary, excited about surprising somebody you care about with a special celebration, or you’re Tom, who really doesn’t understand why the hell anybody celebrates the anniversary of the day that he ran into her at a mall, I mean, come on, Mary, it was like two years be[...]

I have ADD

Thu, 15 Sep 2016 01:28:29 -0700

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. Simone Biles, for those who haven’t heard, was recently victimized by Russian hackers who sought to expose her as a gymnast who takes forbidden medication and thus expose her as much of a fraud as the Russian gymnasts who were banned from the Olympics were. Turns out, she takes Ritalin, as prescribed by the doctor, and has for most of her (admittedly, to this point, fairly short) life. She’s not hiding from it, though, and has come out publicly to say that she’s not ashamed of being somebody who wrestles with ADHD. Attention Deficit Disorder, cousin to its more easily-spotted condition, Attention Deficit Hyperactivity Disorder (ADHD), is not an uncommon thing among adults. Daniel Amen, of the Amen Clinic (one of the leading organizations involved in ADD/ADHD and autism research), has estimated that 1 in 10 members of the general population has ADD/ADHD. He’s even suggest that there are biological reasons for why human beings would evolve such a scenario among the brain’s chemisty: the characteristics of the ADD/ADHD individual are actually the exact same characteristics one would want in a hunter: broad spectrum of attention, quick shift of focus, intense burst of focus on a particular topic/subject/entity/scenario for short periods of time, and so on. Granted, ADD/ADHD doesn’t do well when you’re trying to be a “farmer”, which requires careful and close attention to detail over long periods of time and an ability to concentrate despite what might be going on in the background. But that’s why 1 in 10 are ADD/ADHD, and the rest… aren’t. Or at least, according to Amen. And the CDC, who probably know a few things about medicine. ADD and ADHD aren’t what you think they are, but numerous other places that describe it in much more glowing detail. Suffice it to say, it’s generally not what most people think it is, and in fact I’ve known a number of adults that I’m pretty sure are undiagnosed ADD/ADHD. ADD/ADHD is, however, considered a medical condition, and not something that can be corrected with “better parenting” or “stricter rules”; in fact, that’s probably the easiest way to turn your kids into extremely anxious and unhappy teenagers. It’s sort of like saying “Your lack of one arm is just due to bad parenting and lax discipline; if your parents would just take a more strict position, you could do everything two-armed people could do, too.” And if you think it’s limited to just kids, I’ve got an interesting question for you. Two of them, in fact: one, do you think ADD/ADHD just popped into the world a few years ago, and two, what do you think happened to all the kids with ADD/ADHD before now who grew up with it? Some of us figured out coping mechanisms on our own, some of us never really got a handle on it (ever known an adult who just couldn’t help but be the center of attention, even at great personal cost?), and some found chemical ways to provide the stimulation, usually at great personal cost. Myself, I was diagnosed as an adult. The story is one that I’ll not tell here, but suffice it to say it was one of those “OH!” moments. Specifically, the psychologist was saying that somebody else I knew very well probably had ADD/ADHD, because they did X, Y, and Z, and my reaction was classic: “They can’t possibly have it because I do all those things, too.” The psychologist looked at my wife, my wife looked at the psychologist, and then they both looked at me, and I went, “OH!” (ADD/ADHD does not always mean “not clueless”.) The bigger f[...]

Seattle Code Camp 2016

Thu, 15 Sep 2016 00:41:22 -0700

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.

The two talks I gave, “Why My International Relations Degree Trumps your CS Degree” and “PsyPhilProg”, were pretty well-received overall, but as always, I find I have things that I want to tune. Still, that being said, if you enjoyed the talk(s), that’s awesome, and if you’ve been inspired to go dig up some non-CS reading material to improve your development career, even better. If I can carve out some time, I’ll amend this post to include a suggested reading list.

The Fallacies of Enterprise Computing

Wed, 24 Aug 2016 23:55:16 -0700

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. I’ll expand on the items in the list over future blog posts, I imagine, but without further ado, here’s the Fallacies of Enterprise Computing. New technology is always better than old technology Enterprise systems are not “distributed systems” Business logic can and should be centralized Data, object or any other kind of model can be centralized The system is monolithic The system is finished Vendors can make problems go away Enterprise architecture is the same everywhere Developers need only worry about development problems As Deutsch said, “Essentally everyone, when they first build a [enterprise] system, makes the following [nine] assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.” Naturally, I welcome discussion around these, and I may edit and/or append to this list as time goes by, but this is where the past decade has led me. New technology is always better than old technology After building IT systems for more than sixty years, one would think we as an industry would have learned that “newer is not always better”. Unfortunately, this is a highly youth-centric industry, and the young have this tendency to assume that anything new to them is also new to everybody else. And if it’s new, it’s exciting, and if it’s exciting, it must be good, right? And therefore, we must throw away all the old, and replace it with the new. This cannot be emphasized enough: This is fallacious, idiotic, stupid, and brain-dead. This fallacy is an extension of the old economic “limited market” fallacy: The more gains one entity makes in a market, the more that other entities lose. (Essentially, it suggests that the market is intrinsically a zero-sum game, despite obvious evidence that markets have grown substantially even in just the last hundred years since we started tracking economics as a science.) Thus, for example, if the cloud is new, and it has some advantages over its “competitors”, then every “win” for the cloud must mean an equal “loss” for the alternatives (such as on-prem computing). Never mind that the cloud solves different problems than on-prem computing, or that not everything can be solved using the cloud (such as computing when connections to the Internet are spotty, nonexistent, or worse, extremely slow). Now, for those of you who have been engaged in the industry for more than just the past half-decade, here’s the $65,535 question for you: How is “the cloud” any different from “the mainframe”, albeit much, much faster and with much, much greater storage? Those who cannot remember the past are condemned to repeat it. –George Santanyana, Historian I’ve seen this play out over and over again, starting with my own entry into the IT universe with C++ (which was the “new” over C), and participated in a few system rewrites to C++ from other things (Visual Basic being one, C being another, sometimes some specific vertical stuff as well). Then I saw it again when Java came around, and companies immediately started rewriting some of their C++ systems into Java. This time around, I started to ask, “Why?”, and more often than not, answers of “We don’t want to fall too far behind” or “We need to[...]

Developer Supply Chain Management

Thu, 18 Aug 2016 23:38:17 -0700

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. Well, OK, fine, not exactly the breakdown of all civilization. But certainly a breakdown in the part of civilization that is currently occupied by those who would lead a happy and productive lifestyle in the platform under discussion (whether that be native code, Java, .NET, JavaScript, or what-have-you). For those who haven’t seen the disaster that was NPM-Gate, allow me to refer you to a few links: The Timeline. Probably the closest thing to an “official” history of what happened. ARS Technica’s views on the subject Business Insider UK also reported on the mess The upshot, however, was that the removal (rightly or wrongly) of a package that a core package (ExpressJS, among others) depended on led to an obscene number of sites suffering an outage. Interpreting the deploy To some, particularly those coming from the native, Java or .NET persuasion, this missing dependency may seem odd—after all, it would really only make itself felt when the project was compiled, not at runtime. If the project had already been “built” (which, in the NodeJS world, would mean having already downloaded all of the dependencies and deployed), then why would the package’s subsequent removal really make all that much of a difference? Here, we come to the part where conventions and cultural habits come into play; when a NodeJS-based system is deployed, it’s typically deployed without its dependencies, rather than with them. Recall that NodeJS, like all Javascript-based environments, is an interpreter, not a compiler or virtual machine. Thus, the habit among the NodeJS community is to deploy the source code along with a manifest file (package.json) that in turn describes all of the dependencies. Then, as part of the deploy, one issues the command to pull the dependencies down (npm install), and the application is ready to go. “OK, fine, then each time they deploy, there’s a problem. I still don’t see why this caused so much outage across the Internet”, might be the reasonable reply. And this is where we get into why this matters to people outside the NodeJS world. The NodeJS community, you see, has been at Ground Zero for a lot of the DevOps movement—many of the ideas and concepts around DevOps have been put into play in NodeJS environments. After all, think about it: write your source, then commit the changes, and boom, everything is ready for a deploy—so it’s trivial (in a way) to wire this up into a full-blown DevOps pipeline, particularly since most NodeJS-based systems are using REST/HTTP APIs for the back-end, which are always much, much easier to automatedly test than other middleware options. So when you go “all in” on the DevOps thing, and start doing daily—or hourly—releases, suddenly a break in your deployment process becomes a really big deal. Particularly if your “rollback” strategy is based around the idea of doing a re-deploy of old code, as opposed to having a full backup of the server (or server container image) that you can simply spin up without having to actually run the deployment script. Lessons This kind of event, which qualifies as a black swan event if ever there was one, still leaves quite a few lessons that developers can learn from. First of all, there’s the obvious one that suggests that developers need to pay close attention to their dependencies. [...]

Speaking Tips: Mentor and Be Mentored

Sun, 14 Aug 2016 15:59:34 -0700

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. It’s a pretty simple thing: If you’re a speaker, look for a mentor. This is the first thing any newcomer to Toastmasters does—pick a mentor—so it’s not like this is rocket science. I had a few mentors when I started teaching at DevelopMentor two decades ago, and I learned a ton from watching them do their thing. But there’s more to learning than just learning. Maths, teaching, and me Many, many years ago, in grade school, I confidently informed a math teacher that I didn’t need to do the in-class exercise—I understood the concept (heck if I can remember what it was; probably something like multiplication or something really hard like that). The teacher looked at me, then said, “Well, fine, if you understand it, that’s great, you don’t need to do the work. But could you do me a favor and explain it to your classmate over here? He’s still struggling.” Brim-full of confidence, of course I strode over to the other desk where my classmate was still working to understand it (whatever it was we were taught), and Lo and Behold! I couldn’t really teach it to him, either. Because, as my math teacher then rather gently and kindly explained to me, “You can’t teach what you don’t know.” Political science, lectures, and me What he neglected to tell me—which I discovered for myself years later—is that teaching a subject also helps you learn it a lot, lot better. I found that out while in some college study sessions; I had this habit of reciting the professor’s Poli Sci lectures in her voice and accent, and wouldn’t you know it, it was vastly easier to recall her lectures when I did. I always ended up with some interesting new insights on the subject whenever I did that, and in some cases, was able to work that into essay questions during tests and papers. You cant teach what you don’t know, but you learn more when you teach. Mentoring me, mentoring you If you’re looking to be a speaker, offer to help those who are also just getting started. The act of looking critically at their abstracts and presentations will help you better critique your own. This is because you will be able to critique their work far more easily than you can your own, since you will not have the emotional connection to the work that the other speaker has to it; and once you get more accustomed to judging a work in a more objective and unemotional manner, you’ll start doing it to your own work more effectively. And yes, I can now let the cat out of the bag: All these years that I’ve been mentoring speakers, if you thought I was doing it to “give back to the community”, now you know I’m actually just a selfish conniving manipulator: this entire time I’ve been mentoring others, I’ve actually been learning more about speaking by teaching, and getting better myself as a result. What a jerk! (Well…. OK, you caught me; that’s not the only reason I’ve been doing it. I also do it because I just like teaching. And, sure, whatever, “community”, we can go with that too.) Point is, even if you try to mentor somebody who’s just getting started as you are, you’ll effectively be forming a study group, critiquing each other and learning from both positions. And that, dear readers, is a large part of how we get better. [...]

Speaking Tips: No Speaker Notes

Sat, 13 Aug 2016 03:31:26 -0700

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.

In some cases, they try to hide the fact that this is what they’re doing, and in others, they just openly make reference to them. And to many speakers, this may come as a surprise, but….

Not. A. Fan.

First reason: eyes down on the notes is just as bad as eyes down on the script on the monitor. Keep your eyes up. It’s bad enough that you have to be looking at the screen while you’re typing out the code for the demo, don’t ruin your few moments for making eye contact with the audience by giving your eyes something else to look at right there on the podium.

But secondly…. why, exactly, do you need them?

More importantly, what’s the message you’re sending?

Using speaker notes sends one of several signals to the audience, any or all of which might be true, but even if they’re not, this is still how it can/will come across:

  • This stuff is really hard, so much so that not even the presenter can get it right all the time. That means it’s REALLY hard. Matter of fact, if you don’t have the notes, you may as well just abandon hope, all ye who try to recreate this demo at home.
  • This presenter doesn’t really know the thing they’re trying to demo. I mean, if this isn’t that hard, but you’re using notes, how often have you actually ever done this? Matter of fact, how often have you even used this thing? Are you actually qualified to talk about this stuff at all?!?
  • This presenter hasn’t really practiced this demo at all, so they need the notes to remind themselves of everything they need to do during the demo. And if you haven’t practiced it at all, then how much practicing did you do for the talk as a whole? (It’s just inviting the audience to examine and criticize the talk with a keener eye.)
  • The thing I am demoing is so new and/or so fragile, if the speaker deviates from any part of the happy path, the results are likely to be as spectacular and unpredictable as they are wrong.

Is this what you’re trying to communicate to the audience?

On top of all that, what’s the first thing the audience is going to want from you after the talk? Those very same notes, so that they can follow the notes when they try to do the demo themselves at home, after the talk. Are you prepared to give them up?

If yes, then put them into a README and put the whole thing up onto GitHub. Then you can reference your README in front of the crowd, and everybody feels like they’re back ontp a level playing field.

If no, then figure out how to do the demo without having to refer to the notes, because the attendees will feel cheated and/or shorted when you refuse to turn them over. Even if you say, “Oh, these are just personal notes, it’s not that hard, you shouldn’t need them”, it doesn’t work; in that particular case, attendees know you’re LYING, you liar liar pants on fire, because you needed them yourself!

Most of the time, speakers I talk to say they want the notes because they are afraid of bombing a demo and looking bad in front of the audience. Audiences don’t care that much if you bomb a particular demo—they are willing to forgive a mistake or two, so long as it doesn’t deviate from the flow and pace of the talk as a whole.

Just say no to speaker notes in any form.

Speaking Tips: Never Memorize

Sat, 13 Aug 2016 02:39:12 -0700

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. It feels counterintuitive: If you’re not a good extemporaneous speaker, wouldn’t it make sense to have what you want to say written down, so that you don’t have to try and think and speak at the same time? You can focus on the speaking, since the thinking is already captured there on the script, and that way you can deliver a better talk. The Fallacy of the Script Frankly, I find this to be a speaking fallacy, one which is perpetuated by a variety of sources, particularly politicians. And honestly, given how badly the current Republican candidate is at spontaneously speaking to the audience, it would seem even more counterintuitive. To begin with, let’s put one thing to bed: You simply do not have the time to memorize a talk. Nobody does. I’ve been speaking for twenty years (even longer if you count my high school stint through Toastmasters), and only twice in my life have I ever delivered a memorized speech. There is simply no way I could memorize and deliver all of the technical talks I’ve delivered over the years. Do I have a few well-traveled jokes that I like to carry from one talk to the next? Sure—that’s a different scenario. A memorized speech makes more sense when it’s a one-off and it’s absolutely imperative that you deliver exactly the right words with the right nuance and the right emotion at the exact right moment. A funeral, a wedding, a commencement speech, these are places where a memorized speech is appropriate. A technical talk, not so much. And if you notice the use of the two different words there—“speech” against “talk”—it’s apparent there’s a significant difference between giving a persuasive and/or emotional speech, and delivering a technical talk. To start, the lengths are wildly different. When President Obama delivers a speech to the factory workers in Pennsylvania, he’s generally not talking for an hour—but when you do a technical presentation on OData for the local user group, generally that’s the length of time you shoudl be aiming for. (Of course, each group has its own organization and it’s own wishes, but 50 - 75 minutes is the rough range for almost all the software development conferences I’ve seen.) Secondly, Obama has a TelePrompter. You, sadly, do not. Yes, PowerPoint and Keynote will allow you to put your speaking notes right there on the screen in front of you, but the tendency then will be to put your eyes down onto the screen, and not out to the audience in front of you. And your eyes need to be on the audience in front of you—you need to read their body language to see if they’re getting it, or if they’re all confused, or if somebody has a question, even. Keep your eyes on the audience, not your notes. But lastly, Obama has speechwriters who understand how to craft the spoken work in such a way that it sounds compelling, uplifting and meaningful. All you have is you. What’s more, the spoken word and the written word sound very, very differently from one another. To see what I mean, go pick up the last technical book you’ve read, and flip to the the middle of a chapter. Now read the first three paragraphs out loud. Seriously. Go do this. I’ll wait. whistling That was awful, no? Our eyes and our ears process information very differently from one another. The eyes can pick up on patterns quickly, and slide over unessential words par[...]

Speaking Tips: Slow Down and Drink

Sat, 13 Aug 2016 02:01:18 -0700

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. It is a common theme with most new speakers that they need to slow down when they speak. And by common, I mean pretty much every new speaker (and even a few experienced ones) falls victim to this. So one of the things that I tell new speakers to do is to put a Post-It somewhere on their laptop that reads, “Slow Down and Drink”. Slow down Part of the reason a speaker goes faster during a talk is because they are nervous, to be sure. That part, you’re not going to get past until you get a little bit of experience and practice under your belt. While I wish there was a magical recipe for making the nervousness and anxiety go away, alas, I know of no such thing. And, frankly, I’m not sure I would take it even if I could; nervousness, anxiety, whatever you want to call it, is usually the dark corners of your mind trying to wind you up, and the reason those dark corners can do that is because you’re concerned about doing a good job. If you didn’t care about the quality of your presentation, you really wouldn’t be nervous, because seriously, who cares? Nail it, blow it, whatever. That nervousness is A Good Thing, so don’t be so quick to toss it away. (True story: Thirty years ago, I was attending a youth soccer/futbol referee camp hosted by the legendary referee Ken Aston. This is the man who invented the red and yellow cards, people—he was the gold standard of international soccer/futbol refereeing as you can get. During the closing ceremonies of the camp, one of the other campers asked him about his career and why he retired. He paused, then said, “You know, during my last World Cup, one of the other gents asked that same thing.” He sort of went into himself for a second to think, and then he said: “Picture this: We are standing in the tunnel leading out to the World Cup Final. Thousands of people are screaming, singing, chanting. The teams are preparing to take the field. We five are standing in the tunnel, looking out onto the pitch, having our briefing before we begin, and that question comes up. ‘How can you walk away from this?’ was sort of the implication. I said, ‘Gentlemen, extend one of your hands and hold it flat to the ground.’ They did so, and all four of them were visibly shaking. I put my own hand out, and it was steady as a rock—no nervous shaking whatsoever. I looked at them and said, ‘That’s how I know.’“) Another reason speakers tend to speed up, however, is because they labor under the misguided notion that they need to put as much material into the attendees’ brains as possible—the attendees will be so bored if I don’t, and every second I’m not piling new stuff into their heads is a second they’re going to think I’m wasting their time, and— Bzzzzt. Nope. Wrong. Attendees, like you, are human. They need time to process the information you have told them. As a matter of fact, in some cases, they may even need time to just translate your words, if your language is not their native tongue, before they can even begin to parse the meaning. Particularly for heavily conceptual talks, or new ideas that the audience hasn’t seen before, it will take them some degree of time before they can process it. Don’t believe me? Go to a standup show sometime. Watch the audience. Particularly if the comedian is a dry-sense-of-humor kind of performer, it will take the audience a second or two just to get the fact that he cracked a joke, th[...]

Speaking Tips: Critique Others

Wed, 10 Aug 2016 00:00:51 -0700

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. Note first of all that “critique” does not mean “criticize”. Where the use of the term “criticize” is, colloquially speaking, intended as a negative concept meaning “to put down” or “to find fault with”, I use the term “critique” here to mean “give honest feedback”. There’s a technique to giving feedback (the so-called “compliment sandwich”, although to me its more subtle than that), but first of all, there’s an important thing we must address. You are not your talk. It’s all too common for people to invest their ego into their work. Whether that’s code, art, fiction, or any other kind of creative or productive activity, it’s all too easy to put “us” into the work. This is made all that much easier when everybody out there is telling you to “follow your passion” and “be passionate about what you do”, which thus makes you want to pour your heart and soul into the work all that much more deeply. Unfortunately, this carries with it a large negative consequence: when the work is criticized or found less than perfect—and let’s be really clear here, your work is always less than perfect, because there is no such thing, get that through your head right now—then the criticism of the work is implicitly a criticism of you, of your ego, of your commitment to your passion, of your ability to execute, and from there it’s really short step to HOW DARE YOU QUESTION MY COMMITMENT TO THIS WORK YOU UNBELIEVABLY RUDE PIECE OF SH–. Pause. Nobody is calling you a terrible person. Nobody is saying you are worthless. Nobody is telling you that you are a waste of oxygen and food and water. Even if your talk was the worst that was ever given, that doesn’t mean you as a person are worthless. Because you are not your work. If this does not make sense to you, please return to the top of this page and try again. Nothing else I say here will make sense until you can imbibe and absorb this mantra. Still having trouble with that? Try this: When’s the last time that you said, “This code could be made a little bit clearer by using this different approach”, and what you really meant was, “I can’t believe your mother didn’t do a service to all of humanity and just strangle you in the crib”? Funny thing is, people critiquing your code—or your talks—are in the same boat as you are when you’re offering up criticism. Usually they’re trying to help. Sometimes they’re not doing it well, but hey, most of the time, you’re probably not doing it well, either. And here’s the funny thing about criticism: It becomes easier to accept criticism of your own work when you are able to criticize others’ without judgement. And, of course, when you actively encourage others’ criticism of your own work. By the way, just keep friends and family out of this. They will mean well, but they will generally tell you useless things like, “No, I thought it was wonderful! You’re so good at this!” Bleah. Yeah, I [...]

Speaking Tips: Record Yourself

Tue, 09 Aug 2016 23:43:09 -0700

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. One such tip: Record yourself when speaking. Then, actually watch the video. Many conferences are doing this for speakers, in the belief that the video of speakers delivering their content is a value-add for the conference (and frankly, that’s a whole sidebar that should be its own topic, but I’ve had my views known on that for many years, and honestly I don’t know that anybody cares anymore). Thus, I suppose the tip really should be “Record yourself giving a presentation only if the conference isn’t”, but there’s actually a few reasons to record yourself even if the conference already is. First off, it’s actually pretty easy to record yourself: Get an accomplice to do it. You’re not looking for world-class HDTV production-ready video, you just want somebody to hold a camera on you while you talk, so that you can see what you look like from the outside. Turn the video on, prop the phone on your laptop, and let it record you from there. Since a lot of technical speaking is done from behind a laptop, this will get you at least some idea of what you look like from the outside. Worst case, just bring a tape recorder or other audio recording device, and turn it on before you start. You won’t get the body language or the video, but you’ll at least hear what you sound like. The reason for this is simple: We all know what we look and sound like from the inside, but it’s actually very hard to get an honest view of what we look like from the outside. This insight can be valuable. True story: A number of years ago, I did an interview on .NET Rocks. (For those who don’t know, .NET Rocks is an Internet radio talk show that’s been around for nigh on a decade now.) What we talked about wasn’t really that important; what is important is the fact that .NET Rocks was in the habit, at the time, of doing a full transcript of the interview and posting it to their website. (This is yet another way of getting a view of what you look like from the outside.) I made the happy mistake of going to read the transcript. And discovered, right? That I had this habit, right? Of using the word right, right? As my “crutch word”. Every. Single. Sentence. Ow. It was absolutely painful to read. Which meant, of course, that it was probably just as painful to listen to if you weren’t in the habit of ignoring my crutch words (as I was). By the way, if you’re not aware of it, a “crutch word” is the term used by Toastmasters to refer to the little “space fillers” that we use in speech. Normally it’s “uh” or “um”, which is why many Toastmasters meetings will appoint someone to be the “Um Counter”, and whose job is to count the use of “crutch words” in a presentation. (Sidebar: Part of the reason we use those crutch words during spoken conversation is because we are indicating to our partners in the conversation that we’re not quite done with our thought—that you’re thinking of what you want to say next, and it’s not yet their turn to start talking. When you’re giving a presentation, that’s not a concern. But more on that in another article.) Unless y[...]

Speaking Tips: There is a Conference That Wants You

Mon, 08 Aug 2016 17:50:06 -0700

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. There is a conference that wants you This is probably one of the first obstacles most would-be speakers run into when they start thinking about speaking. They look up at the speaker on stage at the international conference and think, “Man, I wish I could be that speaker.” After some internal conversations, and maybe a few external conversations with friends and family (all of whom universally encourage them to “go for it” and “follow your passion”, which is simultaneously both encouraging and useless), they then work up a few feeble proposals, and submit it to the international conference. Then, when the rejection comes through, they think, “See? Not good enough, not going to work out”, and abandon the idea. Stupid. Think about it—if you were thinking about trying to play futbol/soccer competitively for the first time in your life, do you immediately pack up and head over to training camp for Manchester United? If you decide you want to learn to run, do you immediately fly out for the Boston Marathon? Of course not—and that’s why it’s stupid. While there are exceptions, very few first-time speakers are ever going to get the time of day from a professional speaking event. That may not seem “fair”, that may seem “exclusionary”, but it’s not unreasonable any more than it would be for the New England Patriots to put the ball in your hands during the season. Fortunately, the NFL isn’t the only game in town. Thanks to the explosion of conferences that are springing up all over the country (not to mention the world), there is, quite frankly, a shortage of speaker talent out there. If you know your stuff, and you’re willing to stand up in front of an audience, somebody out there wants you. Which means now it’s just about finding them, or helping them find you. Finding them (EDIT: My wife thought this one ended rather abruptly, and needed a few more paragraphs to it, so I decided to take her advice. The below is what’s new.) Finding conferences is become ever easier, thanks to sites like or even just plain Google, but more often than not, you’re going to prefer to follow recommendations from colleagues and peers about what shows are going on around you. However, remember, if you can’t find a conference and/or don’t want to submit to conferences yet (and frankly, you shouldn’t until you have some speaking experience underneath your belt and have some prior art to show organizers—you are recording your talks, right?), there’s always user groups in your local area. Can’t find one? Go hit Meetup and look for anything that’s in your general interest area via keyword search. Frankly, unless you live in Siberia, there’s almost a guarantee that there’s a user group or two around you. (Yes, I’m also 98% certain there’s a user group in Siberia—it’s an expression.) And if you still can’t find a meetup group, then start one! There is absolutely no reason you cannot get the experience you need (and you do need experience—speakers who’ve been thrust into conference speaking before they [...]

Speaking Tips: James Ward's Suggestions on Abstracts

Sun, 07 Aug 2016 17:46:56 -0700

James Ward also wrote an article on how to write abstracts, and I realized after I published that I forgot to call out to his article as well. Mea culpa. First off, James’ post is here, and for the most part, I think we agree on most things. Where he says “Make the title clear, concise and enaging”, I would word that differently, simply because too many readers will see “engaging” and think “cute”, which I have come to dislike. Go with simple, straightforward, and clear. Go with boring. (The body of that list item makes it more clear, I think, that he and I actually agree on this.) James then says “Start the abstract with a problem or controversial statement”. Staring with the problem is basically the “pain” part of my abstract. I dislike the idea of starting with a controversial statement, however, because I think that tends to attract the wrong kind of attendee to your session. Specifically, it goes back to the whole, “You get what you go looking for” mantra that parents have been trying to teach their kids—if you go out there looking for a fight, you’ll find one soon enough. In an abstract, if you say, “Object-orientation is dead; functional programming is here to rule the world”, several things will happen: Some of the people who will show up will show up just to argue with you. You are threatening their understanding of the universe, and in many cases you are directly threatening the tools they use to make a living, and as such, you are threatenting them. Some of the people who will show up will be functional programmers who are zealots like you profess to be, and they will either (a) turn on you if your session isn’t as zealous as your abstract suggests, or (b) “help” you during the session by yelling or shouting at would-be object-oriented hecklers. What’s worse, their behavior will often kick in even on questions asked by people who really don’t have an opinion, thus ruining the experience for them. Most importantly, the people you really want to reach will probably not show up at all. Think about it—would you attend a session feeling safe and comfortable if the abstract read, “All computer programmers are a drain on our society, and in this session, we’ll talk about how regular folks can throw off the chains of tyranny imposed on us by these pasty-white nerds and their mysterious boxes of electricity”? Probably not. Of course, if the intent of the session is to encourage that kind of argumentation, which is common for a speaker panel or some other audience-participation-driven session, then by all means, go for it. But remember, your abstract is your contract with the audience—if you don’t make good on the contract (including the salacious “Jer-ry” parts, if that’s what you promise), then you’ve failed and you’re probably going to get hammered in the evals. Next: **“Make the abstract about the content and attendee, not you”. This one, I didn’t talk about, and he’s right. In all fairness, I think this is true of much more than the abstract, and something I think is just a general approach/attitude about all speaking, but it deserves mention and I’m glad James throught to bring that out. Here we might disagree a little bit more strongly: “Clearly describe what attendees will take away from the session”. My concern hinges on the word “clearly”; many reades might take that to mean “in great detail”, and as I said earlier, an abstract is not a detailed play-by-play of what you’re going to do in [...]

Speaking Tips: How to Write Good Proposals

Sun, 07 Aug 2016 01:48:17 -0700

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. Mind you, none of these are ever guaranteed to make you a hot topic, or the next TED presenter. That, as it turns out, is the result of these tips, hard work, and a lot of experience (usually in the form of thousands of presentations). And, of course, every presenter will have their own stories, their own tools, and their own particular approach to accomplishing things. As they say on the Internet, Your Mileage May Vary. Without further ado…. Beginnings Most speaking experiences start with first getting accepted to speak at a conference, user group or some other gathering, and that isn’t going to happen until a proposal has been written and submitted to the body in question. (Yes, sometimes the conference will specifically ask someone to do a presentation for them—it’s happened to me more than once. However, that’s only happened recently, and that’s only because I have an existing body of work that they seek to draw from. Again, certainly exceptions are possible, but for the most part, you’re going to have to work your way up to get to that “invited to speak” status.) The process Generally, a conference puts out a “call for papers” or a “call for proposals”. Unless the conference is an academic conference, however, the “call for papers” isn’t really a call for papers; that’s a term that’s a holdover from the academic world, where one would write a paper, submit the paper to the conference, and offer up a short overview of the paper’s contents to the audience and take questions on it as part of the presentation. That’s not really how the modern software development conference or user group works anymore. (Whether that’s a good thing or a bad thing is, of course, open for debate.) Instead, the conference is expecting would-be speakers to submit short abstracts—usually somewhere in the 100 - 500 words range in length—describing the presentation that is being offered. Note that different conferences will have different requirements around the abstract, and that takes us to our first tip. Let’s take as a practical example the most recent (now closed) call for proposals for Seattle Code Camp, which utilized a centralized proposal tool called (Again, the “paper” here is the misnomer term I mentioned earlier; it really should be “”, but that clearly doesn’t roll off the tonue nearly as easily. It sort of trips and stumbles and bleah twists up the tongue.) Read the directions It is absolutely amazing to me how many times a would-be speaker submits a talk abstract that violates one or more of the conference’s stated requirements. It would seem to be pretty straightforward, and yet, sometimes…. First of all, note the opening and (most importantly) the closing date. While it’s often not impossible to submit talks after the closing date (depending on the conference, the number of submissions they have or haven’t received, and/or what your excuse is for why the submissions are late), it’s never guaranteed. Besides, do you real[...]