egghead.io developer chats

What is a Senior Engineer with Tomasz Łakomy

Episode Summary

Joel chats with Tomasz Łakomy about what defines a senior developer, Svelte, learning in public, and speaking at conferences.

Episode Notes

Tomasz highly recommends companies hire interns and train them  because you can get some amazing engineers that you know are going to fit the company's needs. Another great advantage of training interns is that it levels up the senior engineers by giving them mentoring experience!

But, what really is a senior engineer? Basically, a senior engineer isn't a person who programs more, faster, or better. They're a person who makes others better at what they do and a person who can solve problems.

So how do you advance your career? Tomasz says that speaking at conferences had a major impact on his career. He strongly recommends that if somebody wants to start talking at conferences, to start at local meetups because one, you will get experience, and two, they're always looking for speakers.

Transcript

"What is a Senior Engineer with Tomasz Łakomy" Transcript

Tomasz Łakomy

Joel Hooks

Episode Transcription

Joel Hooks:
Hey, Tomasz.

Tomasz Lakomy
Hey, Joel.

Joel Hooks:
How are you doing?

Tomasz Lakomy
Good. Good. Good morning.

Joel Hooks:
Good morning to you as well. I think it's probably evening for you. But I wanted to start out... I really want to talk to you about jQuery. But we're going to get into that in a little bit. First, I kind of wanted to delve into your path. How did you become a software developer? What was your journey to get to where you are today? We can go all the way back to kindergarten if you want. We can start really early.

Tomasz Lakomy
How much time do we have though? Okay. So I'm going to start after I've turned 18, if you don't mind.

Joel Hooks:
Okay, that works.

Tomasz Lakomy
Yeah. So I think I have a quasi traditional path into software development, as in, I do have a master's in engineering. But because I felt like I did not belong in the computer science degree because I was not a programmer when I was 18, and also because somebody who I very much respected at the time who told me, well, programmers are not going to be like a profitable carrier in the future. As you can imagine-

Joel Hooks:
Wow, yeah.

Tomasz Lakomy
... I mean, I kind of listen to them. So I have a master's degree in electronics and communications which is as nerdy as it gets. But we did get programming classes. So I did C++, C# at the university, no JavaScript whatsoever. So at some point, I realized that I kind of enjoy programming. I was not very much... I was not very good at it, to be fair. So I wanted to kind of find an internship around more physical aspects of engineering, so like working with actual equipment and stuff like that. I was not able to find any, but there were plenty of C++ JavaScript internships out there. So I kind of became a developer by accident in a way that I was just pursuing the opportunities that were there starting an internship as a first C++ developer and afterwards as a JS developer.

Tomasz Lakomy
By the way, this JavaScript internship was absolutely amazing because I get to spend a whole month learning JavaScript from scratch, as in, the entire first month for the internship was other engineers training us to become junior frontline engineers. I do highly recommend other companies to do that because you can get some amazing engineers trained by yours truly, that you know that they're going to kind of fit your company needs.

Joel Hooks:
I see a lot of companies that feels like they want senior engineers, right? They want people that are... and I use quotes around "senior engineers", but they want people that are already experienced, that have already fit whatever mold they're trying to find and not as much like hiring people that don't have a resume yet. What do you think? Do you think people should... I mean, you said they should. But what advantages to a company is there to bring in people that are just starting out and actually train them up? What can they expect to see as the result from that?

Tomasz Lakomy
Yeah. So first of all, I'd like to say that, in a way, I do understand some of those companies who are looking for a very senior staff because you need to have some kind of structures of support in the organization, right? So you cannot have like 20 virgin engineers in their company because somebody needs to mentor them, lead them, and try them. But nevertheless, you cannot and you shouldn't build a company out of only senior engineers. You need some first blood. I do highly recommend that companies, well, giving other people a chance, as in, it's much easier to find, I don't know, eager junior developers who, I don't know, have six months of experience or non-experience whatsoever, but they have the passion, they have ambition to learn.

