Subscribe
Share
Share
Embed
Getting out there, showing what you're currently doing / learning, starting a blog, creating content to help other software engineers, those are all good way to distinguish yourself. You might want to consider speaking at conferences as well. In this episode we're talking with Matt Boyle about the what, why, how of getting your first conference talk accepted.
Links:
Links:
- @GopherCon on Twitter
- Sessionized
- Matt's blog post on what should you build
- Writing a successful GopherCon proposal
- ByteSizeGo Matt's courses and books
As always I'd appreciate if you can talk about the pod, share a link, add a review. If you want to support the efforts the best way is to purchase my courses: Build SaaS apps in Go and Build a Google Analytics in Go.
Creators & Guests
Host
What is go podcast()?
15 minutes news, tips, and tricks on the Go programming language.
Hello there. I'm Dominic Senthien Pierre and you're listening to Go Podcast. Today I'm joined by Matt Boyle and we talk about the steps you may take to get your conference talk accepted. Hey there. This is Dominic.
Dominic:And, yeah. I have a guest this week. Matt, thank you very much for joining me for the second time on this episode.
Matt:Hey Dom, it's great to be here again. How's everything going?
Dominic:Very good. I think my English will be, it will be a challenge today for me for some reason, but let's, let's see. We will see. So we will we'll talk about conferences. So for for those that, don't know Matt, so if, you know, you can you can return a couple of episodes.
Dominic:Well, I I don't have the number. We'll have that on the show notes, but, Matt came, I think it was around 34 or something something like that. So, so you can go back there, but we will we will talk about conferences talk today. This is interesting to me. This is something I've never done actually.
Matt:Yeah. It's it's, I must be honest. It's something that's relatively new to me. I've done lots of, smaller talks and things like that, but, this year seems to be the year I've decided to, like, throw myself into doing a little bit more conference speaking. And maybe we'll get into a little bit of of why that is.
Matt:But, you know, generally, it's, it's a great way to to learn some some new skills, and it's something that I was, I guess, a little bit apprehensive about doing. But I feel much better about now that I've done a couple. So I definitely wanna see if I can encourage some of your listeners to to give it a go too.
Dominic:Absolutely. Yeah. When when do you think that it should be a good moment for someone to say, you know what, I might want to start trying to do a talk. Because it's, let's be honest for for almost everyone. This is this is extremely intimidating and the good moment might never happen.
Dominic:So you might be waiting for a long time and it might be, might be something that you want to jump early, but this is also dangerous. So what, you know, when do you think it's it's the proper way, the proper time to do that?
Matt:I I think, you know, at any point is that is the right time to start thinking about speaking honestly. I think, people get, including myself, get overwhelmed with, I guess, some of how how high quality and some of the technical depth that goes on with some of the other speech talks you might see shared around. But you have to remember that, you know, especially in the Go community, there's a real range, of experience. So, you know, if if even if you're a junior engineer or, like, fairly used to language, you'll you'll have something interesting to say. Like, for example, a talk titled, my transition to go from Java or my 1st year of go or, what I learned from what what I brought to with me to to write and go from my experience with JavaScript.
Matt:I love those talks and everybody's experience is completely different. So, you know, regardless of where you're at with your journey, I think it's it's worth considering, you know, at least at least getting going through the process of preparing talks, practicing them, and maybe giving them at work and and applying to conferences with them because it'll give you a really great opportunity to grow, a skill set in engineering that I think is incredibly important and sometimes undervalued, and that is, like, the soft skills. Being a great engineer isn't just about programming, it's about being able to communicate your ideas effectively to to to different, stakeholders with different skill sets. And I think speaking at conferences is a really great way to to get better at that.
Dominic:Absolutely. This this is this is interesting that that you're saying that because, I mean, it's it's also and and, you know, most of the programmer or engineers might be, you know, we are not extrovert. I am not an extrovert per se for sure. So, I mean, it's it's kind of scary to jump in. Would you would you say that, might be might be a good way to start, inside maybe a local, you know, a local meetup maybe?
Dominic:That that would would that be the first step to, that that you would, I don't know, say that the proper step, you know, compared to just jumping into a 300 people room, might be might be extremely extremely rough at first. Yeah.
Matt:I would say start even smaller than that. I think for for most folks, getting comfortable with speaking is is getting, comfortable speaking in front of, you know, even your colleagues and your friends first. So, you know, if if you do decide that you wanna go down this route and speaking is something that interests you, you know, step 1 is to maybe attend a few conferences and and get familiar with the process and how it works. But before applying to them, if you don't feel comfortable going straight to that, a really great way to get more comfortable is to maybe speak at company meetings. A lot of the companies I work at have some sort of, forum where you can share, work you've done, or perhaps you have, sprint demos at the end of your 2 week sprint, and you could, you know, ask for an opportunity to present, the work that your team had done.
Matt:Something that you anyone can do at any company, if it doesn't exist, is set up some sort of, like, lunch and learn, which is, always really appreciated everywhere I've worked is to say, hey, every last Friday of the month at lunchtime, we're gonna do a lunch and learn where you can sign up ahead of time and talk about something you're excited about, some work you did. And these are effectively almost mini conference talks, right? You say, hey, I solved this problem for us and this is how I did it and here's what I learned. So that's a really great way to get comfortable doing so. And it's doing so in an environment you're comfortable with because hopefully your your colleagues and, and your friends who may be there are are your big advocates.
Matt:So they're gonna give you good feedback and support you no matter how it goes, which, I must say is actually my experience at conferences too. I think it can be over very overwhelming to think, you know, there's 300 people or there's a 1000 people in the audience. But they're actually on your side. And it it takes a few once you've done a couple of conferences, you really do realize that that everyone's there to support you, and no one's there to pick flaws in your in your talk or anything. They they really are there to learn and, you know, if you do trip over your words or, say something that wasn't completely correct because you you panicked and got nervous, folks are generally really supportive and are there to to kinda pick you back up.
Matt:And I think once you've done this a couple of times, you start to realize that. And it feels re it's a really nice feeling to know that you're you're presenting to peers and people who do want you to do well.
Dominic:Yes. What, what are what are those, format that that you're mentioning? So I'm I'm I'm not very aware. I never really work at a big company to have, to have those launch demo and whatnot. So do you do you have, like, a screen, a big screen, and and you're kind of presenting before them, or or it's more like, you know, casual just, just sharing your, your screen and whatnot?
Matt:Yeah. It could be either. So, at Cloudflow, we used to do these things in the office where we would invite everyone in the office to come to, like we have a auditorium area. And that would be a very formal, almost like a conference talk, where there'd be a big screen with a projector, and you would present to whoever was interested to come along. That was really nice.
Matt:That's a really great way to prepare for a conference. If your company's more remote like Cloudflare is now, you could just do it on Google Hangouts or Zoom and exactly that. Just share your screen, maybe walk through a deck, maybe do some some code demos. I think the main thing you wanna be practicing for is how to structure your talk and how to tell a story. I think that's the best advice I can give is whatever you're doing, whether it's a, a sprint demo or whether it's a formal conference talk is, you know, turn into a story.
Matt:What was the problem you were trying to solve? What did the world look like before you did this thing? What did you identify as the issues? Like, how did you fix it? And what did you learn?
Matt:And what the next steps are? If you take that format for pretty much anything, you'll tell a really great story and people will come with you because no matter how technically hard something is, they'll understand the problem you were trying to solve. And even if they don't understand the, the technical, bit in the middle about, you know, exactly what you did because maybe it's a really complicated and hard thing to do, they'll appreciate and empathize with the the problem you were going after, which I think is is half the battle with these things.
Dominic:Yeah. I'll also also, I would I would I would say that, yeah, conference talk and just just being out there. So there there was there there were this, this mindset a long, long time ago. So I remember, around 2,003, 4, 5, whatever, there were this idea of, you know, being, being a better developer or something like that. There there was this phrase that people were were saying all over the place.
Dominic:And back then it was like, you know, start a blog, just trying to share what you are doing, you know, share your your knowledge. You you have you have some some expertise and whatnot. I mean, this this is this is probably also a good first step if you are not doing that because and and this is a strange time that we are in. I I know that blogs might not be as popular as they were before, but they are they are still valuable. And it could it could also be a, you know, a first step if you, you know, if if if you if you want to to just get out there and at some point level up, and reach, the conference, I guess.
Dominic:What what what would you say about that?
Matt:Yeah. I think, I think that's really good advice. And I think, I would still encourage every software engineer to to start a blog, anyway. It's great for a bunch of reasons. But I think, if you think about where we're going and if you believe we're gonna be more remote in the future rather than less remote, which is my belief, then there's kind of 3 things you need to be a great software engineer in a remote first world.
Matt:1 is gonna be a great verbal communicator. 1 is gonna be a great written communicator. And one is gonna be the technical skills. And I think, generally, people, you know, they they know they need to be technically great, and they do lots of great work to ensure that they're getting technically better all the time. But it's very easy to kind of reach a point where your work might be excellent, but you're not doing a great job of communicating what you're working on.
Matt:And I think that's where, if you're if you've got a good track record of blogging and you you do a good job of sharing updates, asynchronously with your company, and also you can, you know, run a meeting and can, get across technical ideas to varying audiences, I think that's when you'll be you'll have a truly great career. And I see this all the time. I see people who are great communicators, can accelerate their career, like, really quickly, I think. So, if you are someone who doesn't feel as confident writing your ideas down or speaking, then, blogging and doing conference and meet up talks is a really great way to improve these skills over time, especially if you get to do it at a session where you're gonna get feedback off people or you can use people you trust. And you're also growing a network.
Matt:Right? I think where we're going, especially at the moment, it's very much a, employer's market. I feel like there's there's quite a there's very few job roles open, and there's lots and lots of people applying for them. So it's it's really hard, I think. I I especially empathize with new graduates who maybe don't have any experience in looking for their 1st role.
Matt:I think it's a really tough time to be entering the workforce. So you need to differentiate yourself. Right? And a really great way to do that is to have, you know, maybe you've got some open source projects on GitHub. But if you have a blog of all these interesting things you've explored too and you can demonstrate that you're, you know, that you're growing your technical skills and you can talk about them.
Matt:And maybe you've done a couple of talks at Meetups or just published them on YouTube. You don't necessarily need to go to a to a conference. You'll start to grow your network, and you might find that doing these things leads to you getting job offers or interviews at least just because your name's out there a little bit. So it can give you a unique, advantage as well in in what is a pretty tough market.
Dominic:Yeah. Totally. I mean, I I remember when when I when I first started my blog, it was it was very, very early. And I think my first article was something like how to send an email with c sharp. And back then, maybe it was like, I don't know, 2,002 or something like that.
Dominic:And I was a junior developer at that time. So, I mean, it does not really matter what you are writing about. There there there is there is people, there is developers out there that are at the same level as you are, and they are probably searching for what you are what you are doing actually. And it's just it's just a matter of sharing. So of course of course, you know, I I was not expecting to to have any senior engineers to to to see my blog.
Dominic:But you know what? I I got comments, and I I I it it really started for me at at that point where I I said to myself, you know, this there there's a value to just share the knowledge and and and and also it it's extremely valuable for you as well as as a software engineer. You know, you just by explaining something, you know, it helps you first of all, it helps you to understand it better. And there's no, you know, you're not forced to to write on extremely hard and complicated topic. There there there has to be content for for everyone, I believe.
Matt:Yeah. Totally. I think if you watch, the conference talk I gave at Singapore, it's not actually technically difficult. It's quite simple goal that I was talking about. But the I guess the more interesting element of it that resonated with people is I was telling a story and solving a problem.
Matt:So to your point, like, you don't need to be if you feel like you're not blogging because you don't think you have anything interesting to say, I promise that you're wrong. I'm really interested here in lots of different varying experiences of problems you might face globally, or maybe things that are only unique to you that you've had to solve problems for. And it might be that you didn't have to write very complicated code, but that doesn't mean it's not interesting. The number one question I get asked in my Twitter DMs is what should I build? Like, I I'm, you know, I've got x amount of years ago.
Matt:Sometimes it's a it's a really large amount. It's like I, you know, I've got 5, 6, 7 years, but I'm I just don't have any ideas for projects. And so when other people share the things that they've done and the things they've worked on, people are really excited about that. It's like, oh, this is this is really cool. I never really thought of solving that specific problem this way.
Matt:And here's a concrete example. So I I recently bought an electric car, and I'm having some problems where the, every time I charge it, the, like, the fuse in my house keeps blowing. So I keep having to, like, reset the fuse to charge it, which is, like, very annoying. So I've called the electric company, and they said that, they can't really do anything about it because, when they've came to measure the voltage, which is what's causing it to trip, it's all in range. However, I bought a, like a smart plug and I can see that it's actually not in range all the time.
Matt:It's in range when they came to measure it by pure chance, but like very early in the morning and at varying points, it actually goes outside of the boundaries of what they're supposed to do, and so, it trips. So I called them again and they said, well, we we need evidence of this. So I bought some smart plugs and I set up a Prometheus instance. And I'm I'm pushing all of the voltage information to a Prometheus instance to to build a graph. And so once I've gathered a few weeks of data, I send it back to them and I said, you know, here's some evidence that it's going outside of range, here's the raw information, here's a pretty graph which shows it.
Matt:And And they've actually accepted that as evidence, so now they're gonna come out and see if they can do something to reduce the voltage. So, I think the code I wrote was about 10 lines, you know, it's just a metric, you know, just some stuff to push it from the smart plug to, Prometheus and just normalize it a little bit and that's going to be enough to kind of solve a problem that I faced. Not particularly a hard problem, it was interesting to do and it was in a slightly new domain for me but, you know, it's just one example of where you can find a local problem to you that could be interesting. And I think if I write about this people might be interested and, you know, maybe one day I'll do a even a conference talk or a small meetup talk on this because I think it it tells a story from beginning to end, which I think, in my opinion, make the the big the best conference talks.
Dominic:That that is that is incredible. This is nice. This is very cool. I just want to take an opportunity to return a little bit to what you have said earlier. And, you know, regarding graduate and junior developer, I'm looking at doing a podcast episode with I would like to have 5 junior developers, and just do some round up question to see, you know, how they all they are doing and, you know, what are their challenges and whatnot.
Dominic:And I'm extremely interested in knowing, you know, were there any hard question for them to say, you know what? Should I go into engineering, or or should I should I find something else? I'm extremely interested into that topic. So I'm just saying that, to if there's any listener that that, you know, if if you have, I don't know, 2 2 or 3 years, in, I want to talk to you, especially if you are just started. I'd like to I'd like to do that.
Dominic:And, and yes, to to return to our topic, if if you are not ready to to do talk, I mean, there's so many things that that that you can do. Although returning to what to build, this problem is is real. I mean, I've I've been programming for for the, you know, half of my life now. And I want to I want I want to jump into into Rust, into Zig. I don't know what to build.
Dominic:This this is a genuine problem to be frank. It's I think when when you are when you are mastering what you are doing for a certain time, you you you are just flying, you know? You can you can build almost anything, but as soon as you either you go down into, into, I would I would say, you know, closer to the kernel, whatever, it's it's getting it's getting harder to to know what to build because now you're you're not really mastering this environment.
Matt:Yeah. I suppose that makes sense. I mean, I must admit that's, you know, it's not my my strong suit. I always tend to stay more at the, I guess, the application layer. I really I really like solving, you know, human problems, if you will, like have very clear customer outcomes.
Matt:For example, you know, the silly example I gave a moment ago was my my electric car. It's it's also very specific and real problem for me, and I think the closer you get to, sort of, system programming and the kernel is the more you're probably thinking about solving very, very difficult, probably enterprise level challenges, right, which I think Rust does a great job for. So I think if you wanna learn specific languages like that, it it could be, you know, it could it could be tough if you wanna focus on, like, specific APIs. But I think where, in my opinion, a lot of people get it a little bit wrong is don't worry about solving like, learning a specific part of a language or a specific library to start with. Just focus on writing lots and lots of code.
Matt:And the best way to do that is work on things you're excited about or have, like, very clear, sort of tangible outcomes to you. So I wrote a blog post about this with some suggestions of what to build, so maybe we can link that in the show notes. But, generally, you know, really small things like, I I built one of the first things I built when I learned Go was I built a Telegram bot that sends me a message every morning letting me know what the weather is today. You know, it's it's really simple, but it's been running now for, like, 7 years. It still sends me a message every morning, which is which is cool.
Matt:And I I do find it useful, you know. So, you know, no one's gonna no one's gonna, win any awards for writing applications like that. But I learned a ton doing it, and it got me excited about the language and saw, you know, how to put basic things together. So, you know, for the first 5 or 10 projects I would really prioritize just doing things like that, just getting yourself familiar with writing things and getting excited about what the language can do for you. And then if you wanna go and pick a specific, like, a specific package, maybe in the Go library, you would say, oh, I wanna work I wanna learn concurrency, so I'm gonna go learn about error groups.
Matt:That makes sense, but I would do that after. You're, like, really familiar and sort of bought into the the languages is my view. Totally.
Dominic:Yeah. Yeah. I I did that as well, in focusing on on a small thing recently. For me for me, it was the HTML templates. I decided to to write myself a small library because I was, you know, I was getting tired to, to wonder every time how did I did that on the last thing.
Dominic:And and I I I did a small a small detour in the last 6 months in Django. And I must admit that I really appreciated the the way that the templates were were just handled. So so that's something. When when when you are as well looking around on other languages and and other other way to to work, you can you can also bring a couple of idea to to Go for example, and just say, you know what? This this this could be improved.
Dominic:And I and I will I will I will take care of that. And this this makes this makes for for a good, you know, GitHub project and and probably something that, you know, might be might be worth talking to, to a conference as well, you know, depending on the size of of the library that you're building.
Matt:Yeah. Totally agree. That's a great idea.
Dominic:Do do you do you have, do you have tips on, you know, you know, how to choose or how to select the first conference that that that that one should, should start to.
Matt:Yeah. So it might be a little bit backwards, but I actually don't think you necessarily need to worry about which conference you're gonna apply for first. And I think even if you haven't identified a conference yet, you should work on putting together a, like, a paper. So when conferences are looking for people to speak, they do this thing called call for papers or CFPs. You'll you'll hear it, like, acronyzed as.
Matt:And when that happens, you basically have to follow a pretty pretty standard ish template on, you know, proposing what your talk might look like. So another one I'll link in the show notes, but, Dave Cheney, in 2017 put together one of the best blog posts I've seen on how to write a successful conference proposal, and I've always used this. I use this template and it's been very successful for me. It's a really really great post, so I'll share that below. None of it's rocket science, it all makes sense, but it's really nice to see it all just sort of outlined in very very clear English on what people who are reviewing papers, which Dave used to do, are looking for.
Matt:So writing a, a proposal, with an idea you have is you can do that anytime. You don't necessarily need to have a a conference to aim for. And then there's a website called Sessionize, which again we'll link to below, which seems to have become very popular for finding papers, like, places to apply for, like conferences that are open and have have call for papers open. And you can set up alerts there too to notify you when conferences that are interesting to you, are open. So for example, I've got an alert set up for, like, distributor systems and for Golang.
Matt:And so I get an email a couple of times a month maybe like, hey, this conference might be interesting to you. So that's a really good way to figure out what's available and what's coming up. Also, following the Gold For Con accounts on Twitter is a good idea. They they publish straight away on Twitter when I'm probably LinkedIn, I imagine too, but I don't spend too much time on there when conferences are available and they're looking for papers. So that would be my my first tip.
Matt:And once you use these platforms, you can submit your CFP in there. So you can type your proposal up, you can put it inside the tool, and then you can actually apply to multiple conferences very easily using a drop down. So, you know, you don't need to come up with a unique talk every time. Because one thing I will say is don't be dejected if your talk gets rejected from one conference. It doesn't mean it's a bad talk.
Matt:It might just not have been a fit for what the organizers were trying to do for that specific conference. And a concrete example of that is my talk that ended up being the keynote talk at GopherCon in Singapore, actually got rejected by 3 other conferences before it was a keynote there. So, you know, one person's rejection is another is another conference keynote. So don't don't be rejected if you don't get accepted straight away. Ask ask your friends and people who you know who have spoken before for feedback, before maybe submit it, if you are unsure.
Matt:I'm always happy to give feedback on people's conference proposals, so reach out to me on Twitter and I'd be more than happy to to, give some feedback on it before you submit it. And then, if you do get rejected, just don't don't be too upset about it and, you know, pick yourself up and see what other conferences it could be a good fit for.
Dominic:That that is such good advices. I mean, this is this is incredible. Those tools seems seems to be great. And, how are you preparing then? Let's say okay.
Dominic:Let's let's say you have find you you know, you found the conference and your talk is accepted. I guess now it's time to to write the talk or or or things like that. You know? What what is your process? How do you how do you do that?
Dominic:And and usually, how much time it takes, for you to, you know, to to be to be exactly prepared before before the talk?
Matt:Yeah. It's it takes a really long time. I I would be lying if I said it didn't. So you need to make sure that you've got a lot of time sort of outlined to, to put together a talk. I think as a general rule, especially if you're doing a technical talk where you need to prepare a demo, I would assume that you need sort of 4 to 5 hours per every minute of conference talk.
Matt:So, you know, if you're gonna spend 25 minutes talking, I I would roughly assume that you're probably gonna spend maybe that maybe that estimate's bad. But if you're gonna do a 25 minute talk, I would expect you could easily spend 2 full work weeks. So, like, you know, 40, 60, 70 hours putting all everything together that you need, practicing, and getting ready for it. At least if you're newer in the journey like I am, you know, people like, Bill Kennedy is a a really famous, person in the in the Go community. I've seen him give incredible talks with very little prep just because he's so used to doing it.
Matt:And, he's, you know, he's got his content down. So in Singapore in GovCon in Singapore, there was a, kind of, a spare slot. And Bill was just, I'll do a talk. And he gave probably the most interesting and energetic talk that I I saw at the conference all day. So, you know, some people, as you know, it's like anything.
Matt:As you practice it, you get better at it. And, you know, people like Bill are great people to watch while you're, you're practicing and learning because he just does a great job of being really high energy and really entertaining. And I think that's that's equally as important as the content of your talk. So not everybody has to be a Bill Kennedy. You don't have to be incredibly energetic.
Matt:It might not be in your personality. But I would recommend certainly watching other people talk like Bill and as well as people like Dave Cheney who has speaking style and even some of the Go team. They've got different speaking styles again and see what fits for you and what maybe aligns better with your personality. Once you've kind of figured out roughly what you want to talk about and maybe you've watched a few speakers and figured out how, you know, your presentation needs to look, my best advice would be to get to presenting as quickly as possible. And what I mean by that is, you know, what my process is to start with some Apple Notes.
Matt:I just make a quick, very quick high level bullet points where roughly a bullet point recommend represents a slide, which is like, this is what I wanna cover on this slide, this is what I wanna talk about. And then what I'll do is I'll transfer them into, I I tend to use, it's called Google Sheet Google I forget what the presentation tool in Google is called, whatever that's called. Slides, I guess. Yeah. And, you know, I make very ugly slides, with the content that I I want, to be covered on that slide, and I'll start practicing speaking.
Matt:And the reason I do this is you'll find as you start practicing, your talk is either way longer than you thought it was gonna be, it's way shorter than you thought it was gonna be, or there's bits that just don't click together as well as you thought and they don't follow. So one mistake I see often people make is they start making slides and they make them beautiful and they spend a ton of time making them really, really pretty. And then they realize their talk doesn't really flow, and they have to cut a bunch out or add a bunch more content. And you spend a lot of time doing what I would consider to be the last thing you want to do before, like, they've kinda got comfortable with the presentation. So my advice would be get to the point where you're practicing regularly, with very, very ugly slides.
Matt:And then once you're really happy and you've given your talk 5, 6, 7, 8 times comfortably, then you can start to, you know, make them pretty if you want to. But, But again, if you look at my slides from the talks I've given, my slides never really make it to being that pretty. Mine are all pretty ugly, honestly. I keep them very simple, because I really want people to focus on what I'm saying rather than, looking at my slides. Yeah.
Dominic:Yeah. To to return to Bill, Bill is a machine. I mean, yes. I wanted to prepare I added a couple of episodes ago and I wanted to share Google Docs with him. And I said, you know, we could brainstorm there.
Dominic:He said, well, you know what? Let's jump on a call directly. And I was like, cool. Yeah. I I hear I hear you on that.
Dominic:Very very good advice. That that is that is interesting. Do you do you have any kind of I I know that that people that that give talks told me that sometimes they they do have, like, a a timer of some sort that that they see themselves on on the slide itself. Do do you have that yourself?
Matt:Yeah. So if you use Google Slides, for your presentation, when you put it in speaker mode, it allows you to see some speaker notes. And as part of those speaker notes, it will have a timer. A lot of conferences will enforce having a timer, and they'll usually enforce the time limit too. Some conferences at the back of the conference will have a light that comes on when you've got like 5 minutes left or someone will hold up a sign to let you know.
Matt:So they'll they'll do their best to prompt you and keep you on track. But generally, if you use Google Slides, in the top right corner, there's a button where you can use speaker view. And most conferences, if you are working from slides, you probably wanna use speaker view because then you can see speaker notes, you can see the deck, and you can
Dominic:see the timer as well. Nice. So when when people are saying things like, oh, you know what? I I wrote this this talk yesterday in the plane. They they are they are they are lying or or they are not really prepared for their talk?
Matt:I think it depends, doesn't it? Because I I feel pretty confident that Bill could write a talk on a plane and it would still be exceptional. I couldn't do that. I think my, you know, my advice is very much catered to beginners. If you're just starting out, like, don't do that.
Matt:You know, give yourself sort of 4 to 6 weeks of runway before you talk, and try and spend a couple of hours on it each day. I'd also recommend not trying to just do it, like, in, you know, 20 hours in one go, Like, spreading it out and, little and often repetition is is how you'll become, comfortable and better, with your content. So try and practice little and often where you can, which kind of goes hand in hand with the advice of getting to the point where you're practicing and rehearsing as fast as possible and not worrying too much about your slides is, is my best advice. Last thing while we're talking about slides as well is, try not to put too much content on them. People can one one bad habit I see sometimes is people will put their content as text on the slide.
Matt:Yeah. So you're gonna talk about 5 things, you put 5 bullet points, and it just says exactly what you're going to say. If you do that, people will read your slide instead of listening to you. So generally keeping your slides as minimalist as possible, maybe reinforcing your point, maybe your point, maybe has image or a code snippet on there makes tons of sense. But try not to just put all of your speaker notes onto the slide.
Matt:The most text heavy slides I tend to use is like the final slide which is like the wrap up or the lessons I want people to take away. Makes sense to have some text on there and you'll probably see people maybe pull out their phones to take pictures of that slide if if you take that approach. But apart from that, you probably don't want to have, like, a whole bunch of text on on on any of your decks.
Dominic:Yeah. It's pretty distracting, to be frank. I I can, can understand that. How, you know, how are you practicing? You you you're you're saying rehearsing and whatnot.
Dominic:I mean, do you do you do it for yourself? Do you record yourself and you're listening to yourself after that before presenting that to a first real human or or you're jumping to, to your colleague maybe and and things like that? How do you how do you start that?
Matt:Yeah. That's a good question. So the first few rehearsals will just be me. So I'll put my speaker I'll put my slides in speaker notes and I'll practice speaking while trying to stick to the time limit. Once I'm comfortable with my talk, it's within the time limit and I'm happy with the content.
Matt:Usually, what I do is I record myself speaking. So, you know, I've been making courses for Bite Size Go. So I use a con I use a tool for that called Screen Studio, which records kind of your face and the deck at the same time. So usually, what I'll do is I'll record myself doing that, and I'll share it with a bunch of people that I trust whose feedback that I want. Get some feedback from them.
Matt:And then as I get closer and closer to the conference, I'll practice, either by doing it at work. So I'll ask folks to join a call and I'll be like, hey, I'm gonna give my conference talk. Can I get some last minute feedback? And I'll also practice at home by just, what I tend to do is I've got a standing desk. So as I get closer and closer to the day, I'll practice, like, standing up and treating the desk like a lectern, which is typically what I'd stand behind if I'm doing, one where I need to do a code demo and I need to, to, you know, be at my computer.
Matt:One, that's another piece of advice I would give and this is advice I've I've learned myself recently. I I I didn't do a good job with this. But I recently went to a conference where the stage was very very big. And the way the AV was set up was that they they kinda wanted speakers to use the stage. So there's quite a lot of people, before me, speakers who were excellent, and they had really high energy, and they they moved around the stage as they spoke.
Matt:But I hadn't really practiced in that environment, so I didn't really feel comfortable doing it on the spot. I didn't wanna walk around the stage. So I, kind of, I was pretty static, and I think it made, I I think the content and the way I delivered the talk was okay, but I think the my energy seemed lacking just because I wasn't prepared to walk around the stage. I didn't wanna try and do it for the first time on the day. So, you know, make sure you're familiar with what the setup might look like.
Matt:You can do this by watching previous years' talks and maybe looking at the venue and seeing what it looks like. And, you know, make sure you're prepared to potentially use the stage if it makes sense with your style and and your talk.
Dominic:Yeah. This this is also going, the other way around because I'm I'm a huge fan of, Joe Armstrong. Joe Armstrong is the the, the co author of Erlang, and I really, really enjoy his, he he have a couple of talks on YouTube. And so, you know, at at at some point, there there's one. He is moving a lot.
Dominic:And there's one that, I I would guess, the the stage, that he is on, He was not supposed to move because at at some point, he he he do have, the the projector, you know, the screen projector on his face and whatnot while he's moving. So I mean, it was funny that you were saying that. But I get it. It's, it's a totally different thing to talk, but the stage presence is also you know, we are not we are not actor. We are software engineers.
Dominic:So I mean, it's, it's tough skills to, to handle at first, I I I believe. I I I would guess. I never really did that.
Matt:I think so. This is an area that I'm consciously trying to improve at because, as I said, last talk I gave, I was very aware. I felt my my stage presence wasn't as as strong as some of the other speakers on the day, and I'd I'd like it to be better. So, Yeah. This is something I'm gonna be be working on.
Matt:And I I guess that's a good thing to call out, you know, is, everyone's at different stages in the the speaker journey. Some people, it will be really hard to give the first one. Some folks will be really comfortable with it, and, you know, don't really have, many changes to make. So it just depends on where you're at, but don't, you know, don't watch people on YouTube who are incredible and think, well, I can't speak because I I wouldn't feel confident doing it how they do it. Okay.
Matt:Everyone's got their own way of delivering talks. And, I think I mentioned it at the start of the episode, but the audience really is on your side. Especially if, you know, if they know it's your first talk and or one of your first, you know, they really will support you and they they want you to be successful, which is really, really nice. It's hard to explain how that feels until you're in the moment, but you really do feel supported by the audience generally at these conferences. And to be honest, if the if anyone in the audience wasn't being supportive, I think you'd find they'd be asked to leave fairly quickly.
Matt:Like, these are very supportive environments with code of conducts, generally. So, you know, don't be afraid to put yourself out there.
Dominic:Sounds good. I mean, I I I would say maybe the the hallway track, conversation after that is also very interesting, I I would imagine.
Matt:The hallway track.
Dominic:The hallway track. Meaning that, you know, after the talk, when when everyone is exiting their room, they you are speaking with with everyone. Is does the people came to you and and talk to you about the talk? Do you have a lot of questions?
Matt:Yeah. Sorry. I've never heard that phrase, hallway track. I like it a lot. It's a it's a nice way to describe it.
Matt:It depends on the talk. I've I've had some incredible moments with, with folks after some of my talks. The talk I gave in in Singapore at GovCon was, like, very personal. It was about, how I use Go to manage my, diabetes. I've got type 1 diabetes, and it means I have to be very careful with monitoring my, like, carb intake and my blood sugar levels and stuff.
Matt:After the talk, someone came running up to me and said, I've never met another type one before. It's so nice to meet someone with the same experience that I've had, and, your tool sounds really helpful. Like, I'm gonna build something like that too. And I think as someone who was nervous to give the talk, to get someone come up to you like that, even if no one else cared about my talk, like, that makes it all worth it for me. So, you know, you never know what impact your talk's gonna have.
Matt:So even if it's just a story of how you started a pro a side project or some contribution you made to an open source project, you might be the person to inspire the next person to do it, which is, you know, one of the best feelings you can have, I think.
Dominic:Yeah. Would would you say that it it could be a good first idea for someone to to talk about a project that that that they have done instead of trying to come up with a talk that I don't know, you know, teach, you know, a more abstract concept, for instance. You know, if it's an open source project that you have built or anything that you have built yourself, you are completely in control of what you are saying. You're not trying to teach anyone. You're just trying to show what you have done.
Dominic:Maybe it's it's easier, potentially?
Matt:I think so. It it really does depend on what the conference is hoping for, but you can always adapt your talk to, like, the the conference. Right? So, for example, say you've built a side project which is very customer centric or it's you know, it's a SaaS or maybe you built an application or something. You there may be conferences that'd be really interested to hear about the more customer side of it and how Go helped you achieve, like, low latency, high performance, how you got to ship quickly.
Matt:Like, that's one interesting angle. But there may be other conferences where, they might be more interested in diving deeper into how those things were achieved. So maybe you talk about how you use tracing to make your application faster, or how you found a trick on how you can reorganize your struct so they use less memory, things like that. I've seen talks on all of these things. So the same sort of concept and idea can be adapted and reused a few different times for depending on the conference and, like, what technical depth they want to go to.
Matt:Usually, when conferences make call for papers, they usually are pretty specific. They'll say, we we value technical depth or we welcome talks from first time speakers and things like that. So, you know, make sure you read the the call for papers and just adapt whatever idea you have, potentially what they're looking for, and you'll be able to to be successful there.
Dominic:Is is there any back and forth when you are sending your your CFP? Are they are they giving you some feedback or or it's accepted or rejected kind of scenario?
Matt:Typically, it's accepted or rejected. But one thing you can always do is is follow-up and ask, and say, hey. I noticed my talk was rejected. Do you mind giving me a little bit more feedback? And I found that most conferences I've been rejected from have given me excellent feedback.
Matt:And, one time, it was incredible depth. They, you know, they really do take this seriously and know that, people put a lot of time into these things. So, you know, that's that's how I can say from experience that sometimes they they say, hey. This talk is actually great, but it's just not right for our conference because I've received that feedback before. And also I've seen converse feedback like, your talk was good, but, we had too many, you know, in a similar sort of, idea or theme.
Matt:So, yeah, we went with someone else this time, but thanks for submitting. So you you won't typically get feedback unless you ask, but feel free to ask. But as I mentioned, there's there's tons of people, probably in your network or definitely on Twitter, who would be more than happy to give you some feedback before you submit. So, you know, don't be afraid to ask.
Dominic:Yeah. Totally. That's interesting. I mean, it's, yeah. It's all about getting out there at the end of the day, and and conference talk seems to be, you know, probably the, you know, the the most difficult part, I would say.
Dominic:So if if we have some some advice for the listener, if you're not out there already, you know, you see often the building public tag on Twitter, for example. I mean, this is an easy one. Post about yourself. Talk about what you're doing. Write a blog.
Dominic:I mean, reach out to me if you want to come up as a guest on this podcast. Whatever you do, there's there's always things to do before jumping to to a conference call, I would say. But definitely, this is something, I want to do for a long time myself. But I mean, there's there's a lot of technicalities that are difficult for me. Just just getting myself to the conference is difficult for me.
Dominic:Taking a plane alone, I cannot really do that as a blind person. This is so there there's a there's a lot of, I mean, mobility challenges for me. But, but, yeah, I would encourage people to, to try to try anything. Do do you have any any closing thoughts, anything that that we haven't covered?
Matt:I think, I would encourage people to take you up on your offer there. I think, you know, if you are interested in maybe getting yourself out there a little bit more, building your personal brand, I think, you know, take take Dom up on his offer and and come on this podcast. I think one really nice thing about podcasts, and you often don't see this, but, unlike a conference talk where it's you've recorded from end to end, like, podcast, there's there's things we can cut out, and, you know, if conversations don't really work, or maybe you don't know the answer to a question, you don't want to talk about it, then you can just flag it to the host and they can crop bits out. So it's a really nice and safe way to get comfortable having maybe a more technical conversation or testing out an idea or testing out putting your your personal brand out there. So, you know, if if speaking or growing your confidence with talking and, is something that you're interested in, like, you should take time up on this because I think people love, podcasts where you've got lots of guests and there's more of a discussion going on.
Matt:And, you know, as I say, if if there's anything that, that doesn't, kind of, pan out, that's maybe the the conversation doesn't go where you want it to go, I've always found Dom to be really, really friendly and welcoming. And, it's a really safe way to kind of practice and get get comfortable with being a public speaker.
Dominic:Thanks. Yeah.
Matt:I'm
Dominic:I'm a I'm a nice person, I think.
Matt:I
Dominic:try I try to be a new ego. You are.
Matt:You
Dominic:are. You you do have reached, a lot of subscriber on on your Twitter, how do you call that? The the the Twitter community. This is this is very, very impressive.
Matt:Yeah. I think, it's it's just been built up over time. I think, generally, I just try and be as kind and helpful as I can to to folks on on Go Twitter, and it pays dividends. Like, I get to speak to lots of really interesting people, and I get to, you know, do things like this. And all of it just started with kinda putting myself out there.
Matt:I think, it was last January I really started trying to, I guess, be more present in the Go community and helping where I can because I'd received lots of help before. And I wanted to to give it back to other people. And the amount of really amazing opportunities and people I've got to meet since then has has been incredible. I really do think the Go community especially is exceptionally friendly for the most part. When I compare that to some of the, like, the JavaScript debates and things I see on Twitter versus the discussions the Go community has on Twitter, it's it's definitely a much friendlier place.
Matt:So, you know, come join us.
Dominic:Yeah. There there's way more people on the JavaScript, though. Maybe maybe that's the thing. Maybe if we if we add, that many developers, maybe it will it would start to be a little bit rough. I don't know.
Dominic:It it's it's interesting to evaluate.
Matt:Yeah. Perhaps. I guess, hopefully, we'll find out one day as the as Go takes off even more than it has now.
Dominic:I don't know. I don't know. I I see a lot of people, I see the interest in going. I'm really, really happy about that. It seems to be steady and and it does not really drop.
Dominic:I would I would even dare say that it's getting more and more popular. This is, this is interesting because when you think about that, this is such a verbose language that I can understand someone that is writing Ruby on Rails, for example, might be I mean, they might see Go as, no thanks. That's not for me. You know, at first, at first, just before that time when you start to realize all the benefits, at least at the beginning, you know, performance and speed of compilation and whatnot. And just the security of having a, you know, static type and whatnot.
Dominic:I mean, this is I I under I can understand that from the exterior point of view, it it might not be the sexiest language out there.
Matt:Yeah. Perhaps. But I think, some of the tooling is incredible, and I think I think success of the language sometimes comes with enterprise adoption. Right? You see some really big companies, starting to use it.
Matt:And, obviously, it's incubated within Google, which gives people a lot of confidence that it's gonna be around and and being sort of, stewarded in the right way, even though there's been some some controversy about, the iterator proposal for the next version. But, generally, people feel pretty good about Google Stewardship, I think. So I think as long as those things will continue, we'll continue to see growth. But I think, I don't know. If I if I was a a betting person, I would be watching, Rust, and I'd be watching Zig.
Matt:I think those those languages are gonna, continue to grow too, I think.
Dominic:Yeah. Personally, I I do have a a small preference for Zig, to be frank, be just because it it's similar a little bit to go in terms of its simplicity. I mean, Rust, I would like to love Rust. Might be strange to say, but each time I'm trying to say, you know what, let's just build something small in Ross and like, oh, this I don't know. There's a lot of things.
Dominic:My mind is I'm hold now. I'm very, I don't know. I don't have the energy that I had before. And to be frank, Rust is hard. It's hard to just start.
Dominic:The the learning curve is deep, to be frank.
Matt:Yeah. I had the same experience. I spent sort of 3 to 6 months just playing around with with Rust and trying to get familiar with it. And, there's some bits I really liked about it. I liked some of the some of the more functional paradigms you can do, which took me back to my old camel days.
Matt:But, generally, I did find it definitely very challenging. It's just a different mindset shift. I found Gold kinda hard to start with, if I'm honest too, coming from Java, just because of the lack of structure for, at least like, project structure, which I know is something people struggle with a lot. And I ended up in a lot of situations where I had the, dependency import cycle error that I really struggled to, to figure out how to fix, but I think you just gotta stick with something for a little bit don't you? When you start to learn the patterns and then it all makes sense.
Matt:So I just don't think I ever reached that point with Rust where it all clicked, But I'm sure if you stick with it, you can you can reach that point. Because I know a lot of people who who absolutely love it.
Dominic:Oh, yeah. Oh, yeah. Definitely. I mean, this is interesting. And, wow.
Dominic:Okay. I'm old. This is this is something we will need to expand at some point. But I I received I received the Marianne Mangtagnino last last week. She she said something about structure because I I I'm I'm always saying I I know that this is this is an issue.
Dominic:I let's face it. Let's be let's be real and frank. People that that try Go are they they have difficulties having a blank directory at first. Nothing, you know, no structure whatsoever. And I'm not understanding that.
Dominic:But she said, you know, she said something very interesting. I mean, this this this can be people can be nervous when when there's nothing at first. And and it made me realize that, you know what? Yeah. This is true.
Dominic:This is true. I I can imagine that when you are trying something new and the only thing that you have is a compiler, and now you you you need to create your first file, and you don't really know how to structure your your thing. This this is interesting, but I mean, at some point, is it not something that the Go tool should should take on itself then? To have some kind of scaffolding inside there. Or it could be, it could be a project.
Dominic:I mean, it could be, there is certainly some project that do that. And yes, for COBRA, for example, you can scaffold a thing like that. But I mean, I don't know. There's something to be, there's something to talk about to think about for structure.
Matt:Yeah. I think, the main problem here comes from the Go community's general desire not to use frameworks. Right? Because if you think about all the other languages where people are used to having very structured ways of writing it, for example, let's look at PHP. You can just make an index dot PHP file and put codes everywhere, but people rarely do that anymore because Laravel has got such huge adoption.
Matt:And Laravel is incredibly opinionated about where how you write your code and it helps you with project structure and you generate most of your stuff. So it's very productive and it solves the problem of I need to think about my package structure because it kind of tells me how to do that. Then there's a bunch of, you know, frameworks like Next. Js as well where it actually routes, like you need to use a certain package structure otherwise you're going to break the routing, it depends on it. For Go we have stuff like Encore.
Matt:Encore is pretty opinionated about how you organize your projects, which is very helpful. So, you know, if you do, if you don't want to worry about those things there are frameworks available to you in Go that can, remove some of this overhead. But generally the advice and guidance and the idiom for Go is, you know, to not depend on frameworks too much, which I think is where some of this head scratching comes from because that kind of breaks the the paradigm that maybe you're used to coming from some other languages.
Dominic:Yeah. Totally. This is how I'm I'm phrasing it in my fur my first book that I wrote, my first course, let's say. How can you how can you make a choice or framework if you if you don't really know, you know, the bare metal. So that's why I really like people to to start with with the standard library.
Dominic:And after that, if you want to use something, then you can at least do a good choice. When I started with Kio, I started because at some point I woke up, I was I was having a a a sass at the at that time, and it was it was on it was Node. Js. At at some point, I I woke up in, one morning and I said, you know, I'm tired. It it was it was mainly callbacks at that time.
Dominic:It is very old. Promises was not really there. But the point is, I took a framework. I don't even recall what it is because it's not, it's not there anymore. But the point is, I I took a framework without really knowing.
Dominic:But if if I if I had knew better, I I would have been way better with just the standard library because, it's difficult at first, but but, yes, in the in the long run, you know, you can you can open a an old project 5, 6 years ago and and it's still build. It might it might still build as well with with with the framework and whatnot. Let's say you are doing let's say you you have to pick route route a router like Chi or echo, for example. It it might it might still work, but I don't know. I I I really enjoy the fact that before choosing something, it's it's easier to to understand what's going on underneath.
Matt:Yeah. And I can give a, an example from my experience here too. Like, I I kinda joined the workforce as React was becoming popular, or at least at the company I was working at React was becoming popular after Angular Angular 1. And so I learned very basic JavaScript at university, and then I actually started writing React pretty much straight away. And I am semi competent in React.
Matt:I wouldn't say I'm good at it, but I can I roughly understand the life cycle and I can I can make apps work? But because of how I learnt to write front ends, I don't I would say I don't really know JavaScript. Like, I definitely don't know JavaScript to the depth that folks who, you know, started out with raw JavaScript and then learned jQuery and then learned the frameworks on top have. And so, you know, if people say to me, do you know JavaScript? I tend to say, no, but I know React.
Matt:And I don't think that's the right way to learn things. If React stops being popular tomorrow, which, you know, according to JavaScript, Twitter might be true. I see lots of other frameworks becoming increasingly popular. I'd I'd have to start from square 1. And I I really I should go back and learn, like, the absolute fundamentals of JavaScript before I learn a new framework.
Matt:And I think if I did start doing more front end work, I I think I would do that. I'd go back to basics, because I've never actually really learned a lot of the the depth that I I really feel like I
Dominic:should do. Yeah. I I started with HTML 3. I saw HTML 4 coming in. So I'm pretty I'm pretty yeah.
Dominic:It's the other way around for me. And and yeah. That that have the the the other other in in in impact for me. So when when I when came the time to choose any any framework, I yeah. I don't I don't know.
Dominic:It's it's the JavaScript is so oh, yeah. That's that's another the discussion. Maybe maybe I will I will, we will we will need to reschedule this discussion because, I mean, I don't think we have time to to enter there. But but, yeah, that that's a good point. That's a very, very good point.
Dominic:So let's wrap up, Matt. So so would you say would you say that if someone is sending a resume and there is some conference talk or any any kind of, you know, blog or open source project on their on their resume. This is already a plus for someone that is hiring a software engineer?
Matt:Yeah. It definitely helps. It shows, you know, passion and interest in, you know, the potentially the language or, the job beyond sort of day to day work. It also potentially gives me something to go and read and watch before we have an interview. Right?
Matt:So I can learn a little bit more about you. I think it definitely it certainly helps. I think as I say in the market at the moment, anything that you can do to be a differentiator, you should you should consider doing. But more importantly than that, if you can find a passion for, you know, your job, like, you'll you'll have a much better time at work than if you, if you feel that it is just a way to earn some money. I think as a software engineer we're I don't know if it's I don't know if it's unique, but, you know, one thing about being a software engineer is you have to be always learning.
Matt:The best software engineers are always learning. That doesn't necessarily mean you need to learn every language, but it does mean that you have to kind of keep your skills fresh, which means investing in in training. And one of the best ways to do that is to go, oh, I just heard about this cool library or tool or thing. Let me, do a short talk about it, or let me write a blog about, you know, what what I'm gonna use it for, and then maybe write a follow-up blog about what I ended up using it for, why I liked it, and what maybe why you should use it too. So I wrote a blog recently on SQLC.
Matt:I wasn't familiar with SQLC, but I heard everyone talking about it right, so I spent a little bit of time, figuring it out, looking at it, and, I was really impressed by it, I thought it was excellent. It kind of flips the ORM model on its head. And so I actually use that now as, like, my primary way to, kind of, interact with the database, in Go. And if I hadn't seen people talking about it and gone and experimented with it, I'd still be, using the slightly immoral fashion ways of just using, like, raw pgx. So, you know, even you know, I've been running Go for 6, 8 years at this point, I think.
Matt:I don't remember exactly. I'm still learning new stuff, like, every week, I would say.
Dominic:Yeah. Same for me. Same for me for SQL C as well. I mean, it's it's crazy because I checked them a long time ago. I think it's episode 5 where I talk about databases.
Dominic:Maybe it's 2 years ago. And and for some reason, it did not really click. I I retested it recently, and I'm I'm just like, wow. Okay. That's it.
Dominic:That's all. That's all. I'm I'm going to do that now. So so, yeah, same same experience as you. So if you if you haven't checked it, I mean, it's worth it's worth because to me, database was always the most verbose in Go.
Dominic:The thing that I did not really like to write, because I did not really like Gorm and all the the ORM approach and things like that. I really like SQL, or SQL, depending on how you want to pronounce it. I I really don't know. But, yeah. Same same same here.
Dominic:It's really it's really a nice a nice piece of library. Cool, Matt. So thank you very much. I mean, if people want to to check check out what you are doing, you you have launched a book recently, on on debugging as well. A follow-up to your course, if I'm not mistaken.
Matt:Yeah. If you wanna wanna see what I where I'm up to, you can find me on Twitter. It's mattjamesboil. And then the book that Dom's referencing is available on bitesize.go.com. Yeah.
Matt:I, this is my second book. This is the first one I've self published. Self publishing is interesting. Maybe that's another discussion for a podcast, like self publishing a tech book. But, I learned a ton along the way, and it's it's been really rewarding.
Matt:And I've been getting some great feedback on it. So check it out if you're looking for your next, next book to read on the on a commute to work, perhaps.
Dominic:Yeah. And join, join the the community as well. We we will have all the show notes, all the links in the show notes. It's it's time to close. I am losing my, my communication skills, by the way.
Dominic:Alright. Thank you very much, Matt. It was it was great.
Matt:No. Thanks, Tom. Bye.
Dominic:Alright. That's it for this week. I would really appreciate if you can talk or share about this podcast. It's it's always helpful. Also, another way to support this show is by purchasing my course.
Dominic:There's always a link in the show notes. So on that, see you next week.