The subtle art of giving code walkthrough talks

Speaker 1: Welcome everybody for this session, and I hope you're enjoying this conference. I know I am. Right? I'm learning a lot with everybody and all the sessions that has been presented so far. So I'm gonna try my best to actually provide something useful here as well.

Speaker 1: So my name is Ricardo Ferreira, and I'm a developer advocate in this company called Elastic. And in this session, I'm gonna try to actually show some tips that I've kind of learned the hard way, about how to give live presentations when your content is about code. Only code. No slides. And, so the the the main reason why I think this is important is because, I I would guess that every developer advocate or developer relations professional would like to create presentations or talks that aren't memorable.

Speaker 1: Right? So I think the whole point of you going to a stage, either if it's in person or virtual, is to create your mark in the community and actually be able to contribute and educate developers about the whatever product, service, or technology we're talking about. Right? So if your whole goal is to create a a memorial talk, I think it is important for you to be prepared to when you don't have those lines to for it. So it it is funny because my whole experience with this whole live code thing happened because I was often kind of being accepted at conferences, which is good.

Speaker 1: But then the day before the actual my talk, I would end up with alright. I have no slides yet. I know I have the code. I I have a demo ready, but I have no slides. So you know what?

Speaker 1: I'm gonna jump straight to the demo and just present that. And by doing so, that's how I kind of create this habit of doing the live code walkthrough. And another thing that I've kind of learned throughout this pandemic is that if you start doing live coding using code as your whole content actually, I think that's can be a really positive outcome because one of the things that I've noticed is that people are getting tired of 100% full slides. Right? So with that said, I am not saying that, doing slides is wrong.

Speaker 1: Right? Everybody has their own style. What what I'm saying is that if you try to mix and match a little bit of code, a little bit of line, or maybe only code, the chances that people are going to enjoy it are gonna be greater, especially during the pandemic when everything is virtual. Right? It might be different if you were presenting in person.

Speaker 1: Right? So so with that said, the content that I'm going to share here today is going to be based on. I'm gonna share some tips about behavioral, that you should, pay attention when you are presenting a code walk through. We're gonna also obviously, right, walk you through in the stakes or perhaps some sharing some tips that you could use to make your talk memorable. Right?

Speaker 1: And lastly, right, how can you actually, when you present, right, if you you're a teacher or a presenter, it is all about keeping the attention span throughout the end of your presentation. Right? So there are studies that shows that, alright, the the attention span are gonna varies and sometimes it's gonna drop. This is normal. Right?

Speaker 1: Nobody actually gonna pay a 100% attention to your talk. But how can you act at least keep it that on average and never keep drop it all the time? So I'm gonna share tips about this. Again, considering that you are using code as your main content. Right?

Speaker 1: So the first thing I would like to share with you is that make the effort to make the presentation not about you, but about the audience. Right? I've seen and I am viewed as charged as well. Right? I'm seeing some presenters, including myself, that in the past would make would use the situation about presenting as a way to show that how smart they are or how smart I was.

Speaker 1: Right? This is a mistake. Right? So what you have to do, use your personality. Try to be as much human being as possible and make sure that the people are gonna like of your personality.

Speaker 1: Not because you are good in what you're doing, but because you were truthfully trying to teach something the best way possible. So that's one of the tips that I can share that are are gonna help you to create your talks more memorable. Right? Another thing, try to enjoy what you're doing. So one of these things that, again, I've done this mistake as well.

Speaker 1: So and I've seen other people actually doing it is not expressing some positive emotions while we are doing the walkthrough and the code. Like like, it is especially when you're virtual, it is very tempting to you to keep looking to the screen and, like, treat the audience as just someone that watching your screen and you're you're hearing your voice and you don't necessarily are actually talking to them directly. So my advice is to try to express some emotion. Right? Remember, it's all about being memorable.

Speaker 1: So, for example, even if you are writing a code for the first time that is supposed to maybe invert a three and it works, celebrate that like make sure that the people see you as enthusiasm. So that's how you are going to keep the attention span to the end. Right? So or at least try to do this. Right?

Speaker 1: Make pauses. It is very important. It is very important to do pauses on any presentation, I would say. Right? But when you were doing some code walk through, what I do is, for example, if my talk is supposed to be, like, twenty five minutes, right, I am going to create at least three milestones of pauses that I will manage.