Tomasz Lakomy
Honestly, I think this is amazing. We had an internship program here [inaudible] and we've hired a bunch of folks who are... They don't have much professional experience, but they were a great addition to our team. Honestly, I feel like more companies should push for hiring interns because they will give you benefits, which you honestly should have in your organization.

Joel Hooks:
I think a good internship program would allow that, right? So it's a time box, right? Maybe it's six months, and we can check it out, and we see how the relationship works, and maybe it's a good fit. Maybe it isn't a good fit. But that allows you to kind of hire from that pool. I think one of the dangers, and you touched on this, would be to bring people in with less experience without the support structure to facilitate their growth, right? They just drop them in there, and they're confused and don't have the mentorship they would need. That would be one kind of red flag or something you wouldn't want to do.

Tomasz Lakomy
Yeah. But you also get to grow those senior engineers by doing those internships, as in, you give them the opportunity to mentor somebody else, which is honestly a very useful thing to have in your toolkit as a "senior engineer".

Joel Hooks:
Sure. What does it mean to be a senior developer, senior engineer?

Tomasz Lakomy
Yeah. So I wrote an article a while back because I do interview quite a lot of folks. I'm not a huge fan of labels, by the way, but you have to use something, as in, you have to have something on your contract. So in my company, we have junior, regular, or mid-level engineers and seniors. For me, senior basically is not a person who programs more or programs faster or programs better, whatever that might mean. It's a person who makes others better at what they do and also has a perspective outside of programming. So what I'm trying to say by that is that I think the senior engineers focus on solving problems, not necessarily programming. So they're able to not only translate Jira to JavaScript, but also think about what is the problem that we are trying to solve? Do we want to solve this problem? How do we get away with solving this problem with as little development time as possible?

Tomasz Lakomy
So for instance, one of the examples that I usually give when people ask me this question is a while ago we had this situation where we want to run an A/B test on a group of users, very limited group of users to get their opinion on something. I was like, "Okay. Why don't we just send an email to them?" We get to solve this problem, but we don't have to implement anything, and we get some amazing feedback from this email because, well, you have this medium of communication with other human beings, which is honestly freaking amazing.

Tomasz Lakomy
So I would say it's mostly boils down to making others better, solving problems, not necessarily reacting code, and as we discussed before, mentoring others and helping others succeed because you can be an amazing programmer, but you won't do everything alone. You need others. You need the support. You need to support them, and you need to create those knowledge sharing and support sectors in your team in order for everyone to succeed.

Joel Hooks:
Yeah. I like that, and I like your example of the A/B test because it's a social problem versus an engineering problem, right? Why don't we just ask a question? So spending weeks coding up a solution, and that's experience and also kind of paying attention to the options that are available to you. So do you consider yourself a specialist or a generalist as far as being a software developer?

Tomasz Lakomy
Yeah. So as far as software engineering is concerned, I don't think I'm a specialist, as in, I don't tend to do the same thing over and over again, as in, of course, I do specialize in front, and I'm a JavaScript engineer. I've been doing that for a bunch of years. But I tend to keep my eyes open, as in, I do mostly React, but I'm also taking a look at Svelte recently as well as AWS and other technologies out there. I can't remember who said it first, but there's this idea of being T-shaped, as in, you have those skills that you specialize in, but you also keep an open perspective for other skills that might be useful for you in your career as a software engineer. Because I think you mentioned it in some other podcasts that you used to do Flash for quite some time. Yeah. So at some point, if you are not able to specialize in something else, it might be damaging for your career because then you have to basically reinvent yourself after some time.

Joel Hooks:
Yeah. In that case, I learned that a company can completely close down a platform, and if you've specialized in that platform, you're in a really hard place.

Tomasz Lakomy
Yeah, I can only imagine.

Joel Hooks:
I don't expect AWS, for instance, to shut down anytime soon. We wouldn't expect that. But they can change it, and they can shut down services, like Google, they shut our services all the time, and they don't ask our opinions necessarily, "Hey, how is this going to affect you? Because if it affects you, we're going to shut it down." That isn't something they ask. So there's a danger in being too specialized, I think so.

Tomasz Lakomy
Yeah. I think so. Yeah. I do completely agree, as in, if you get so into a topic that you don't pay attention to others, sometimes you may miss out on things that are also going to solve your problems, but maybe in a better way. But you won't be able to see them because you are sitting there in your corner focusing on your very specific use case and your various specific domain.

Joel Hooks:
It's interesting to me also because it goes back to the advice that you received that had you pursue a master's degree in electrical engineering that said software isn't going to be where it's at. To me, that's like, "Hey, you should specialize in electrical engineering." As it turns out, the jobs weren't there. Right? So you spend all that time and effort, and then you come into the job market, and the reality is, "What do I do now?"

Tomasz Lakomy
Okay. But on the other hand, I've learned, well, of course definitely a lot, but I also learned to learn which is hugely useful, as in, the university classes were extremely diverse. So we had to learn a lot of stuff, very diverse topics, and it helped me afterwards in my career because, well, as a software engineer, you have to be a lifetime learner in order to have a decent career.

Joel Hooks:
Yeah. Electrical engineering is no joke in general in terms of just learning and just the concepts you have to hold in your head. I think that sort of effort and hardcore learning over time just builds that muscle for yourself too. So there's always advantages. It's not wasted time, I wouldn't say, to pursue-

Tomasz Lakomy
No, absolutely not.

Joel Hooks:
So on that kind of line, what is your recommended path? If people want to join in on the software gravy train at this point and a lot of people apparently do, what do you recommend to people when they ask you, "How do I get into this? How do I break into this field?"

Tomasz Lakomy
Yeah. So first off, I would ask them to consider, why do they want to have a career in software engineering? As in, if the answer is money, I don't think there's necessarily something wrong with that. But you have to be interested in software engineering in order to do that. As in, if you cannot imagine yourself in front of a computer for eight or more hours per day, you are probably not going to have a very successful career in the field. But afterwards, if you make this decision that, "Okay, it sounds good to me, I want to work as a software developer," I would say that there's so much resources out there, including a certain website that both of us are familiar with, I mean, ACAD that you can learn on your own.

Tomasz Lakomy
I do actually have a good friend of mine, [inaudible] I'm not sure if he's going to listen to it, but he was an architect. After a bunch of time, he decided that he wants to become a JavaScript developer. He took some online boot camps, like online courses from various websites. After a couple of firms, he was hired as an intern in a Berlin based company. So one, it can be done, and two, I think it's a very good approach to learn on your own pace, not necessarily you have to spend quite a lot of money in order to attend a boot camp because, well, first off, boot camps take a lot of time. Secondly, they are quite expensive, and thirdly, as in, there are so many materials out there that you may not need a structured system of learning, the boot camp provides. You may be just well enough prepared for the job with self-sustained learning at your own peace.

Joel Hooks:
All boot camps aren't created equally. There's a lot of them out there. Some even borderline predatory because it is like a gravy train, and education is part of that, right? People are jumping in softwares of lucrative career. There's a lot of jobs, there's a lot of money involved, and now we have this multi-billion dollar global industry to train people to get to this point. So my advice to people that are looking at boot camps, if that's the route you want to go, and it can be a great route, and there's thousands of people every year that are having success doing that. But you also have to do your research and talk to people that went to the boot camp and make sure that it's a good fit for you. All that sort of thing I think is important.

Tomasz Lakomy
I actually taught classes at one boot camp in Poznan in Poland where I'm based. But firstly, before I decided to teach there, I actually talked to two people who have graduated from the boot camp because I do respect them very much. Both of them are amazing engineers, and I was like, "Okay. Is this actually working?" They told me, "Yeah. This is a decent bootcamp." "Okay. Now, I'm interested." Because otherwise like you said, I wouldn't kind of write my name under some predatory contract.

