Didn't think that'd work with Sam Levy
This is episode 13 of the ripples podcast, and, unluckily, you've got me, Samuel Levy.
Greg:Hey, Sam. How's it going, mate?
Sam:Hello. Not too bad.
Michael:You know, I I have known you, Samuel, for a number of years, and I've only ever known you in all of your, like, online communications to show yourself as Samuel Levy. So I'm not inclined to abbreviate that. But do you mind if we call you Sam?
Sam:I actually prefer Sam.
Michael:Okay.
Sam:I don't know why I became Samuel in online stuff. I think it's just people kept referring me to me instead, but I actually prefer Sam.
Michael:Okay. So I can call you Sam. That's fine. After all these years that we've known each other, probably, what, since oh, no. It has been a long time, like, before even the first Laracon, you were kicking around
Sam:in I think
Michael:in Probably
Sam:2017 or 18 when I joined the PHP Australia Slack and started really annoying people.
Michael:Yep. Sounds about right.
Sam:Yep.
Michael:7 years, 6 years, something along that along those lines. So, Samuel, we've got you on here to talk a little bit about your journey. You have you've spoken at Laracon a few times, Laracon AU a few times rather. You've been in the PHP Australia Slack community, I suppose, for a long time. Yep.
Michael:You you work for yourself, which you've been doing for an even longer period of time. So I suppose why don't why don't you start with telling us a little bit about yourself and and what you do before we get into some of the horrors that you always find yourself getting involved in?
Sam:I like to call myself a code bunker because that seems less pretentious than a software engineer or webmaster, while also still seeming a bit weird and pretentious. I mostly do PHP, but I've got a background in hosting and Python and bit of this, bit of that. I just kinda do whatever comes my way. I've been freelancing I started freelancing about 13 years ago, and then that moved into running my own little consultancy, which I've been doing ever since.
Michael:And your your consultancy is primarily rooted in PHP, but you pick up, like, basically whatever's going to sustain yourself?
Sam:Yeah. So my preference is PHP and Laravel, just because I don't hate myself that much. But there's always, you know, a bit of WordPress knocking around and then every now and then someone comes to me and they've run out of options elsewhere. So I kind of end up taking on all sorts of things like, yeah, Python, Kotlin, Go, Rust occasionally. But very I've had 1 person come to me with Rust, and, yeah, I didn't last very long on that before I went, yeah.
Sam:You you probably wanna be paying someone who knows the language more than I do. But, yeah, it it's a kind of I I take what I get. So long as the clients are paying and understand that I may be learning as I go, that's not a big deal.
Michael:Nice.
Sam:So I I think I first,
Greg:met you at 1 of the early for his Laravel meetups. Yeah. And, I because I I haven't been very
Sam:active in the in the,
Greg:AusPHP, Spark channels. So, at the time, didn't know too many people. And I got a, a ticket on our on our GitHub where we take talk submissions for running Laravel inside of WordPress. Laravel.
Sam:Yes. So, yeah, I I,
Greg:part of me was like, this is crazy, and I don't want any part of it. But I think I think we ended up putting you on the billing, out of some morbid fascination with how you would go about getting something without working. So and having now known you for a number of years, I've come to realize that that isn't even probably the craziest thing, that you put together. I'm always interested to know what it is that motivates you to try and mix these things up and whether or not they they do in fact have any, legitimate commercial usefulness or whether it's just purely intellectual exercise, like the mountain is there to be climbed kind of thing?
Sam:Now for the most part, especially when it comes to splicing WordPress and Laravel, things like that, there's a underlying feeling of it's all PHP. So there's a certain amount of me that I've worked with so many happy systems, so many legacy systems, so many homegrown frameworks that I've got a pretty good understanding of how all of the things fit together, and I'm always up for a good code dive to dig in and see how something actually works, which always leads me to going, it doesn't have to work this way. Most of the things I would love to say have no commercial use. However, almost every single dumb experiment that I've done, I have then told people about it and someone somewhere has gone, oh, yeah. We figured we're we've been doing that for our production system.
Sam:How did you sort this out? And it just makes me go, oh, 0, that's right. All code's terrible.
Michael:As much as we can look at, you know, we we often put out the best versions of ourselves into the world. You know, not not just in code, but people often only see the successes. It's not all the work that goes up to it, which we've spoken about on this podcast, you know, the the overnight success that took 10 years to build. And so, you know, a lot of the stuff that we see in the Laravel community is actually the best of what we have. You know, we polish things, and we put the the best versions of our card out there that, you know, we review and make sure it all works and it looks great and and whatever else.
Michael:But the reality of our roles as as developers, as engineers, whatever you wanna call ourselves, is, you know, that there is a lot of dank and disgusting code out there in the world that is is running, you know, real real businesses.
Sam:Yep. That's
Greg:Yeah. It's also make you wonder, like, when you look at your your your phone or, or or or a major website, how many of these things where you can't see the source code? Are they just held together with hopes and prayers and strung up on layers and layers of legacy nonsense?
Sam:Yeah. Yeah. There's a lot of that.
Greg:And Yeah. I suspect it's
Sam:I suspect it's more than through all the Through my career, I have encountered quite a bit of those bits and pieces where I I go, oh, I thought this was a good company that heads stuff together, and this is how it runs. And then you question it, and everyone's like, no. No. No. This works.
Sam:Don't touch it. It's it's all. All Yeah.
Greg:It's not it's not wrong it's not wrong if it works and it's making money.
Sam:Well, yeah, that that's the thing. It's 1 of my biggest issues when I was way back in agency land is I kept trying to build perfect systems. I was very much a perfectionist and I would over engineer things. And 1 of the biggest lessons I had to learn from my agency boss is that business doesn't care if it's perfect. The business cares if it's making money.
Sam:So there's a certain amount of pragmatism which is can be hard to pull in. But then again, also being agency, we had to maintain things that we but that we've forgotten about that it that a lot of projects that you would do, and then 6 months later, there'd be a change or an update or something like that. So you had to be able to quickly come back in, jump in, figure out what the heck's going on, and maintain it. So it led to a very kind of structured or structured way of building things, which was easily maintainable, but easy to drop and forget and then learn again. I avoided frameworks for a very long time because every single 1 that I could see was adding well, at least PHP frameworks.
Sam:Every single 1 was adding complexity around the things that PHP already did quicker and faster, but they weren't adding any actual reliability features, and Laravel was the first framework that I encountered that actually made me look at PHP frameworks and go, oh, okay. I could actually use this. It is actually providing value. Before that, it was like code igniter and cake and things like that that were yeah. Yeah.
Sam:I mean, you
Greg:you trade off I mean, there are definite trade offs in, you know, in picking a a framework.
Sam:We have a bit
Greg:a a really simple case, of that in in Laravel is is, you know, array functions versus collections. Array functions are objectively faster. They they perform they objectively perform better. Whether or not that matters, is is a question for the problem that you're trying to solve. But the there has to be enough sort of utility and ergonomics and developer experience in going the other way to offset, the the performance reduction that you get from, from moving that way.
Greg:And Yeah. I think in 9 out of 10 cases, whenever Laravel touches something, they kinda get that. They they kind of give you a lot more leverage as a developer to be able to produce solutions faster Yeah. Rather than just putting AAA bit of syntactic sugar around something that that doesn't necessarily need to be there.
Sam:Well, just yesterday, I ran into that. I had a an array that I needed to go through and just do an array map on. And I went because it was just an array, I reached for the PHP standard array map and then went to ask the key and realized the standard PHP array map doesn't give you the key. It's the second parameter. So I had to switch to the right the array helper to map through, and that would give me the key and the value.
Sam:Just little bits and pieces of, yes, the standard PHP ones are going going to be faster. It's going to use less memory, but sometimes it there's a tiny little bit sort of usability niceness around them. But
Greg:It's the accumulation it's the accumulation of those tiny little improvements in developer experience that ultimately add up to I can I'd imagine this is critically important for for someone in in in the sort of agency consulting space is that every little increment of efficiency that you can gain is less work you have to do for your billable hours. And in theory charge the same amount of money, but work fewer hours deliver a better result, deliver a more maintainable result, faster for the client than you otherwise would.
Sam:Yeah. It it can produce more value. And the the really important part is I can build these things and trust that when I come back to it, I can understand what is happening. Mhmm. I know I know you and I have had discussions about code comments before, Greg.
Sam:I know your company has an opinion about them. Mhmm. But I I still think, like, code comments are very useful. There's been a lot of discussion about does AI get rid of the need for commenting your code, and I don't think it does. It it gets rid of the need to write bad code comments because bad code comments just explain the thing that it's doing, and I totally agree with you.
Sam:If you need to comment what this thing is doing, then you haven't written it clear enough to understand what it's doing without the comment. A comment should exist for why or to expose things which are not explicitly clear from the off. Or or it it comments should be there for intention. The the the intended use of this thing as opposed to the exact concrete, this is what it does. Yeah.
Sam:I mean,
Greg:if you if you got a very if you got a variable dollar a and then a comment next to it saying currency, just make the the variable dollar currency and be and yeah. Just just for just for clarity's sake, we don't actually have there there is a bit of a mean that my company has a firm policy against, comments and that you'll be fired if you use them. That isn't in fact the case. We do III
Sam:don't we do suggest apology.
Greg:We we do suggest that that that in most cases, a a comment is should be seen as an apology for not writing something clear. And there are definitely cases where you simply can't write it clear. You can't extract a method. You can't give something a name, limitations of the framework, limitations of the language, limitations of the business problems that you're trying to solve. And in those cases, we will dutifully make our apology in code for doing that.
Greg:But the the opposite of that is that I I have found and my experience has been that when people comment on code, when when you don't have that kind of forcing function that people will forego writing things clearly because they can just write a paragraph of prose that explains the thing that they're trying to do. So it's really just a way of trying to, you know, force people to say, could could you write this in a way that you could delete, that you could remove the comment that you've added? I mean, informational comments like like doc blocks and, you know, explanations as to how how something might interact with something else, examples of how to implement, you know, if you if you're writing library code, putting an example inside of, a comment on how you would implement it is they're all valid very valid uses of that.
Sam:Yeah. There there's a few there's a few factors there. 1 is if you're documenting the the you're documenting the behavior of a function or something like that, 1, people will trust that whatever you've documented is correct and then get frustrated when it's not actually correct. And 2, people well, like, the the functionality of something will change. It just it definitely will change.
Sam:So there's very little code that I've seen which gets written and then 15 years later actually, I would love to send a very little credit. See, that hasn't been just 15 years and is still running. There there's a lot of it out there, but it should have been redone. But, yeah, the the functionality of things or the behavior of things will change. And if you're writing a code comment which describes the behavior of the thing and people never update that, then it's gonna be bad documentation.
Greg:Yeah. They have to document. They have to write the same thing twice, and the chances that they will do that is is relatively low.
Sam:But I find if you write comments that describe the intention, like, the the intention and the reasoning of why this thing is, it actually has a side benefit of it makes people not want to make functions do too many things. If you have a function that says, this multiply yeah. This multiplies the x 8 times, then someone goes, well, we need it multiplied 9 times, and they do that, and they don't update the comment, then you've you've got junk. But if you've got an explanation of this function provides adds the multiplier for x feature, then people aren't gonna go, oh, okay. I'm gonna use this function just because I happen to need a thing multiplied at times and now to code bug that someone else someone changes it because that feature requires a change, and all these other places have used this weird function which was never intended for that.
Sam:So it it helps people to understand, is this safe to use outside, in a different area of the code? And it also helps people to go, hey. Maybe I shouldn't be changing this here because that's adding functionality, which isn't listed as this is the intention of this function.
Michael:Alright. I'm gonna see the conversation away from code comments if we can and and try and get a little bit back on track. Okay.
Sam:No comment.
Michael:We we I just mentioned at the start of the the podcast that you have spoken at what 3 Laracon are you now? All of them? Or or 2 of them? 2 of them.
Sam:I I didn't make it to the first 1. I, unfortunately, didn't know it was on then. But Oh, I
Greg:didn't have his advertising game sorted at that point.
Michael:I don't know. I don't know.
Sam:It's not a lot. Yeah. Well, 1 of the things I figured out at some point, being a solo contractor who doesn't get to go to the big expensive conferences, if if I wanna go to conferences, the best way to go is to talk at them, Then then people will often pay me to pay for me to go there or at least pay with my flights and accommodation, and I get to go go to a conference, which was otherwise a breach for me. Mhmm. So, yeah, I started submitting to conferences.
Sam:Just started with local meetups to begin with, just talking about random bullshit that I encountered. Then WordCamp, which is a larger conference for WordPress, but, still very localized. They're they're run by communities, and they're a $50 ticket, guaranteed no matter where you are in the world. It is $50 for a 2 day conference at WordCamp. And, yeah, just submitted to a bunch of other conferences, included, international PHP conf and lot of other PHP Conferences and other, I think, have spoken at, NDC.
Sam:It it's a great way to go around and meet people, and it has definitely helped me, for 1, grow my business, and for 2, get more comfortable with what the state of the industry is like outside of my little world of contracting.
Greg:Mhmm. Actually, actually fine, found that, last year for myself. Like, this time last year, I didn't have a business. Did Atalk at Barricon. Now now I do.
Greg:It's it's it's remarkable. I mean, it's fairly obvious looking back on it. You're standing up in front of 3, 400 people, and you're, talking about a thing, with a level of expertise, and that's definitely gonna, like, resonate,
Sam:you know, with with a
Greg:group of people that, you know, I I think entrepreneurship or starting your own thing or or doing even some side hustle to, make a little bit of extra, money on the side. It's it's a difficult thing to kind of bootstrap on Twitter or LinkedIn or whatever you're you know, breaking into that, and particularly those of us who are a bit older who didn't grow up in the Instagram generation and don't really understand personal brand as well as some people in the community do. Yeah. I found IIII find that that that that speaking either either at local meetups or or at conferences is is a great way to kind of, see whether or not people are would be interested in paying you for the things that you know, if nothing else.
Sam:Well, even aside from that, I like I'm not sure that I've had any direct work come from Laracon or in particular, but just where we mentioned the PHP Australia Slack before. There's also a Brisbane Dev Slack, and there's a brands leadership Slack that I'm part of. Just those types of communities where I can go and hang out and just talk shit, That's that's helped me I don't know if I would say grow my brand, but be known within those communities as the person who knows about the thing who to do this. So just before Laracon 2019, Tim McDonald had decided to step away from freelancing. And because I've been talking shit with them in PHP Australia, he handed over his clients to me.
Sam:Still working with some of them. From the from the Brisbane dev site, I was known as the person who knows PHP. So when a local Brisbane company needed someone to go and audit or order the code base of a company that ran Laravel, that they were looking at acquiring. My name got thrown up as this is the person who knows about Laravel, who is trustworthy, and who seems to know his stuff. So I went and had a poke around at someone's code base in Adelaide, and then yeah.
Sam:It was it was Michael's company. And when when I went and asked in the DHP Australia, it's like, hey. Does anyone know who anyone who works here? Michael popped up and then went and spoke to his boss, and then I got flack from the from my end going, are you talking about this to people? Yeah.
Sam:But not Yeah.
Michael:Funny how the world works.
Greg:It is kind of it's it's kind of an interesting kind of lifting the little little lid a little bit. Ugh, words today. Lifting the lid a little bit on how that sort of ripple effect tends to work. Right? I mean, it, very much is a case of it.
Greg:Like, you didn't I don't imagine you expected to pick up Tim Mcdonald's book of clients by just talking by by just being the guy inside that channel, but, you know, getting out there and, and doing those things for for for no other reason than you want to, interact with like minded people and find some find some new friends and, grow your knowledge ultimately ends up turning into changing a freelancing business into a full blown consultancy.
Sam:Yeah. Well, that that's the thing. It's the last year and a half I've been contracting, I think, 3 people from HP Australia were being subcontracting work out to them as well, just just because it got to the point where I needed more people to to help on certain projects. But, yeah, it's definitely I'm I'm terrible with social media. I deleted my Facebook in 2011, 2012, which was just about when I started freelancing because I got sick of it.
Sam:My I've had a Twitter for a long time, and then I forgot it existed for about 5 years and only started going back onto it, Laracon 2019 because it seemed like that's where everyone was. LinkedIn is LinkedIn, it's not well suited for people who freelance or run the wrong thing. I just get constant recruiters fan saying, hey, Sam. We can see you haven't worked for a while. Would you like this junior JavaScript position?
Sam:Or or alternatively, hey. I can see you've got a company name. Would you like to hire these 8 people who who are completely unsuited to your type of work?
Greg:You've got job you've got JavaScript in your list of skills. Here's a Java position. Yes.
Sam:III
Greg:think we we call it recruiter book. The sooner the sooner LinkedIn wake up to themselves and just rename it recruiter book, the better. Like Yeah.
Sam:But, yeah, that that's the thing. I don't I don't do well on traditional social media. It's I've got 200 ish followers on Twitter, and it's an effort to post anything there because it feels partly like screaming into the void and partly like I don't I prefer the feedback of, talking crap somewhere where people can't get away from it. I mean no. No.
Sam:So no. It I I prefer the chat style community and, like, the PHP Estrella is a great community. It's 1 of the only group communities I've seen where everyone comes in in the morning and says, oh, good morning. How's it going? And it feels very like local community ish Mhmm.
Sam:Which can be intimidating to people coming in, I'm sure. But then outside of that is I I find finding the area where where you're most comfortable and becoming known there. You don't have to be the expert. You just have to be known as competent. So if all anyone ever saw of me were from me was Sam shoved Lumin into WordPress as a theme, and that's all.
Sam:So I don't think anyone would have been handing me clients out of the gun. Well, that guy's an idiot. Yeah. Or all the other ones, what have I done? There was I was getting I should finish that off.
Sam:WordPress installable as a LiveWire component for Pulse. That that that's what I was working on. I I got halfway there. Yeah. I've done a bunch of little bits and pieces like that and and, obviously, the recursive databases that Michael doesn't like talking about.
Sam:Good. Good.
Michael:Good for the audience. So you submitted to speak at Laricon AU this year on the subject of, like, shoving SQLite, like, entire SQLite databases as binary blobs into my my SQL columns or something like that.
Sam:I was
Michael:like, I Yeah. Probably.
Greg:Yeah. I've put up with enough of your stuff, so far. So there there was a line and you just crossed it.
Sam:The the thing is it it is such a, like, on the face, bizarre, stupid idea, but people have done something similar in the past. And there are, the more I've looked into it, there are potentially actually useful things that can come from it, especially if you have read heavy databases which are not written very often. Being able to store a SQLite database somewhere, whether it's in s 3 or in MySQL, but you can effectively if you're using something like Claribel Vapor, you can pull the database out once when the instance boots and then run that instance running off a local copy of a database, then it has no read latency to the database. It has and you don't have to worry about running a massive database instance either because it's not getting hit very often.
Greg:Yeah. I mean, at the end of the day, it's I mean, it is different because SQLite is a bit of a different animal, but, you know Yeah. MySQL lets you have JSON data structures, which let you do similarly horrific things if you if you really wanna push it.
Sam:I use that I use that pretty frequently in the especially with, Spasys variable data package. The latest version has a great little feature where if you have an abstract base class, then you can type in that in eloquent and then use a whole bunch of other different classes that subclass off that, and it will automatically pick the right 1 and fill in your data. So you can have 3 or 4 so I've been using it with Stripe. For example, I've got 3 or 4 different Stripe products that effectively polymorphic into a single JSON structure. And depending on the name of the class or the the class that I put in there in the first place, it'll automatically pull out the same 1.
Sam:So I can pull models out, and they've all got different data structures connected to them, which were all type safe and properly structured, and I can go I can do the instance of this, and it's not just a blob of JSON data.
Greg:Yeah. Cool.
Michael:Yeah. Laravel gives you that functionality out of the box, you know, to to serialize JSON objects or arrays or whatever else into the database. But being able to then pull them out as structured DTOs as value objects.
Sam:And and not just structured, but polymorphic structures in from a single column is an amazing little feature.
Michael:Yeah. I was actually looking at that right before we jumped on to to record this this episode.
Sam:Unfortunately, the done it manually before that feature existed, and it was a pain.
Greg:Yeah. But there's there's there's other cases there too where that that kind of thing is just immediately obvious when you're looking at things like an address field, and the the the typical way of storing addresses is to have half a dozen fields for address line 1, address line 2, state Yep. City, suburb, postcode. And you can create a very real object that represents an address, and then just store it in a single address, field Yep. And and you'll have to
Sam:have an sorry. Yeah. If you have an abstract address class, which says these methods must exist, for pulling data out of it, then you can subclass that and have a stripe address, which looks different to a 0 address, which looks different to all of these different addresses. Store them all in the same field, and they'll get pulled out as a DTO, which gives you consistent access to the things, and it just pulls out the right shape. Mhmm.
Sam:So Very cool. Yeah. It it it's really we'll be able to do that. But yeah.
Greg:So recursive database is not as crazy as we first thought.
Sam:Yeah. Well Not a bad step. The the next step, which was the next step, which was, using queues to provide a file system for MySQL's data directory that was stored in Postgres, so it was SQLite inside MySQL inside Postgres. That For
Greg:those not for those not watching this on YouTube, Michael's now got his his head in his hands, and he's shaking his head.
Sam:Well, then I also found a few refuse wrapper for SQLite, so I could possibly get the whole thing ground back to SQLite if I wanted.
Greg:So well, SQLite's got, binary tables. You could put SQLite inside of SQLite, and just it's just SQLite all the way
Sam:down. Yeah. Yeah. So, yeah, I could do it as binaries or I could do it as the fuse file system thing where it's storing it it's storing a file system or presenting a file system to use a space which is actually stored on a table. So so
Michael:You are the, the the manifestation of that doctor Ian Malcolm meme, scientists were so preoccupied with whether or not they could, they didn't stop to think whether or not they should.
Sam:Yeah. The the difference there is I know I shouldn't be doing this. I know I shouldn't be, and I'm never gonna be doing it in production. But I've learned a lot by doing it. Well, okay.
Sam:The that's what Yes. Scroll log in in MySQL, maybe. But I'm more likely to store it in s 3 or some other kind of persistent object store just because MySQL doesn't do great with storing binary data. Mhmm. And I don't tend to need to query that data.
Sam:I just need to know where it is. Yeah. Cool. But to a certain extent, I mean, like, the the way MySQL stores JSON objects because I've looked into it, there's a certain size that that the document can be under where it stores in the table, and then it splits it out. So it's doing a separate file system where you pull that JSON document out.
Sam:So already MySQL's internal data structures are doing things that are kind of like that where it's pulling some data out from somewhere and giving you basic access. Way back in agency days, we used ZOIP, which is a incredibly dense Python framework, which it it had a 6 to 9 month learning curve just to understand the basics of it. But 1 of the things that came with was the zerodb, which was an object database. You just threw objects into it, and then you could pull out these fully realized objects at any point. But that was slow, so you indexed it.
Sam:So it was a a lot of that influenced a lot of my understanding of the best way to deal with these types of complex infrastructures and index them and still make them searchable even though you're not having to invoke the full the full method of the the full data structure. Cool. Yeah.
Greg:So another another thing that, we, I suppose, got relatively you and I got relatively close during the the the lead up to, Laracon, AU last year. So I got some insight into the way that you go about talk prep and, designing.
Sam:Yes. But
Greg:So 1 of the 1 of the things 1 of the really surprising things for me this year was that I had a lot of, potential first time speakers, reach out to me to ask me how I did it as a first time speaker last year. It'd be really cool if we get your insights into breaking into the speaker circuit and and and what that sort of looks like look like for you as a first time speaker back in the day and advice you might give to the prospective speaker who wants to break into the to to the circuit?
Sam:So, obviously, when I first started speaking, I started at local meetups because that's a great way to start speaking in front of a small audience where the stakes are quite low. Also, it gets you knowing your local community. So when I first started meetups, I knew nobody. I've been out of the loop of local community for so long that I kinda showed up, and I didn't recognize a single facet. So speaking, I saw it's a nice little way to break the ice a little bit so people at least knew me and and had something to talk to me about.
Sam:So I spent a lot of time with WordPress meetups. I don't really like doing much in WordPress, but I spent a bit of time there because the meetups were accessible and easy to get to, and, they were always they were monthly, so they were always looking for speakers. Then PHP meetups, then the Laravel meetups when they started up. It's it's been a it's always a good way to, start with local meetups. Conferences were scary to begin with because it's a bigger room of people, and there are definitely different types of conferences.
Sam:Laracon is definitely a standout of a different style conference. It's single track. Michael does an amazing job of caring about the speakers and making sure everyone's happy. And because it's even though it is a Laravel conference, it's not just Laravel. It's, there's access I I gave an accessibility tool, the the last 1.
Sam:It's but it covers a whole bunch of other things, and Michael reaches out to people on from other communities as well. So we had Lauren gave a accessibility talk at the last as well. I knew her quite well from Brisbane, but she's not in the PHP Laravel space. She's currently working for Canva, and before that, she was doing Thoughtworks and a whole bunch of other things. So she's dotnetspace.
Sam:But, Laracon's a great example of how a conference can be done really well to be really good for a for a first time speaker. Other conferences, like, I I wouldn't suggest anyone try to go and speak at something like, NDC as a first point, because it's a 5 day conference. I think 4 tracks over 5 days. It's just so many people, And if you're not part of the group of people who get shits around to every single NBC conference, you're gonna feel like massive fish out of water until you feel comfortable talking about the thing. The other thing I would suggest is if you're nervous, try to get an early speaking swap for a bunch of reasons.
Sam:It's ripping off the Band Aid, but also it gives it until and I'm sure you under understood this entirely, Greg. Until you have given your talk, you cannot focus on any of the other talks that are being that are going on, which kind of means most of your conference, you're sitting there just stressed about the thing you're gonna say. And the more people you see say, you the more you start diving into self doubt. However, everyone's there to see succeed. No one's no one's coming to a conference.
Sam:No 1 is paying 2 to 5 to $600. Some of those larger conferences are 3.3 to 4 grand per ticket to sit there and. They're there to learn. They're there to meet people, and everyone who is seeing someone up on stage, is kind of sitting there going, Well, I should listen to this person that being picked to stand up on stage and tell tell me about stuff. Everyone wants you to succeed.
Sam:So so long as you aren't going there and starting to make really controversial statements like, push everything to production immediately or juniors are effectively disabled or or or any of these types of statements. So as long as that's not your entire talk, and any benefit is, it it gives someone something for people to talk to you about.
Greg:Yeah. Sure. Yeah. 1 1 of the other things that I found that was very, very useful, and and you were sort of party to this, is we identified relatively quickly that for whatever reason last year, Brisbane was massively over indexed on on speakers. And, I think I was the only first timer from Brisbane.
Greg:So because we were all very local, and I'd suggest this to anyone else who anyone who's finding themselves at at Arakon AU this year if you're a first timer. Find all the people who are sort of geographically local to you and then find a space and run your talks and run your talk in front of experienced speakers because there was definitely some insights. You saw a very early cut of of of of my talk, and you affect and you the advice you gave me was basically same content, but swap it around. So the thing you were talking about last, talk about first, which ultimately was the way that that that and and, like, part of the reason that advice, was given is because I'm very used to speaking to business people and trying to convince business people of things and not necessarily used to speaking to, sort of engineers at, individual contributor level, trying to convince them of things. And they're sort of the the the the the pacing of the talk was the wrong way around for what we're trying to do.
Greg:And that's an insight that I would not have gotten had I have just rolled with my my original. I think, you know, the talk was probably 10 times better for it having having having made that switch. So, but there there are always there are always people in the speaker group who are always on the circuit, massively experienced, you know, born on the stage kind of thing. And if you can find them locally, and, you know, find a little office space somewhere, grab a pizza and a couple of beers, and, like, present to, to I was actually probably more nervous presenting that to you and Jess than I was presenting it on the on on the, on the stage in the It's
Sam:a lot more personal. Yeah. Yeah. Yeah. Yeah.
Sam:I mean,
Greg:you also you also you you don't stand there on stage in front of 400 people and you directly ask them to criticize the thing you just spent a month working on. I mean, where's it going? You also don't care because, like, you can't speak to them all. But when you sort of go into a room with with people, you actually, you know, I I want you to tear this apart. I want you to tell me again where it's gonna be wrong.
Greg:That can be, pretty, intimidating. But yeah. That that'd be sort of 1 piece of advice. I think that was originally Stephen Rees Carter's idea, but he ended up getting the spicy flu and couldn't come along.
Sam:Yeah. I don't know. Steven's another great guy who I met originally at WordCamp. He and I had both been presenting at WordCamps for a couple of years running while he was working for Wordfence. And then when he moved into the Laravel space, I was like, oh, hey.
Sam:I know you. So, yeah, he's I've presented with him a few times at work camp, at. He was at the NDC that I spoke at at Melbourne. So it's the the more you do it, the more you'll start seeing some people pop up here and there. Was it Ben I can never remember pronounce his last name.
Sam:Ben de Krij.
Greg:Yeah.
Sam:Yep. He he spoke at the 2019, Laracon, and I've seen him pop up because he was he was doing, temporal. So he was showing up at all these other conferences that I was either attending or speaking at. I'm like, oh, hey. I recognize him.
Sam:Yeah. So
Michael:Yeah. You find that that that there's always a a cohort of speakers that, you know, if you're in a I mean, Laracon's a good 1. You you look at Laracon EU and Alaricon AU and Alaricon US and Alaricon India, you will find that there is going to be some speakers that that end up speaking at multiple of them. And a lot of that from a organization perspective is those are known quantities in terms of, you know, they're gonna put on a good talk, you know, that they're gonna speak well to the audience, and that whatever they're they're talking about resonates with the audience. But it's always important, I think, from my perspective as well to to mix that up a little bit to to have some new voices and new perspectives and things like that.
Michael:And and mixing and matching like that means that the new voices get the opportunity to present their ideas, surrounded by people with experience that can help them along on that journey as well. So it it can it can feel a bit intimidating to come into a group like that of, you know, this person spoken at 3 laricons or they've spoken at 5 laricons in different continents and things like that. But remember that at some point in their speaking career, they were also speaking for the first time entering into a different cohort of experienced speakers. So, and as you say, everyone wants you to succeed, not just in the audience because they've paid, you know, 100 of dollars to come and see you speak, but also the other speakers. There's it's, like, it's kind of in the back of everyone's mind, I think, but everyone is is there to to put on a good event for everyone else, and everyone kind of reflects on everyone else in terms of what is presented.
Michael:So, you know, it's in everyone's best interest to help, you know, keep the the the level, you know, where it needs to be. So and we certainly strive to do that with, AU. And I know that Taylor always picks terrific speakers. I know that the the guys in the Alarcon that you do, and India has done a great job with what they've done in in their 1st 2 years as well. So, hopefully, that that can continue, and we can continue to see, you know, new voices and and new perspectives and new people across all of those different events in in the coming years as well.
Michael:But
Sam:As much as I would love to talk at every single Laracon AU, I am very well aware that there there is space for new speakers, and I'm I'm not a big enough name in the community to be the name that draws the crowd either.
Michael:Well, don't don't say it's so short, though. I think there was, you know, both of your talks, there's there's been a lot of, positive feedback. And, you know, it may not necessarily translate to new business for you, but it certainly, as you say, puts your your name into people's minds when it comes to to that kind of stuff as well. So, you know, some people do it because they want to make a career of speaking. Some people do it because they wanna, you know, travel the world.
Michael:And and the only way really to to get into a position to do any of that stuff is to put yourself out there and and to just do the thing. And Yeah. You know, I know that we will certainly help you out in that process in terms of support in in speaking and, you know, getting there and and, you know, whatever you need really to to just concentrate on on giving that presentation.
Sam:And some people just like to annoy Michael with terrible talk ideas and see which ones have been accepted.
Michael:See what
Sam:sticks. Alright. Or we'll send him bobbleheads.
Michael:Or bobbleheads. Yes. That was a whole story, that 1 was. But he sits on my desk next to my tailor bobblehead every day.
Greg:Nice.
Michael:Excellent. Alright. I'm gonna I'm gonna wrap it there because we've run a bit longer than than we would normally with these episodes. But I think there's some some good nuggets in there, especially if you like comments or not comments in your code. But, Yeah.
Michael:This this has been episode number 13 of the ripples podcast. You can find us on YouTube, on x slash Twitter at ripples f m. You can find me at Michael Dorinda. You can find Greg at Greg Skirman. Sam is at I am Sam Levy.
Sam:But I am Sam Levy.
Michael:I'm Sam Levy. But but as he said, he does not tweet much, but you can we'll put links to the PHP Australia Slack into the show notes as well. You can find us there. But, yeah, thank you so much, Sam, for for coming on and and share the shit with us.
Sam:Right.
Michael:Until next time, I have been Michael.
Sam:I have been Greg. And I've been a pain in their ass. See
Greg:you,
Sam:everyone. Bye.
Creators and Guests
