One of the .. I was asked a question during the livestream last time, or one
of the questions after the live stream, which was because I was talking about...
When you're doing a presentation you need to have one key point in mind. Keep
it always in the back of your mind. So that as you're talking you have
something to fall back on. As you're building your talk you can tailor it as
a result. So I thought I'd show you some of the key points I've used in the last
two talks I've done, and in the talk that I'm about to do this afternoon or
this evening . So I did an ask me anything online. And because it's and "Ask Me
Anything", the key point was really for me. The key point was to keep me on track.
So that when I am answering questions, I wanted to not have absolutes, I wanted to
try as much as possible to convince people that I was answering from my
experience and explaining them as individual models of me. So this was
because we're getting lots of questions there on different topics. But the
key point was an indicator for me; to always try and explain the reasoning
behind what I was saying. And why I'm saying things in a certain way.
And What the answer is related to. so that's one instance of the key point. It was
there to keep me on track, to have an overriding aim across all of the content
and questions. At the joy of coding conference that I did last week... and you
can see that I had a bunch of stuff in my outline. But I also had a key point.
Which was, and this key point, this... What was important was that this key point changed
over time. Right. Because the key point started with "I aspire to be a software
developer". Right, and everything that I was doing was related to "how does this
concept fit into the notion of software development?". And over time I realized as I
was writing this that the key point was really that "we're aspiring to be
solutions developers." That whilst all the different aspects of a software
development role are important and we can learn
as many as possible. It really doesn't make any difference unless what we actually
build is a solution. So we should be aspiring to be a solution developer.
And I kept that in the back of my mind so that all the examples and lessons
learned were related to that, and building up that concept. When I'm doing
a talk later on today. About "automating pragmatically". My key point is
that we need to own the models that we're using in order to interpret all
the stuff that we hear, we need to own and interpret models rather than just
adopt them completely. So everything that I'm saying is related to this. All the
examples are related to this key point. So when I talk about having a key point
in the back your mind, it is regardless of all the different things that you want
to talk about. Because there's gonna be lots of different things you want to
talk about. There's going to be lots of points you want to make. But overriding
that is a key point. And that's going to help you filter it, and help you answer
questions and address this. So those are direct examples from work that have done.
Because this is something that I do when I'm building talks. When I'm trying to
create a blog post, I'm trying to work out what is the key message here that I need to
tie it back to. And if I do that I can filter out different concepts and they
can be useful for other content later on. I don't have to try and cram everything
in. So when you hear people go "here
I've squeezed my 45 minute talk into 15 minutes" that is possible to do, much more
easily, when you have a key point that is overriding it. Because if you can funnel
that key point in you can see what is most appropriate. So this is something that
massively helps me. And so hopefully that is a good enough set of examples to help
you in the future when you start using these kind of concepts in your own
material.