Joel Hooks:
Yeah. Yeah, for sure. Personally, there's so much free resources out there. I think going into a boot camp and having that sort of dedicated structure is great. But then, I point people at freeCodeCamp a lot because it has some of the qualities of a bootcamp. But as the name implies, it's free. So if you just want to it, is this something I can even stand to doing? Finding a free resource is often a good place to start and to understand if this is actually for me and if I can stand sitting here staring at these characters on the screen all day as a career. Because that's what it is. That presents you with hard problems to solve, and it... Because to me, the fun bit, the part that really intrigued me is the puzzle aspect of this, right? Where you get to solve weird puzzles, whether it's human interaction or actual code or whatever. We're always kind of, "You need to solve these issues." That can be fun if it's for you. So I want to know, what's your deal with jQuery?

Tomasz Lakomy
Okay. So this is my first podcast, and I'm absolutely sure that every single podcast I will ever appear on will have this question. So I should probably-

Joel Hooks:
Yeah. It's your fault.

Tomasz Lakomy
I am totally aware of that. I should probably record this answer and just play it next time. So for the record, I am not in jQuery team. I am not contributing to jQuery, although I would love to at some point. So the whole story is that I was invited to my very first international conference in Italy in 2017. I do remember we were sitting at a speaker's dinner. I was sitting next to Mika Bertolli from Facebook, and I had an extreme case of imposter syndrome at this dinner because I was like, "I do not belong here. Why am I even here?" So we started talking, and the idea came up to mainstream jQuery at every single talk during the conference, which kind of worked and people liked it.

Tomasz Lakomy
There was this reaction that, "What people seem to enjoy it?" I always like to make people laugh, and I sometimes even succeed. So it kind of became a thing. We're mostly on Twitter and at work and some other places I suppose, where I started to make those jokes and started calling myself jQuery evangelists. Somebody calls me a DJ Query, and I actually own a T-shirt with a DJ Query logo on it.

Joel Hooks:
It's excellent.

Tomasz Lakomy
Yeah. I know. I was considering starting selling good and donating the money for charity, but I'm not entirely sure if it's legal. But to be fair, there's also some nostalgia aspect to it. As in, I do remember that during those days, like 2014, for instance, by adding jQuery to your toolkit, you were immensely productive from day one, as in, you [inaudible] and you got the manipulation, animations, Ajax, and all those things. Well, I do strongly believe that the web was much more dynamic back then because animations were much simpler because we've adjusted side up, slide down, and that's it.

Tomasz Lakomy
Nowadays, I would say that animations are fairly difficult to implement on the web and also with things like React. With React is absolutely amazing. It pays my bills. But nevertheless, at React, you have to think about routine, you have to think about state management. I kind of think of those times that I got to install jQuery, and it solved so many of my problems back then. I'm a huge fan of those kind of tools that allow you to become very productive by just adding them. So this is probably why I got kind of involved in Svelte because Svelte is kind of similar to that, as in, you have the single tool. If you want to use animations, you get to import animations from Svelte. If you want to use, well, stores or anything else entirely, you can do that, but you don't have to.

Joel Hooks:
So a tool like Svelte, right? We have this, it's an amazing tool. Do you think there's potential for this to become more mainstream, or is the dominant frameworks from Google and Facebook going to just be the status quo going forward?

Tomasz Lakomy
Before I answer that, I have to mention that at some point, I started to learn Dart from Google. I was strongly convinced that JavaScript will die after a couple of months from now. So my predictions do not work in any way whatsoever. With that being said, I think it has the potential to become mainstream, absolutely. For a bunch of reasons. First off, it is a compiler. So so many things that you will have to optimize on your own are optimized by the compiler. So the first thing,, they are doing an amazing job kind of taking care of performance issues for you. I'm not saying that you don't have to care about performance when using Svelte because obviously, you do. But so many things are obstructed away from you.

