Reflections on my rhetorics

”ähem“ is my most common filler, I use too much.

Due to my train of thought, I sometimes cut sentences. This happens if my thoughts are faster than my mouth is.

I observe my personal recurring pattern when speaking German: I switch between very formal descriptions in standard German and casual language (with more ähem) in my Carinthian dialect.

Compared to other German speakers, I pronounce stop consonants rather harsh making listening to me unpleasant

IIRC it was one of the first times, I applied my ”lecture content as a sequence of concepts“ approach. In general, I think it worked. But you need to be aware that everything can be considered a concept. You need to define its scope and applicability. Furthermore all concepts must be semantically related. Then this approach can work out.

I talked 6 min about the project, 17 min about IT security including its societal/ethical consequences, 14min about GnuPG on the CLI, 6min about Enigmail.

I regret claiming “und ich glaube insbesondere im Bereich der Emailverschlüsselung ist es schon eigentlich recht benutzerfreundlich”. Usability is a vague, empirical topic and these days I would rather prefer not to judge on usability.

I didn’t include the audience. I could have taken questions in between every section of my talk.

Personally speaking, I can easily see that I was well-prepared and therefore relaxed

”ähem“ is still my most common, annoying filler.

I use a lot of gestures in this talk. It is personal, but somehow awkward.

I ask the audience for their Python experience. So there is at least a little interaction. I spent the last 10 minutes taking questions.

After 4min, I begin with the tutorial. For 9 minutes, I talk about variables and types. For 9 minutes, I talk about unicode, bytearrays and their differences in python2/py3k. I talk 4 minutes about [im]mutability. I continued with collections, string operations and other concepts.

I ridiculously jumped between novice and advanced concepts. Basically I am not well-prepared and explain concepts prematurely, because I don’t remember when they will occur.

I shouldn’t use bitmask and bytearray synonymously. That is just wrong.

list comprehensions introduced before a for-loop? That is awkward and difficult to follow.

I screwed up my unicode explanations. It is somewhere between unavoidable and highly technical. It is difficult to convey. Today, I would address this issue by a short, concise technical description followed by moving on. My fault, back then, was not to plan ahead my explanations and my impromptu approaches were bad.

It is difficult to explain an entire programming language in 45 minutes. I only addressed programmers with experiences.

I remember this talk as the worst of all. I am surprised that it is not so bad, but still: I was badly prepared. I should have invested time better and made some trial runs to estimate my time progress.

ähem, ähem, ähem

I think it is fascinating that I changed some gestures. They originate from some speaker, I know. I imitate this speaker.

Sometimes I showed a slide, smiled and waited for the audience to react. In the meanwhile, I looked away and made fun of my slide’s content. I think this presentation style is acceptable, but today I prefer a more formal approach. I would introduce the slide as funny, make a concise description and move on.

I asked the audience for correctness/errors in regex. There was quite some interactivity.

Again, first I explain that “a regex is a string representing a set of strings“. Later on, a slide shows up containing this exact phrase.

“And who are we going to discuss that?” … damn, fix your English!

I spent 9 minutes with a revision of the basics. I spent 6 minutes with advanced regex operators. I spent 4 minutes with parsing theory. I spent 14 minutes to introduce regex engines and their differences. In

I definitely should have shown practical examples of those advanced regex operators. Maybe even a regex quiz?

On the contrary, I should have removed the parsing theory section. It is simply too theoretical for this audience.

I received feedback that instead of showing practical applications, I introduced awkward impractical scenarios. Except for the previous points, I reject this conclusion. I interacted with the audience on the basics, I talked about some advanced stuff and made collected some practical data. I think the talk design was well-thought through. And necessarily, this talk was well-prepared.

It is the first time, I consciously presented a table of data and waited some time, so the audience can digest its content.

Public feedback:

There is not recording

The talk was properly prepared, but lacked interest by the community

On the other hand, the topic was not fancy either

No public feedback received.

My first lightning talk

I got/pronounced some numbers wrong (while presenting, I cannot read numbers apparently!)

I got stuck while presenting several times

Especially for lightning talks, it should be easy to make complete, thorough trial runs. I didn’t.

Public feedback:

I use vivid gestures, but they show a certain affection/interest towards the topic

Personally, I like my English voice better.

In English, I don’t use fillers so much. Sometimes I use “uhm“. I sometimes stretch “and“ between sentences.

I could have prepared the demonstration of Anki[Droid] better. Considering the circumstances of the organization of this event, I still think I did a great job.

The definition of spaced repetition was out-of-place (too late)

I talked 1 minute about me, 8 minutes about motivation, 7 minutes about neurosciences, 15 minutes about a custom implementation and usecases, 13 minutes about the Anki software stack and 2 minutes about conclusions. I think this is a very good sectioning!

Public feedback: