The ASP.NET Web API 2 HTTP Message Lifecycle in 43 Easy Steps

Anyone who works with ASP.NET Web API should check out this poster that Microsoft created to explain the Request/Response Pipeline that Web API utilizes. It's amazing, and if you do any work in Web API you should check it out! Right now. Yes, seriously. Go ahead, I'll wait.

I love this poster, but in my opinion it doesn't do a good job of explaining the decision logic and ideas behind each step in the pipeline. Further, it doesn't explicitly tell you exactly how many things happen during this pipeline (answer: a surprisingly large number of things). In short: it's awesome, but it can be made more awesome by incorporating just a little more detail.

Here's what we're going to do in this post: using that poster, we're going to enumerate every single step involved in processing a request and receiving a response using ASP.NET Web API 2, and explain a little more about each piece of the pipeline and where we programmers can extend, change, or otherwise make more awesome this complex lifecycle. So let's get going and step through the ASP.NET Web API 2 Request Lifecycle in just 43 easy steps!

The 43 Steps

It all starts with IIS:

  1. IIS (or OWIN self-hosting) receives a request.
  2. The request is then passed to an instance of HttpServer.

  3. HttpServer is responsible for dispatching HttpRequestMessage objects.

  4. HttpRequestMessage provides strongly-typed access to the request.

  5. If one or more global instances of DelegatingHandler exist on the pipeline, the request is passed to it. The request arrives at the instances of DelegatingHandler in the order said instances were added to the pipeline.

  6. If the HttpRequestMessage passes the DelegatingHandler instances (or no such handler exists), then the request proceeds to the HttpRoutingDispatcher instance.

    • HttpRoutingDispatcher chooses which routing handler to call based on the matching route. If no such route exists (e.g. Route.Handler is null, as seen in the diagram) then the request proceeds directly to Step 10.

  7. If a Route Handler exists for the given route, the HttpRequestMessage is sent to that handler.

  8. It is possible to have instances of DelegatingHandler attached to individual routes. If such handlers exist, the request goes to them (in the order they were added to the pipeline).
  9. An instance of HttpMessageHandler then handles the request. If you provide a custom HttpMessageHandler, said handler can optionally return the request to the "main" path or to a custom end point.

  10. The request is received by an instance of HttpControllerDispatcher, which will route the request to the appropriate route as determined by the request's URL.

  11. The HttpControllerDispatcher selects the appropriate controller to route the request to.

  12. An instance of IHttpControllerSelector selects the appropriate HttpControllerDescriptor for the given HttpMessage.
  13. The IHttpControllerSelector calls an instance of IHttpControllerTypeResolver, which will finally call...
  14. instance of IAssembliesResolver, which ultimately selects the appropriate controller and returns it to the HttpControllerDispatcher from Step 11.
    • NOTE: If you implement Dependency Injection, the IAssembliesResolver will be replaced by whatever container you register.
  15. Once the HttpControllerDispatcher has a reference to the appropriate controller, it calls the Create() method on an IHttpControllerActivator...
  16. ...which creates the actual controller and returns it to the Dispatcher. The dispatcher then sends the request into the Select Controller Action routine, as shown below.

  17. We now have an instance of ApiController which represents the actual controller class the request is routed to. Said instance calls the SelectAction() method on IHttpActionSelector...

  18. ...which returns an instance of HttpActionDescriptor representing the action that needs to be called.

  19. Once the pipeline has determined which action to route the request to, it executes any Authentication Filters which are inserted into the pipeline (either globally or local to the invoked action).

    • These filters allow you to authenticate requests to either individual actions, entire controllers, or globally throughout the application. Any filters which exist are executed in the order they are added to the pipeline (global filters first, then controller-level filters, then action-level filters).
  20. The request then proceeds to the [Authorization Filters] layer, where any Authorization Filters which exist are applied to the request.

    • Authorization Filters can optionally create their own response and send that back, rather than allowing the request to proceed through the pipeline. These filters are applied in the same manner as Authentication Filters (globally, controller-level, action-level). Note that Authorization Filters can only be used on the Request, not the Response, as it is assumed that if a Response exists, the user had the authorization to generate it.
  21. The request now enters the Model Binding process, which is shown in the next part of the main poster. Each parameter needed by the action can be bound to its value by one of three separate paths. Which path the binding system uses depends on where the value needed exists within the request.

  22. If data needed for an action parameter value exists in the entity body, Web API reads the body of the request; an instance of FormatterParameterBinding will invoke the appropriate formatter classes...

  23. ...which bind the values to a media type (using MediaTypeFormatter)...

  24. ...which results in a new complex type.

  25. If data needed for a parameter value exists in the URL or query string, said URL is passed into an instance of IModelBinder, which uses an IValueProvider to map values to a model (see Phil Haack's post about this topic for more info)....

  26. ...which results in a simple type.

  27. If a custom HttpParameterBinding exists, the system uses that custom binding to build the value...

  28. ...which results in any kind (simple or complex) of object being mappable (see Mike Stall's wonderful series on this topic).

  29. Now that the request is bound to a model, it is passed through any Action Filters which may exist in the pipeline (either globally or just for the action being invoked).

  30. Once the action filters are passed, the action itself is invoked, and the system waits for a response from it.

  31. If the action produces an exception AND an exception filter exists, the exception filter receives and processes the exception.

  32. If no exception occurred, the action produces an instance of HttpResponseMessage by running the Result Conversion subroutine, shown in the next screenshot.

  33. If the return type is already an HttpResponseMessage, we don't need to do any conversion, so pass the return on through.

  34. If the return type is void, .NET will return an HttpResponseMessage with the status 204 No Content.

  35. If the return type is an IHttpActionResult, call the method ExecuteAsync to create an HttpResponseMessage.

    • In any Web API method in which you use return Ok(); or return BadRequest(); or something similar, that return statement follows this process, rather than any of the other processes, since the return type of those actions is IHttpActionResult.
  36. For all other types, .NET will create an HttpResponseMessage and place the serialized value of the return in the body of that message.

  37. Once the HttpResponseMessage has been created, return it to the main pipeline.

  38. Pass the newly-created HttpResponseMessage through any AuthenticationFilters which may exist.

    • Remember that Authorization Filters cannot be used on Responses.

  39. The HttpResponseMessage flows through the HttpControllerDispatcher, which at this point probably won't do anything with it.

  40. The Response also flows through the HttpRoutingDispatcher, which again won't do anything with it.

  41. The Response now proceeds through any DelegatingHandlers that are set up to handle it. At this point, the DelegatingHandler objects can really only change the response being sent (e.g. intercept certain responses and change to the appropriate HTTP status).

  42. The final HttpResponseMessage is given to the HttpServer instance...

  43. ...which returns an Http response to the invoking client.

Tada! We've successfully walked through the entire Web API 2 request/response pipeline, and in only 43 easy steps!

Let me know if this kind of deep dive has been helpful to you, and feel free to share in the comments! Microsoft people and other experts, please chime in to let me know if I got something wrong; I intend for this post to be the definitive guide to the Web API 2 Request/Response Lifecycle, and you can't be definitive without being correct.

Happy Coding!

15 Fundamental Laws of the Internet

(AKA How To Sound Smart In Your Next Online Rant)

Wiio's Law

What is the internet? The internet is, at heart, a communication tool, a way for disparate people across the globe to spread ideas, opinions, and generally communicate with each other more easily than has ever been possible. Unfortunately, communication is hard.

Finnish academic Osmo Antero Wiio formulated a serious of humorous laws that succinctly explain how communication works between humans; specifically, that it doesn't. The set of laws Wiio created are often summarized as Wiio's Law:

"Communication usually fails, except by accident."

So maybe, instead of being angry that people didn't get what we said, perhaps we should merely be pleased when, against all odds, they actually understand what we are saying.

Kranzburg's First Law of Technology

Melvin Kranzberg was a professor of history, specifically the history of technology (and, apparently, a WWII-era interrogator. Office hours must have been stressful for his students). Kransberg formulated a series of laws about technology and its place in history, most famous of which is his First Law of Technology:

"Technology is neither good nor bad; nor is it neutral."

In other words, technology is not inherently anything; it's value is imposed upon it by whomever uses it. Technology itself has no intrinsic value. Perhaps this is why Apple removed the headphone jack from the iPhone.

Sturgeon's Law

Ever wonder why the vast majority of things on the internet are terrible? So did Theodore Sturgeon, except for everything. Sturgeon was a science fiction and horror writer, and he was appalled that most science fiction of his day was utter trash. Hence he coined Sturgeon's Revelation, which is now more widely known as Sturgeon's Law.

"90% of everything is crap."

Yes, everything. Makes me wonder if he included his own work in that statement.

But it's not all tongue-in-cheek: Sturgeon's law has been cited by noted philosopher Daniel Dennett as one of his critical tools for thinking. So not only is 90% of everything crap, the awareness of this fact is important to be properly aware of critical thinking. Yay for not liking anything ever!

The 1% Rule

The 1% Rule is an adage which states:

"Only 1% of the users of a website actively create new content, while the other 99% of the participants only lurk."

In other words, most people just sit in the metaphorical shadows and read what the 1% write. This is particularly interesting to think about in the context of designing communities like reddit or Stack Overflow, since if only 1% of the people will create content, how do the site owners get the 99% to stick around and read things? Unless you get incredibly lucky, figuring out how to make both the 1% and the 99% happy is very tricky, and only a few sites get it right.

Dickwad Theory

If you don't like swearing, you'd best skip this section. The Dickwad theory was put forth in the online comic strip Penny Arcade, and states:

"Normal Person + Anonymity + Audience = Total Dickwad"

Ever wonder why trolls exist on the internet in exponentially greater numbers than in real life? Dickwad theory proposes the reason: when a normal person received total anonymity and an audience, s/he loses all their inhibitions and promptly starts to act like a total raging asshole. Anyone who has been on the internet long enough has encountered someone who proves this theory, and if they say they haven't, it's because they themselves are proving it.

Dickwad theory is apparently also known as online disinhibition effect, but that's not nearly as interesting a name for this phenomenon.

Godwin's Law

The next few laws relate to how people communicate on the Internet, specifically how they use text. This particular adage is the one law on this list that, most likely, everyone has heard of. Godwin's Law was written by attorney Mike Godwin on a Usenet group in 1990, and it states the following:

"As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one."

What's particularly interesting about this law is that Godwin himself deliberately and repeatedly posted this law anywhere he could, according to a 1994 article written by him and published in Wired. He specifically calls it "meme engineering" (as he invented the idea of an "internet meme"), and it remains possibly the most successful case of this yet seen.

Poe's Law

There's an inherent problem in trying to communicate via text: the inflection and intonation that is so readily apparent in verbal speech is missing. Consequently, what would be obvious when spoken might be missed when written down.

Poe's Law (named after Nathan Poe, who wrote the original formulation of it in 2005) states the following:

"Without a clear indicator of the author's intent, parodies of extreme views will be mistaken by some readers or viewers as sincere expressions of the parodied views."

No matter how obvious it is that you are making fun of something, unless you explicitly state that you are doing so, someone somewhere will think you are being serious.

The original text of this law cited Creationism, but it has been repeatedly proven to be true for any sufficiently contentious topic (by which I mean: all of them).

Skitt's Law

One of the more obscure laws on this list is Skitt's Law, which states:

"Any post correcting an error in another post will contain at least one error itself."

I'm tempted to think of this as the Law of Glass Houses, after the famous proverb, "Those who live in glass houses should not throw stones." At any rate, Skitt's Law demonstrates an incontrovertible fact about the internet: if you feel the need to correct someone else, you'd best be prepared for someone to correct you.

Law of Exclamation

Punctuation can actually be a tip-off as to whether or not what you are reading is total crap. The Law of Exclamation says:

"The more exclamation points used in an email (or other posting), the more likely it is a complete lie."

An example of this law is found in the novel Reaper Man by Terry Pratchett, one of his Discworld series. In it, a character states that "five exclamation marks [are] the sure sign of an insane mind." Remember this next time you think you need more than one exclamation point (and are not a teenager).

Cunningham's Law

The modern internet owes a lot to Ward Cunningham, a programmer who among other things invented the wiki. He's also known for having his name attached to a particularly keen insight into how questions and answers work on the internet (though he didn't originate this law; his coworker Steven McGeady did). Cunningham's Law is usually written as follows:

"The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer."

McGeady even cited a site that relies on Cunningham's invention as the best proof of the truth of this law: Wikipedia.

The Wiki Rule

Speaking of wikis, there's another theory that states that there is a wiki for anything. It's called The Wiki Rule:

"There's a wiki for that."

Yes, that. And that. And even that. If you can think of it, if it has at least one fan out there, there's probably a wiki for it, and some of these wikis can get astoundingly large.

Danth's Law

Ever get into an argument on the internet? Stop lying; of course you have. Have you ever been able to figure out who actually won said argument? Danth's Law gives you this handy tip:

"If you have to insist that you've won an Internet argument, you've probably lost badly."

Because if you'd actually won the argument, you wouldn't need to argue that you did.

Law of the Echo Chamber

Let's be real for a second: in a lot of ways, the Internet has made modern life easier and more accessible, but in some ways the promises of this great web of information simply haven't materialized.

The idealistic goal of the internet was to be democratic, to show us all sides of any possible argument in a non-biased way. Problem is, people are inherently biased, and the internet is run by people, so that bias leaks in. In fact, it leaks so much that more often than not your circle of internet friends is populated by people who subscribe to the same opinions you do.

I therefore propose something I've been calling the Law of the Echo Chamber:

"If you feel comfortable enough to post an opinion of any importance on any given Internet site, you are most likely delivering that opinion to people who already agree with you."

Munroe's Law

There is a corollary to the Law of the Echo Chamber, which I've taken to calling Munroe's Law after the cartoonist who draws and publishes the comic xkcd. A while back Randall Munroe posted the following cartoon, and it has since become something of a meme.

We've all been there. That comic is merely a funny way of stating the following:

"You will never change anyone's opinion on anything by making a post on the Internet. This will not stop you from trying."

Golden Rule of the Internet (AKA Wheaton's Law)

The traditional phrasing of the Golden Rule is "do unto others as you would have them do unto you." Actor and writer Wil Wheaton coined a slightly shorter version which has occasionally been referred to as Wheaton's Law:

"Don't be a dick"

Because sometimes it really is just that simple.


Many of the laws enumerated above don't apply to just the internet; they apply to life and behavior of humans in general. This is, of course, intentional. After all, the users of the internet are people, regardless of what they want you to think they are.

Did I miss any fundamental laws of the internet that you've found useful? Feel free to sound off in the comments!

Happy Coding!

Mind of the Speaker - How Do You Feel About Your First Presentation?

The first time we do anything, we're terrified. Asking out that first date, submitting that first patch, reviewing someone else's code for the first time. Surprisingly, how we feel about it (e.g. "OH MY GOD I DON'T KNOW WHAT I'M DOING") has very little to do with how well we actually do at it; sometimes we're right and we end up doing terribly, and other times we're wrong and it ends up going well. It's different for each person.

In October of this year (2016), I attended the DevIntersection/AngleBrackets conference in Las Vegas, as I did twice last year. Once again, as I am fascinated with the process involved in speaking for tech conferences, I tracked down as many speakers as would talk to me and asked them three simple questions:

  1. Who are you, and what do you do?
  2. What is the most important thing for a speaker to remember while they are on stage?
  3. What was your first conference-level presentation about, and how did it go?

NOTE: A couple speakers couldn't remember their first conference presentation, so instead I asked them about a particularly memorable one.

This blog post gathers the answers I got to the third question: What was your first conference-level presentation about, and how did it go? The answers I got varied mightily, both in how well they thought the presentation went, and how well they thought it was going to go.

Don't Bother Applying

Let's get the worst out of the way: sometimes you do so bad at your first conference presentation, the conference doesn't want to have you back. Ever.

Kathleen Dollard (.NET coach and Director of Engineering, ROI Code): "Oh, terrible. It was some terribly-named thing like 'Data in the Dog House' or something stupid like that. I absolutely bombed. I was so bad. I won't tell you what conference it was, but it was a conference that [told me], 'yeah, don't bother to apply again.' But [my colleagues] told me, 'you shouldn't quit,' and I said, 'oh, ok, I'll try again.' It was terrible, absolutely terrible."

Technical Issues

The bane of any tech speaker's existence is technical issues, especially ones they can't control and are powerless to change.

Dan Wahlin (consultant, author, founder of Wahlin Consulting): "I think one of the more memorable ones would have been a TechEd one I did. We had some serious technical issues. In that case, I'll have to admit, I don't think I was [prepared], because I just assumed that you show up and everything works; that you're just there to speak. So being prepared for the things that don't go so well, goes a long way."

John Papa (Pluralsight author, speaker): "One of [my presentations] that was not so great, because they're more fun to talk about, was when I was on stage and talking about a topic (I think it was ADO and RDS, one of my earliest talks), and we had some technical difficulties again. The slides didn't work at all. So I had to do an hour-long presentation without slides. Part of the [problem] was, within a minute, I realized it just wasn't going to work. Nothing was working. So I was like, "well, now I've got to teach for the next 59 minutes about this topic without any computer. [But I can say] that it was a good experience, in the sense that I realized that I didn't need the visuals to do it. It was also good to realize [what] Dan mentioned: have backups, be prepared. It was humbling, because I know it didn't go as well as it should have."

Sometimes, though, the technical issues are caused by your own worst enemy: yourself.

Javier Lozano (Owner of LozanoTek): "[It] was many, many years ago on WCF. It went surprisingly well, [and] the reason why I say [surprisingly] that is that I did something very stupid. WCF was in beta, and I upgraded to the latest beta bits. Just the bits, but not my code, and my code wouldn't work. So I'm freaking out thirty minutes before [my talk], trying to undo all that, and it was very, very painful. Out of all of the demos, I was able to get four of them working, rather than the eight that I had to show. It was one of those [things where] I apologised to everybody, because it was a stupid mistake [to] upgrade all of the stuff. That was a lesson that I never, ever repeated."

Wrong Format

Occasionally speakers, who at their core are really teachers, get up to present a session and realize that the format of that session is just completely wrong for their current environment:

Phil Japikse (Consultant, speaker, author, blogger ( "My very first conference-level presentation was about the data access blocks in .NET, and it went terrible (sic). I do a lot of instruction [and] classroom-style teaching for customers, and I'd been doing that for years. A buddy of mine was running a show, and he knew I was teaching. He had an open slot, and he says 'will you come give a talk on the data access blocks?' I said, 'sure! I use them all the time.' So I built a classroom-style presentation for a code camp, and realized pretty quick that that's not the right format. I was trying to teach like [I would] in a classroom, as opposed to just step back and get people excited about it and move on. So I learned pretty quick to adjust my style."

Someone Else's Content

One speaker had what seemed to me to be a rather unique experience: she was presenting someone else's content!

Julie Lerman (Consultant, Vermonter, blogger at The Data Farm): "It might have been at a Microsoft community event in Boston, oh, a thousand years ago. Microsoft tech [had] developer evangelists at the time, although that's not what they were called. It was people from the community doing [the] speaking, and it was a really big deal, and they gave you the content to do, so it was really hard. My talk was [something] like 60 slides, and I had a half an hour to talk, or something like that. It wasn't my content; I had to do somebody else's talk! The first time I did [that talk], it went so badly. It was so bad; I couldn't even believe that I could be so bad. And then we did a new iteration; we did that whole thing again with the same people, [about] a week later, and I totally nailed it!"

Roller Coaster Ride

A couple speakers had a wild, up-and-down experience doing their first conference-level presentation. In one particular case, a speaker was thrown into the fire, so to speak, and ended up with people clamoring to get into his sessions:

Mark Miller (Chief scientist at DevExpress, expert in great design): "I think my first one was pretty crazy. I substituted for another speaker that couldn't make it because his wife was having a baby. I was kind of irreverent and nobody had ever seen anything like that before; they were used to a professional setting. I had three different talks at that conference, and by the last talk I had people following me and trying to get in to my sessions (because everybody was like 'who's this guy?'). I remember getting into my last session, and there was just a crowd of people trying to get into it. I was trying to get by them, and somebody was like 'who's this guy?' and some other guy [says] 'some hotshot speaker!'"

For at least one presenter, the presentation started out really well and ended, well, differently:

James Ashley (Freelance HoloLens developer at Imaginative Universal, Microsoft MVP - Emerging Experiences): "I can't remember my first [conference presentation], but I'll tell you about one that I remember really well. I'd picked a new technology topic and was feeling sick, so I showed up thinking I would get some small corner room somewhere (this was a conference in Tennessee). Instead I got a thousand people in the room. I totally bombed it. Lost my place, got overwhelmed, barely dragged my way to the end. Yeah, that was great experience."

My head is still spinning from that one.


I firmly believe the best way to give a stellar presentation is to practice the hell out of it, and a few of the speakers agreed with me.

Robert Green (Developer Evangelist and speaker, Microsoft): "[Laughs] Oh boy. I might wind up dating myself. I believe my first [presentation] was on doing client-server development in FoxPro. It went fine, because I knew a lot more about it than the people in the room. I go to a talk to learn. I don't necessarily go to a talk to hear the world's foremost expert on something. If I can, that's great, but I go to a talk to learn. So I think people learned a lot in that talk, and so I think it went pretty well. If you want to be a speaker, of course you need to know your subjects, but you don't have to be the world's foremost expert to teach people thing."

Tim Huckaby (CEO of InterKnowlogy, software guy): "I worked on a server produce team at Microsoft in '98. I was just a lowly dev on an architecture team, but all the business people, all the [project managers], were busy. Back then Microsoft had this conference called TechEd. [It was] an enormous conference. And they said, 'well, Huckaby has a personality, let him do the presentation,' since none of them wanted to do it. So I did, and it went amazingly well. I prepared the hell out of it, I studied the hell out of it, I knew the product like the back of my hand, because I'd worked on the product. I just had all this insight that I'd gathered up from the team and my experience. It was the highest rated presentation in the conference. And it was the first time I'd ever done it! They're like 'oh my God, you were awesome,' and I'm like 'really? I though I was horrible.' Because we're all our own worst critics."

People Showed Up!

Because presenters do tend to be their own worst critics, sometimes speakers are just surprised anyone showed up at all.

Jes Borland (Senior SQL Server Engineer, Concurrency): "My was in 2011. I presented at a SQL Saturday, and my topic was completely not technical. It was 'Make Your Voice Heard,' and how to further your career through using forums and blogging and Twitter and LinkedIn. It was great! People had so many questions. They wanted to know how I had gotten started with those things. They wanted to know what my tips for success were. They genuinely looked up to me. Being able to do that was awesome."

Erin Stellato (Principal Consultant, SQLSkills): "My first conference-level presentation was in 2011, and it was specific to capturing baselines in SQL server. I was on the last day of the conference in the last timeslot, and was of course concerned that no one would show up. Lo and behold, people did show up, and I had questions and I had good feedback from that, and it ended up being a great experience."

Credit Where It's Due

One speaker credited his first talk going so well to a person who'd inspired him to do it in the first place.

Pete Brown (Music app and Internet of Things developer, Microsoft): "I was just thinking about this the other day, because I owe a lot of that to a guy who was a vice president at the last company I worked at; his name was Tom O'Connell. He got me in to speak at an event called Explorer 99, and I was talking about a Visual Basic library we wrote to make it really simple to build forms-over-data applications, where all the entities and everything inside the VB app and all the rules [and so forth] were generated from UML models. I thought it went pretty well."

Following the Big Name

One speaker was terribly nervous to even give his first presentation, due to the fact that he was following a big name in his field:

Burke Holland (Developer Advocate, Progress Software): "My first conference presentation was on HTML5 when [that] was a new concept. I was sent to TechDays in Canada, and I had the first session after the keynote in the keynote room. The keynote was by Scott Hanselman, who I did not know and had never seen a keynote from before. So as a speaker, I had to get up there on stage, after [Scott], and be like, 'well, I hope you enjoyed that, and now... this.' And it went great! It was a great experience, but it was absolutely terrifying."

How Was Your First?

As you can see, many speakers did well, and many did terribly. But, considering the fact that I got to interview them at all, their experiences with their first conference-level presentation didn't stop them from doing more.

Have you done presentations of any kind, not just at conferences? If so, do you remember your first one, and how did it go? Share in the comments!

Happy Coding Speaking!

Post image is Hayat Sindi, found on Flickr and used under license

Mind of the Speaker - The Most Important Thing To Remember On Stage

I've always been fascinated by the idea of getting up in front of hundreds of strangers and being expected to present your ideas to them. It's simultaneously enticing and terrifying, and that's probably what draws me to it.

In October of this year (2016), I attended the DevIntersection/AngleBrackets conference in Las Vegas, as I did twice last year. Once again, as I am fascinated with the process involved in speaking for tech conferences, I tracked down as many speakers as would talk to me and asked them three simple questions:

  1. Who are you, and what do you do?
  2. What is the most important thing for a speaker to remember while they are on stage?
  3. What was your first conference-level presentation about, and how did it go?

The answers to the third question will be their own separate blog post, so for now I want to focus on the answers the speakers gave to the second question. What should a speaker remember while they are on stage? Let's find out!

The Basics

First off, let's review the basic things a speaker should remember while they are on stage:

John Papa: "Their name."

Dan Wahlin: "To turn the mic off before they go to the restroom."

Phil Japikse: "To zip their fly. [It's] really key."

Julie Lerman: "I forgot."

Remember these things, and you're already well on your way to delivering a spectacular presentation.

OK, let's be serious for a bit. In any presentation, there are two incontrovertible pieces: the speaker, and the audience. Each of the presenters I talked to mentioned one or other, in some form, as the most important thing to remember when on stage.

The Speaker

This is who everyone in the audience is here to see. Some people show up at a presentation for the content, and some show up because they know who's talking about it. A speaker's job is to convey his ideas and content thoughtfully and clearly. But what about the speaker's job is important, and how can they effectively communicate their point to tens or hundreds or even thousands of people at a time?

Body Language

A human's body language can tell you a great deal about them without the need for words. One presenter said he can improve the audience's ability to remember his key points by focusing on what his body language silently tells his audience:

Tim Huckaby (CEO of InterKnowlogy, software guy): "For me, it's body language, eye contact, and speaking TO the audience as opposed to AT them. That means moving around, wandering the stage, making sure you get eye contact as best you can. That keeps people engaged. The average human only digests about one-eighth of what you're talking about in an hour-long session. To improve that percentage, you move around, you're physical, and you're making eye contact [or] at least appearing to make eye contact with the audience.

Another mentioned his energy level will reflect his audience's:

James Ashley (HoloLens developer, Imaginative Universal): "For me personally, it's the energy level. As long as you have [a] good energy level, you can get through any talk. You can be totally senseless. But if you're engaged with the audience, they'll ride with you the full way."


For many presenters, the act of giving a presentation is analogous to telling a story.

Erin Stellato (Principal Consultant, SQLSkills): "You have a story to tell. Hopefully you've crafted that as part of your session. This is your experience that you're sharing, so it's going to be authentic, it's going to come from what you've learned and what you know. Trust in that [authenticity] as you're presenting that material."

Robert Green (Developer Evangelist, Microsoft): "You are up there telling a story. So before you give a talk, [ask] what is your story? What are you going to cover? What do you want people to learn at the end of it? Whether you're speaking for 20 minutes, 60 minutes, 75 minutes or a whole day, you're up there to tell the story. Understand your story, and how to tell your story, and then the rest is just slides and demos."

One speaker confessed that it is sometimes difficult to remember the story you've created:

Burke Holland (Developer Advocate, Progress Software): "For me, the most important thing to remember is what I am actually going to say when I get up there. That's probably the hardest part. As long as I've been doing this, it's so easy to get up there with your slides that you've rehearsed about twenty times, and go 'I have no idea what I was going to say on this slide, and I have no idea what I'm going to say on the next slide.' I've been speaking for about ten years, and I'm as nervous now as I was the very first time."


People go to presentations for the content. So how can speakers make sure they have the most important and effective content they can present?

Billy Hollis (Consultant, user experience designer): "The biggest thing is that there ought to be a unifying theme to what they're trying to communicate to the audience. Every session should have one big idea, or at most two big ideas, [and] everybody ought to walk out with those ideas in mind. You construct your session around that [theme] and while you're walking around talking about it, you always should have [those] one or two themes forefront in your mind."

Ben Miller (SQL Server expert, "[Remember that] the attendees are looking to get something out of it. You need to make sure that you're knowledgeable; that you speak clearly; that you articulate the things that you want to [say]; [and] that you accept questions."


A few speakers, rather than keeping their content or unconcious body language in the forefront, choose instead to zero-in on their on-stage behavior:

Dan Wahlin (consultant, author, founder of Wahlin Consulting): "Probably time. Otherwise what ends up happening is at the end, if you don't keep on top of [the time], then it looks like your whole thing was rushed even though you did a great job for three-quarters [of the presentation]. So I'd say time is one of them."

Joe Guadagno (Software Architect at QuickenLoans): "That you are going to get a question that you don't know the answer to, and that's okay, as long as you take the attendee's information down and tell them you'll reach back to him or her with an answer. It's totally fine to not know the answer."


Finally, one speaker felt it was important to remember that he wasn't the most intelligent person in the room:

Phil Japikse (Consultant, author, blogger at "What I always try to remember is that I'm not the smartest person in the room; I'm the one who was brave enough to get up and talk about [the topic]. I try to learn from my attendees as much as I try to teach. In an hour, or an hour and fifteen minutes, I'm really not going to teach anybody anything; [rather], it's my opportunity to get someone to be enthusiastic about it. If I can get them excited and thinking about it and saying, 'hey, I should do more research into [this],' then as a speaker, I've won."

The Audience

The other, and arguably more critical, part of any presentation is the audience. The audience is more important than the speaker in several ways. First, it is remarkably easy to have a speaker with no audience; just go to any downtown area and look for loud, brightly-dressed people yelling and swinging books around. Second, the entire purpose of a presentation is to educate the audience about something; if no education happens, was it a presentation, or just a speech?

The audience is critical to any presentation. But how do we cater our presentations to the audience that shows up?

Who Are They?

Let's start at the beginning: who is your audience anyway? A couple of speakers made a very basic point: your audience is made up of people.

Pete Brown (Music app and Internet of Things developer, Microsoft): "The other [thing to remember] would be the audience that you are speaking to: knowing what they already know, knowing what they don't know, understanding where their kind of humor lies, where their interest lies. "

Aaron Bertrand (Product Evangelist at SentryOne): "Everybody in the audience are people just like them (the speaker). I think a lot of people get nervous because they think that there's a lot of judgment going on, or if they make a mistake that's the end of the world, and that's just not the way it is. The people in the audience identify with you. [They know] that you're just a normal person, just like they are."

Not only is the audience made up of people, those people have perspectives that are just as valid as yours:

Kathleen Dollard (.NET coach and Director of Engineering, ROI Code): "That the people in the audience are what it's about. It's really easy to get caught up in the technology, because we get so passionate about [that], but it's really all about the people who are out there, how much they can handle, what they care about, what's important in their world. It's really important to look at it from their perspective and not just your perspective."

On Your Side

Here's the thing about audiences: if they showed up at all, they did not show up to see you fail:

Scott Hanselman (Blogger and Principal Community Architect for ASP.NET, Microsoft): "Remember that the audience is very likely on your side. In this particular instance, where [I] just got off stage at DevIntersections, my computer crashed, which was embarrassing. But the question is: does the audience care about that? [Do] they want me to fail? Or do they want me to succeed? So if I know that they want me to succeed, then I have less to worry about and I [don't] feel so bad. I'm still embarrassed that it crashed, but I was able to recover, and the audience cheered along [because] they were on my side."

Another speaker presented (see what I did there?) this same idea very plainly:

Jes Borland (Senior SQL Server Engineer, Concurrency): "Everyone in the audience is there because they want you to succeed. No one is there to say, 'oh, this person doesn't know their stuff.' They're there to learn from you! When they sit in your session, they want to hear from you. People are there to see you succeed."


Once you get past the irrational fears of judgment, the tricky part becomes trying to engage your audience in a meaningful way. That engagement starts by making everyone feel included:

Julie Lerman (Consultant, Vermonter and blogger at The Data Farm): "I try to make an effort to look across the whole audience instead of focusing on certain people, so everybody feels like I'm talking to them. If people ask questions, remembering to repeat the questions. It's sometimes difficult, but [I also try] to stay cool, calm, and collected."

Eye contact seems to be particularly salient to being an effective speaker:

Mark Miller (Chief scientist at DevExpress, creator of The Science of Great UI): "The most important thing is that you are there for the audience. You are there to communicate with them. So it's important to look everybody in the eye, to get a sense of where everybody is, and to react and respond to where they are."

Let's face it: to most people, tech-inclined or otherwise, the vast majority of technology presentations are boring. One speaker is keenly aware of this problem:

John Papa (Blogger, Pluralsight author and trainer): "For me, it's about engaging with the audience. Whatever you're talking about, especially in the technology world, it's usually not interesting to most people. We can be very boring people! You only have certain weapons with you: you've got your slides, you've got your demos, you've got your voice, and you've got your body language. You should use all those. You want to be interesting, you want to be engaging, and you want to keep people moving."


If you can believe that the audience is on your side, and you engage with them meaningfully, the result is the holy grail that most speakers strive for: relatability.

Javier Lozano (Owner of LozanoTek): "To me, the most important thing is... trying to connect with the audience. I could be behind a podium pontificating, and I'm going to lose people. So, I try to figure out how I'm going to share the content that I have as a story, so people can understand that 'hey, this is important.' But it's important in a 'here's how [this] relates to you' [kind of way]. That's the thing that I see as most important, because if people are going to be tuned out, then they can find a [better] use of their time than just listening to me talk."

One presenter effectively combined many of the previously-espoused ideas about the audience and decided that the ultimate goal is to help people:

Jeff Fritz (Program Manager for ASP.NET, Microsoft): "When I think about [being] a speaker on stage, I think about [how] I want to be relatable to my audience. The folks that are there learn from me, they're developers just like I was, sitting in that room 2-3 years ago. I want to be as relatable as possible and as accessible as possible, because people are going to walk away from that talk, and they are going to have things that they are going to remember about me. When they come back and have follow-up questions, if I'm accessible and relatable, they'll reach out to me on Twitter, they'll put a comment on my blog, and they'll ask those follow-up questions.

"Now, I've got a relationship with them, that make me more than just a speaker. It makes me a resource that people can work with."


It's difficult to pin down exactly what the most important thing to remember while on stage actually is. Some believe it's your body language; some, that the audience is not out to get you; some, that there should be an overarching theme; and some, that you'd better be sure of when your mic is off (or worse, on).

But there's no denying that each of the ideas espoused by these speakers is important to some degree. Using each of these ideas, as well as incorporating your own style and mannerisms, is key to delivering an effective, useful, powerful presentation that the audience will remember and refer back to.

Oh, and don't forget to zip your fly. That's really key.

Happy Coding Speaking!