Tomasz Lakomy
Another aspect which I think that people are going to enjoy learning Svelte and kind of moving forward is that, with React, you import ReactDOM, and you get all those amazing features, which you may or may not use. You also feel it gets daunting sometimes because you have all those features available by React, and you feel this impression that, "Okay, I should start using all of them." Especially when you look on Twitter because on Twitter, everybody seems to use hooks a week before they released to production. With Svelte, I kind of feel that you get to use whatever you need, as in, you only get to import the things that you need and which is what is more important. Only the things that you're going to actually end up using are going to be shipped to the users. So if you were working on something that needs to be performance optimized, when it comes to bundle size, well, such seems to be an amazing choice. I'm only waiting for the TypeScript support because once TypeScript is supported in Svelte, I feel like it's going to be a major game changer.

Joel Hooks:
So it's impossible to make predictions, and I agree with that. I think there's still a large group of people that are trying to make Dart mainstream. But what is it going to take? What do we need to do? Community-wise, what does the Svelte community need to do to push it forward? Is that something that we even want to do? Does that matter, or should we be pushing that or just kind of like embrace what's popular now and go for that because that's where the jobs are at?

Tomasz Lakomy
Yeah. That's a difficult question, as in, I don't want anybody to have to [inaudible] the app because something else is popular on Twitter or any other social media website because we, web developers tend to do that. We tend to chase trends and not necessarily always focusing on the users. But when it comes to Svelte itself, what I think it kind of needs is more opinionated tools, as in, there are currently some solutions when it comes to routine. But nevertheless, there is nothing like an official "Svelte router" or SvelteX, Svelte that. As in with React, Vue, Angular, you have those pre-established solutions for so many problems out there.

Tomasz Lakomy
Svelte is kind of new. In a way, I'm talking about Svelte [inaudible 00:22:24]. So I think it will take some time before those kinds of problems and solutions to those problems are more well known in the community, as of, if we want to have another mainstream framework, well, I think there's always a room for some healthy competition. But I surely hope that we don't get to... I don't know, have those debates or flame wars whether you should do React... whether you should use React or Svelte or something else entirely. Because there are so many factors to consider apart from, well, whether you enjoyed the framework or not.

Joel Hooks:
Yeah. I think it kind of loses the plot, to me. You have to make a technical decision. There's a business decision when you're going into these things. I think that's why, as React kind of game steam, you see a lot of people as the solutions come, and there's educational materials, and you can post a job listing for a React developer and people understand what that is. But it isn't really necessarily a versus thing. It's like, "What tool is good for this job?" It always, to me, boils down to the jobs, right, the job market and hiring and learning and figuring something out and kind of making safe choices to get where we need to go plays a big part in any of this, which is why something that's funded and distributed in the way React is ends up being kind of a popular and often safe choice for organizations.

Tomasz Lakomy
Yeah. I mean, if you are starting your career in the field and you are trying to learn the framework, React is an absolutely amazing choice because there are so many jobs out there.

Joel Hooks:
That's good too.

Tomasz Lakomy
Like you mentioned.

Joel Hooks:
Right? All of these are good, like Vue, Angular, Svelte, React. All of these are really good tools. So it's like an embarrassment of riches at this point because we have so many great tools and things that we can use. Then they all have their drawbacks too, which is just kind of the state of being a web developer at this point.

Tomasz Lakomy
Yeah. Kind of.

Joel Hooks:
So I want to talk a little bit about... You obviously I think, and correct me if I'm wrong, have a strategy and put yourself out there and kind of develop your community brand, where you're promoting yourself and teaching and putting that stuff out there. I was wondering, "What is that? Do you have a strategy for creating and sharing content on the internet about web development?"