Speaker 1: Right? So maybe after the first five minutes, I have explained the basics of what I'm trying to say and then I'm gonna literally pause, ask people if they have questions and give the time to them to digest the code because, again, they're using code. Right? Slides are easy to digest, but code sometimes is not so easy. So and maybe people are trying to make questions.

Speaker 1: Right? So, yeah, sometimes you have the q and a always in the end, but this is this alone is another tip that I can give it to you. Try to avoid this whole, oh, yeah, and A on the end and let me do my thing. Make make the make the presentation work conversational and interactive. Right?

Speaker 1: I think that's gonna make the attention more not to drop. Right? And very importantly, always create your code that you are going to present and make sure that in the beginning, not in the middle or the end, in the beginning of the presentation you say, hey. We're gonna be working with this this repository that is publicly available. Here's the GitHub link or whatever other repository you were using.

Speaker 1: Right? Because instinctively, people will not makes make it that effort to try to remember everything that you were talking or coding or showing because they know, okay. If I miss a thing or two, I can go back to the repositor and, remind that there. So that that will make them relax right off the bat and keep your eye focused on what you actually want to try to express. So but, again, create a reposer.

Speaker 1: This is not something that, yeah, it would be nice, but it's kind of a mandatory. Right? Build your codes as a narrative. So, for example, you as its presenter or as a developer advocate, you always break down your content into a narrative, into a cohesive narrative. Right?

Speaker 1: This is you're you're gonna do this instinctively. Right? Because you wanna make sure that people are going to digest everything that you were saying. But this also applies when you were using code. Right?

Speaker 1: So what I do usually is, let's say I am like a I I actually did this presentation a couple of months ago about how to people that write go, go developers can use elastic search for their applications. Right? So what I've did, I've created this like a representation of the whole code and broke down into different files and modules and packages. Right? So and then as I progress it through the presentation, I walk you through each one of them individually.

Speaker 1: This is good for two reasons. First, because mentally, it it will make more sense. Right? It's easy to digest instead of one whole main code that has everything there and you're just walking through top to top to the bottom. And secondly, because there's a there's a question of time.

Speaker 1: Right? You have to manage your time. So, for example, sometimes I've been given about fifteen minutes of my whole presentation and things happen. Right? For example, we might be running behind schedule for the whole conference or livestream or talk that you were supposed to present.

Speaker 1: And maybe instead of actually using the fifteen minutes, you have to rely on twelve or ten. Right? So if you break down your logic, your content in different modules, you're going to be able to at least finish them individually and never leave the presentation with something incomplete. I think that's important. Right?

Speaker 1: Another important thing is and this is something that I've started using very recently and I saw that it worked. So that's why I I I turned into a tip. Try to create two branches. Right? The main branch, of course.

Speaker 1: Right? That that's where the main branch is gonna contain all your code that people are going to clone and start using it, and they're gonna pass their work, pass it on the the main code. But one of the things that I like to do is to create what I call a demo branch or a livestream branch. And I'm actually I brought you here an example of this branch. I'm gonna actually open real quick here.

Speaker 1: So, for example, this is a project that I've made available with my GitHub repository. And this is as you can see here, this is the main branch. Right? So this is where I suppose the whole code is complete. So what I do, I create this, branch, which I call livestream that has nothing.

Speaker 1: Right? So and during my code walk through, I always start with this branch and then I kind of have a second monitor or maybe some iPad if you were doing a live, right, with the actual brand that contains the code. And instead of trying to remember from the top of your head what you have to write the code, you simply copy. Just like that. Remember, you you don't have to prove that how good you were technically.

Speaker 1: What you have to actually teach, what your code is trying to do. Right? So there's no problem of, alright, I'm gonna progressively try to copy and pass all the code from the main branch to this incomplete branch. Right? So the experience of digesting what the code does is gonna be better.

Speaker 1: Right? So this is one of the things that you should start doing it. Always create brands and more importantly, people can actually run a gif diff to see, the differences between the incomplete brand with the complete brand. So that's a bonus. Right?