Tomasz Lakomy
Well, I wouldn't call it a strategy, as in, I've never thought of it like a strategy. But what I tend to do, especially when it comes to creating content, I try to learn in the public. As in, most of my ACAD lessons, for example, were recorded about the things that I've learned about recently. Some of those lessons were recorded for me because I tend to watch my own lessons quite often when I want to, I don't know, remember, how do I use this hook in React, for instance. On the other hand, I think it's about helping others succeed. This is why I started writing some more posts because I realized that after a couple of years in the field, I do have some experience. I was working for a bunch of different companies over my career and I've seen quite a lot of things that work, quite a lot of things that don't work. So I started just sharing that with others.

Tomasz Lakomy
For me, if only at least one person finds it useful, well, my job here is done. But when it comes to strategy itself, well, I'm not entirely sure. Like I mentioned in the ACAD chart yesterday, I sure hope the strategies just to be kind and be the person who just make others' lives a bit better by you being kind of in the room, whether it's offline or online. I sure hope this is the strategy. But I'm not entirely sure.

Joel Hooks:
I think that's a good strategy. It really is. You're just trying to be helpful and learn and share what you're learning and kind of your experience versus dictating how people should do things.

Tomasz Lakomy
Yeah. I do strongly agree with this notion. I think you've shared it a bunch of time ago. But so many articles should start with in my opinion or in my experience or this is what I've seen to work. Yeah. Instead of kind of expressing everything as an objective truth because there are no objective truths in programming [crosstalk 00:26:54]-

Joel Hooks:
I got to say objective truths are stronger copywriting, in terms of strategy.

Tomasz Lakomy
Good point.

Joel Hooks:
So I'm one of my favorite communities in a place where you're active is dev.to or DEV, as people like to call it. I think that's a site that is really amazing and is doing really good work but is also super confusing and overwhelming to just land on. What is going on, and what is up with dev? How could we use it? What is the use case that you see, and how do you use dev in your own content creation pipeline?

Tomasz Lakomy
Yeah. So DEV is surprising for me because, for instance, on Twitter, I refuse to use hashtags.

Joel Hooks:
Yeah [inaudible 00:27:37].

Tomasz Lakomy
Yeah. I don't like hashtags in any way whatsoever. But on dev.to, they are actually useful. So the way I use dev.to is that you are strongly encouraged when writing a post to decent hashtags, so whether it's, I don't know, AWS, React, jQuery, or whatever, and then you get to kind of browse the content by those hashtags. Why I started publishing to dev.to is for the massive community that is there. So first off, the community is large. So you will get a lot of feedback on your posts. Many people are going to see it. Basically, I get an email every day from dev.to that, I don't know, 10, 20, 50, 100 people started following me, well, the day before because it's growing massively, the whole community.

Tomasz Lakomy
So if you are looking for a place in order to kind of promote your content, this is an amazing solution. What is also amazing about the community is that very strongly do they enforce the code of conduct. As in, I've heard some comments, some of my posts. To be fair, lucky and privileged enough that I don't get many of them. But if I do look at one of them, it's very easy to flag them, and they just disappear from the website. They are not visible to anybody else. So it's not like Hacker News, where you'll get those, yeah, the orange websites where the discussions get to be, well, interesting in a not productive way. Here is-

Joel Hooks:
Toxic I think is the word.

Tomasz Lakomy
Yeah. Toxic. Exactly. I was trying to be nice. But maybe it wasn't deserved at this point. But on dev.to, it's so much nicer because you get constructive criticism, you get feedback, but you don't get rude people, toxic people just screaming their opinions in a very unpleasant way at you [crosstalk 00:29:39]-

Joel Hooks:
I feel like they literally chase them out of their room on DEV. You're not welcome here. The design of the site is presented in a way that's like, "Hey, this probably isn't for you. There's plenty of sites on the internet. You can go to Reddit or Hacker News or wherever you prefer. DEV isn't for you. This is a place for conversation and community," is the vibe that I feel that it gives.

Tomasz Lakomy
Yeah. I think it's entirely accurate. I get this exactly the same feeling as well. It's like it's so easy to just make sure that you are going to feel safe. I mean, to somewhat degree, right, I mean [crosstalk 00:30:13]-

Joel Hooks:
[crosstalk] right?

Tomasz Lakomy
Yeah. It's through the internet. But they're doing an amazing job to do all they can in order to make it safe and comfortable for all kinds of folks.

Joel Hooks:
One of the things that's actually interesting to me is from a commerce perspective, they are trying very hard to keep... They'll allow you to use canonical references. So if you post on your own site, you can syndicate to DEV, and they're fine with that. They're very business friendly. So A, head as a business. We can use DEV and post under an organization, and they give us these lightweight ways to give them a little bit of money and promote our products and stuff. It doesn't feel like kind of the startupy pseudo community vibe. It feels like real community that understands business and commerce and learning and sharing and all that stuff. It's really exciting to watch it and see people kind of evolve and use it as a platform.

Tomasz Lakomy
Yeah. I do absolutely agree with that. As in, they're very friendly, and they also sent me free stickers, so I love them.

Joel Hooks:
Oh, nice. Yeah. They have some of the best developer swag game going on, period. They really do a great job on that front. So I want to ask you. You talked about this a while ago, and you talked about your first experience, imposter syndrome speaking at events. I was wondering how that has affected your overall career when you kind of took the plunge and got over that hurdle of your brain telling you no, no, no and started speaking at events. How did that affect you professionally?

Tomasz Lakomy
So that was the best decision in my professional career, to get started. As in, I've started from local meetups. I do strongly, strongly recommend that if somebody wants to do that, start talking at conferences, please start at local meetups because one, you will get experience, and two, they're always looking for speakers. So once I started talking out some local meetups here in Poznan, afterwards, I was also co-organizing some of them. I've started applying to conferences out there. So that conference is in Poland and also conferences in Europe. I've submitted over 20 call for papers in the first year, and I got accepted to one. So yeah. That was another life lesson is that getting accepted into conferences is not easy.

Joel Hooks:
Keep asking.

Tomasz Lakomy
Keep asking. Exactly. Because they get hundreds of proposals. Major conferences, I know probably like React gets thousands of proposals each year. So it's not easy to be selected. But once you do, it opened so many doors for me because getting to know all those people from different countries, different communities, solving different problems, and having different ideas is hugely useful for you personally and professionally. But you also get to kind of share your ideas with others. You get to meet other speakers who, for instance, I know travel from the US. I've never been to the US. So for me, it was kind of an opportunity to also meet folks that I would otherwise not meet at all. To be fair, if I haven't decided to start talking at conferences, if I haven't gone on that journey, we wouldn't be talking here today right now. As in, this kind of car key started my career, gave me much more confidence that I do belong there.

Tomasz Lakomy
By there, I mean, into the international community of developers. Because I had this feeling that there's [inaudible 00:33:55]. There's the, I don't know, others, those amazing conference speakers, and there's the kind of youngest of us, which is not true, not true in any way whatsoever. I do strongly believe that so many people belong on stage. Most people do have a kind of conference talk in them. It's not easy. It's not for everybody. I do know that some folks are going to struggle once on stage. But if you feel like this is something that you can do it to some degree, I do highly recommend that.

Joel Hooks:
I have a lot of empathy for the crippling anxiety of giving public speaking, right? To me, my diaphragm was being squeezed, and I was going to hyperventilate, and I had to stop and drink, just pause and kind of the first few times that I did that sort of thing. Later, as I went through, I found that that my preparation really helped me, like experience and then preparing properly. I was wondering, what's your experience? How do you prepare to give a conference talk and kind of help yourself in terms of practice and preparing your presentation?

Tomasz Lakomy
Well, I would say that I prepare too much, and it helps.