Speaker 1: And mistakes are fine. I mean, I cannot exhaust this, like, enough to say that there is okay if you maybe you were trying to run something and okay. You were supposed to happen something and didn't happen, or maybe you were starting up a service here and dragging itself, waiting for something else, and you have no idea about what's going on. It is okay to actually make these live mistakes. And I I I actually have the habit of intentionally create some mistakes, right, to make things more like a we are all human beings.

Speaker 1: Right? To be really honest with you, I am as a as a developer, when I see a presentation, when everything runs perfectly or smoothly, I start to think, okay. This dude is trying to trick me because in real life, there's not everything is perfect when it when it comes to code. So embrace the failures. Right?

Speaker 1: Also, this is very important. Right? Try to ease up in the whole programming language details. For example, I was once presenting this meetup that I was presenting about Go, and then I had this piece of code and actually put a screenshot here that basically reads a file. That's it it is simple like this.

Speaker 1: Right? But I've noticed that after meetup, people came after me and say, Ricardo, I didn't know about I didn't understood completely about how the code was supposed to read that file. And then when I started looking to the actual code, I remember that, okay, I I'm trying to create so so many complication about concurrency and making sure that, I was using the go routines from go to make sure that everything was gonna run parallel. So the TLDR is that there are some constructs from the programming language that not everybody will kind of understand right off the bat. This is even more important if you are a person just like me, for example, I have to interact with different communities.

Speaker 1: Right? Although I I I am a Go and a Java developer, but sometimes it have to present for some Python communities or maybe c plus plus community. I'm not gonna expect them to understand every single building block from my programming language just because, like, I I don't have to do the struggle to present to them. So make sure you don't overuse your programming language, features. And the same goes to IDEs.

Speaker 1: Like, I have I am I'm extremely open minded regarding IDEs. I'm not a huge defense on earth one or two or three. But keep in mind that when you are presenting, remember, your job is to make sure that people understand the code. And if you present your code in a such a way that depends of a given understanding about how a IDE works, whatever the IDE is, I think that people will get more confused and then actually simulate your your content. And just start and sometimes, if they don't like the ID that you are trying to use, sometimes it's gonna even create the opposite effect, which is they're gonna start leaving your presentation because this guy is trying to push me this ID that I don't like it.

Speaker 1: So try to ease up in the IDs as well. Right? As many as much as possible, try to use VI, for example, which is everybody everybody likes it. I take that back. Nobody likes the VI.

Speaker 1: So, I mean, some some do, but I don't. That's okay. And keep the tech list to the minimum. Right? This is something that I've seen a lot of people doing it.

Speaker 1: I did in the past as well. This is a classic mistake about trying to bring as many technologies because all the architectures these days are distributed. Right? So I've in the past, I've did some presentations like, alright. Yeah.

Speaker 1: I'm I'm gonna use here serverless, docker, kubernetes on top of terraform and everything is gonna be applied using Ansible and I'm gonna mix and match different programming language. Try to make it simple. Right? It's just the the analogy like when you go to this, Shirazkari experience, which is steakhouse from Brazil. And then if you don't know the concept of a Shirazko, you're gonna end up there and, hey, man, I just came here to have a dinner.

Speaker 1: I don't understand why you were showing me all this type of meats and like, a type of food. So, you know, make sure that your understanding is digestible. So be coherent with the number of technology that you are trying to showcase. If you wanna if you are trying to showcase more than you should, maybe break it down in different meetups and explain the normal obvious details. Like, I've seen some presentation that that people would start to saying, yeah.

Speaker 1: Just grab this manifest here and then, apply your Kubernetes cluster and everything will be deployed automatically. So sometimes the manifest is doing more than actually it should. So try to expend some time explaining the plumbing behind that huge manifest that does a lot of moving parts. Right? And then finally, just to wrap up, always end your presentations to not trying to do some call to action.

Speaker 1: Right? I'm not saying that this is wrong. Right? If you do, that's okay. But one thing that I've learned in my years with developer relations that developers cannot be fooled.

Speaker 1: Right? So they're gonna notice if by the end of the presentation you are calling you're asking them to subscribe to your servers or maybe to buy a subscription and make all about education and awareness. If you liked your job and if you did your job right and that that's a big if. Right? They're going proactively come back to you and say, hey, Ricardo.

Speaker 1: Could you help me to actually subscribe to your social because I like what I have seen from you. So with that said, I would like to thank for your participation. I hope you joined.