Joel Hooks:
Is that possible? I don't know.

Tomasz Lakomy
I think so. So first off, I think that the best talks both from the experience of the speaker but also from the audience perspective come from practice. As in, you have to be familiar with your own material, and you also have to care about your own material. Because if you're going to give a talk that somebody else told you to give and you don't necessarily care about the material that you're going to be presenting, you are not going to have a lot of fun. But in order to prepare, I would say practice quite a lot. When you do practice, try to simulate the conference environment.

Tomasz Lakomy
So what I do, I stand up. I have a clicker which I bought from okay, Polish equivalent of eBay for, I don't know, $10. I do those kinds of small conferences on my own in my own apartment. When I start talking, I do not stop until the talk is over. I don't restart, in a way. Because you won't be able to do that on stage. What I found out is that if you allow yourself to restart the talk when you fumble, well, your first three minutes of your talk are going to be absolutely amazing because you did went through them so many times, but the last 70 minutes are going to be, well, much more stressful for you because you haven't gone through them a bunch of times, especially when you're speaking in public in your non-native language.

Tomasz Lakomy
I think it's especially useful and helpful to practice out loud, especially when it comes to time requirements. Some people tend to speak faster. Some people tend to speak slower, and then no native language. You also have to account for [inaudible] because you will have like 20 or 25 minutes out there on stage.

Joel Hooks:
Yeah. I mean, to me, it's amazing in terms of none... For better or worse, this industry of software development is English as the primary language. I got to be born with that advantage and privilege of speaking English since I was able to. But to deliver a technical talk in your non-native language, it has to be a significant challenge to overcome, I would imagine.

Tomasz Lakomy
Yeah. This is another part of the reason why I do recommend local meetups first because then you will get experience in public speaking without this other additional challenge of speaking in English. Because to be fair, it's either your native language or English.

Joel Hooks:
Yeah. I saw you recommend the best language to work on for non-English speakers is English for software developers. I think that was a tweet, which I thought was interesting and probably true for better or worse.

Tomasz Lakomy
Yeah. I think it's true. I mean, it's kind of... I wouldn't say sad. But for the lack of a better word, I'm going to roll with that, is that when you are starting as, I don't know, person from Czech Republic, you have to learn English to at least some degree in order to be comfortable programming because the programming languages themselves are in English. Therefore, you have to have a decent understanding. Of course, there are some resources in your own native language. But to be fair, in order to have a successful career in the field, you have to be able to at least learn from the source. So to learn from the documentation, which again is going to be in English.

Joel Hooks:
Yeah. I think one of the things that you just said that was very interesting to me was, when you fumble, you need to keep going and not restart your practice talk because what you're actually doing is practicing how to recover from when you fumble, which is... That's critical, right? If you fumble on stage, you need to have that practice so that you can continue. So the audience always wants you to succeed I think is one of the best tips I've ever received. Everybody sitting there watching you wants you to succeed. We're all rooting for you. If you mess up, it's fine. Just keep going, recover, gain your composure, take a breath, that sort of thing has always been, in my experience, something that's worth thinking about.

Tomasz Lakomy
Yeah, that's absolutely true. Everyone wants you to succeed. If you're going to start fumbling or your demo is going to break, well, other people will actually go out of their way to help you. I've seen demos breaking on stage and someone from the audience screaming how to fix the demo, like you had a missing semi-colon here and there. Speaking of demos, make sure that your demos work online, offline, under water, upside down. Just test the hell out of it because something-

Joel Hooks:
Yeah. Good advice.

Tomasz Lakomy
... will break. Yeah. Something will break on stage at some point.

Joel Hooks:
Tomasz, thank you so much for taking time out of your day to hang out with us and tell us about your experience. I really appreciate it, and I look forward to talking to you soon.

Tomasz Lakomy
No problem. Cheers.

Joel Hooks:
Cheers.