Episode #126: Teaching What You Learn with Tomasz Łakomy
February 28, 2022 • 58 minutes
On this episode, Jeremy and Rebecca chat with Tomasz Łakomy about his work at Cloudash and Stedi, why continuous learning is such an important part of your continued growth as an engineer, how teaching to your former self can help others on their journeys, and so much more.
Tomasz Łakomy is a Frontend Engineer at Stedi, Co-founder of Cloudash, an egghead.io instructor, and a lifelong learner with a passion for learning in public.
Since 2018, he's been diving into the world of AWS and at the same time sharing what he's learned with others. After passing the AWS Certified Solutions Architect: Associate exam in 2019 he recorded multiple courses on serverless technologies, including Build an App with the AWS Cloud Development Kit, and Learn AWS Lambda from scratch.
In addition, he's active on his Twitter, blog - tlakomy.com, as well as The Practical Dev community, where he posts articles on career advice, testing and - of course - AWS.
Transcript
Jeremy: Hi, everyone. I'm Jeremy Daly.
Rebecca: And I'm Rebecca Marshburn.
Jeremy: And this is Serverless Chats. Hey, Rebecca.
Rebecca: Hey, Jeremy, how you doing?
Jeremy: I am doing well. I actually am on vacation for two days. I took two days off of work so that I could catch up on some work, is basically what I did.
Rebecca: So you say you're taking a weekend?
Jeremy: I'm taking a week... Oh, what are weekends?
Rebecca: Good, glad you're...
Jeremy: I don't know. I forgot what those are. When you have kids, it gets a little tough to find time for yourself to do things. But actually tomorrow I'm going to take my youngest daughter skiing for the day so that should be fun.
Rebecca: Yeah. That'll be really fun. Good on you.
Jeremy: So what have you been up to?
Rebecca: I am actually, you might notice my background is a little different. I am visiting my mom.
Jeremy: Oh, nice.
Rebecca: And some of my family in the Bay Area. And it's always interesting to work in a new place. Super grateful that I get to do it. Also, strange because there's four dogs running around, two small children, lots of trying to quiet the barking or the garage opening. And it just brings back nostalgic memories of oh, okay, this is, yeah. All right. Lots of stuff going on.
Jeremy: Yes. Well, I have my 13 year old daughter I think holding my dog's mouth shut so he's not barking right now. So anyways, so hey, speaking of new places, although this not really new for us, we've had some guests from Poland before. But we have an excellent guest today. And I'm going to ask you, Rebecca, to introduce him because of the pronunciation of his last name.
Rebecca: I would love to do it, and I see him smiling right now. I wish everyone else listening could as well. He's like, all right, let's see how this goes. He's rubbing his hands together. So our guest today is front-end engineer at Stedi, and co-founder at Cloudash, and an instructor at egghead.io, Tomasz Łakomy. Hey, Tomasz. Thank you for joining us.
Tomasz Łakomy:
Hey, my pleasure. Thanks for having me.
Jeremy: You nailed that, Rebecca. That was good.
Rebecca: Did I? Okay, all right.
Tomasz Łakomy:
That was authentic. Close enough.
Jeremy: Close enough.
Rebecca: So Tomasz, why don't you tell the audience a bit about yourself and then what both Stedi and Cloudash do. There's a lot of things in the introduction, and so maybe let's break them down a little.
Tomasz Łakomy:
Sure thing. So my name is Tomasz Łakomy. I am based in Poznań, Poland, born and raised actually. So like I said, I'm a front-end engineer at Stedi among some of the other are things that I do. I end up wearing multiple hats sometimes even on the same day. So Stedi is a very much serverless startup which started in the US but currently we have employees all around the globe. I think that we cover, if I remember correctly, 13 or 14 countries. So basically the work happens 24 times six because we have also employees in New Zealand. So basically they work in the future. And what we are building is an EDI platform for developers for building business integrations. And if you are not aware of what EDI is, honestly, I don't blame you because I was not aware of EDI before joining Stedi either. EDI is a ancient data communication, let's call it a standard.
Tomasz Łakomy:
So effectively what ends up happening is that if I create a company and I want to sell you, I don't know pans, for instance. I sell 10 pans and then 100 pans, and then I get so many orders for millions of them and so on. At some point you want to automate all those business transactions. And at some point you're going to realize that you need to integrate with this thing called EDI, which stands for electronic data interchange. And this is effectively what, more or less, everyone uses in eCommerce business. Sometimes even realizing that this is actually happening under the hood. So in that sense, it's a ancient backbone of modern eCommerce. And not only the standard is ancient because it was first created back in 1970s. So it's way older than I am but...
Jeremy: Hey, I was created in the 1970s, so I'm not that ancient, late 1970s. Anyways, sorry. Continue.
Tomasz Łakomy:
All good things were created in the '70s. In any case, all those platforms were also stuck. Back in the '90s where I come from, by the way, because I was born in 1990, and there's little to no innovation in this area. What we are building is a set of products that allow any developers to build their own business integrations themselves. On top of course existing AWS infrastructure. We use AWS everywhere all the time. So effectively what we allow customers to build their own integrations by standing on our shoulders.
Jeremy: Very cool. So let's talk about Cloudash, though. So this is a side project that you're working on with Maciej... Is it Winnicki, is that the...
Tomasz Łakomy:
Winnicki.
Jeremy: Okay. Winnicki, okay. Wow, man. Polish names. I can't do it. I did get Maciej right though. Only because I work with a Maciej so I know that one. But anyways, I think you told me at re:Invent that actually Maciej does most of the work on Cloudash though, right?
Tomasz Łakomy:
Yeah.
Jeremy: I'm totally kidding, but no. So tell us about Cloudash and what that's all about.
Tomasz Łakomy:
Yeah. So apart from my day job at Stedi, I'm also a co-founder at Cloudash, as you mentioned with Maciej Winnicki. So basically Cloudash is a desktop app for macOS and Linux with windows support coming shortly around the corner for monitoring serverless applications because the idea behind Cloudash is that AWS is amazingly good at wide range of use cases. So for instance, they have CloudWatch which is excellent for monitoring everything, really. So it's stuff on EC2, stuff on Docker containers and so on and so forth. But what we found out along the way that there's a niche that's missing when it comes to serverless developers. So we are building a laser focused product that allows serverless developers to understand and investigate what is happening in their serverless applications and infrastructure. So for instance, to give you an example, imagine that I am on call right now and I get page in the middle of the night. Our goal is to build Cloudash in a way that this is the only app that you need to open in order to understand, okay, those are my metrics.
Tomasz Łakomy:
Those are my logs. Okay. This function has errors for some reason. I can click over here and see all the graphs and so on to have a very quick understanding of what exactly has happened because when you get page in the middle of the night, honestly, you are under enough stress already. And you don't want to have the stress of, okay, which CloudWatch tab was that again that I have those logs that I need to figure out right now? We are trying to make this experience much, much easier. So we currently support Lambda and API gateway. We want to introduce support for other services along the way as well. Effectively, we are also using Cloudash on a day to day basis.
Tomasz Łakomy:
So we are effectively building this product for ourselves while also of course, providing this for our customers on a monthly basis, because you can buy [inaudible 00:07:31] subscription. Either you can pay us monthly or once per year, whatever suits your need. And you can use it as many time as you want. And because it's a desktop app, everything that happens on your machine stays on the machine. So we are not sending your logs anywhere. We don't store them. We genuinely don't care what's in your logs. I have enough on my own logs to analyze. I don't need yours.
Rebecca: So I love that you're one, building this in a way to solve your own problem, right. And then you're like, okay, it's laser focused because I know exactly what I'd want to solve for myself. And I'm guessing having something to do with log storage might be part of the answer to what I'm about to ask. But with all the observability tools out there, how do you describe what's different about Cloudash?
Tomasz Łakomy:
So basically what's different is that it lands on your machine and we only get the logs from AWS that you ask us for. So in some of the other solutions, which I'm not going to name because this is not about naming competitors and so on. But it's more of a, they're going to ask you for some credentials or you have to import all the logs into their system in order to be able to analyze them, to run some metrics and so on and so forth. Whereas for us, if a system is up and running, you have an SLA of seven nines or whatever, you have an incident. You only want to laser focus on this particular incident time in this hour when the system was down because I don't know, [inaudible 00:09:00] had some hiccups as opposed to paying for 99.999% of the time where everything was perfectly fine.
Tomasz Łakomy:
So that's one difference. And secondly, like I said, we are laser focused on serverless developers and this serverless experience. So for instance, we decided that we needed to include API gateway support and all of the logs that come with it because we were not able to investigate some of our stuff, and it launched literally yesterday. So there you have it. Now we can use it. We have so many other idea as well, like integrating with alarms. So for instance, if I get a CloudWatch alarm, I should see all of that in Cloudash. A secondly, we want to also integrate with CloudWatch logs inside so I can query logs inside of Cloudash. So basically the possibilities are endless and I'm honestly very excited to see where it's going to lead us in the future.
Rebecca: Yeah, that's super cool.
Jeremy: So I think that's a super interesting approach where it's like all of these platforms, we're talking about open telemetry and all these other things. And they're ingesting all this data and you're log shipping and usually these services will run within AWS. So you minimize, I think, to some degree data transfers, data transfer costs and things that. But really interesting what you're doing, bringing that all down to the desktop and just using the native AWS tools. And again, you can do a lot of really interesting things so far with Cloudash. So it's cool to hear all these other things you want to do, but I'm actually curious about your opinion or your thoughts, and this is probably part of the reason why you built Cloudash. On this AWS information segregation problem, maybe, you mentioned all these multiple tabs, right?
Jeremy: The thing that drives me nuts is if I'm going into debug a Lambda function, even if I'm just building a small app, before I've got all my observability set up and all these other things, you're like, okay, go to CloudWatch logs. And then go to this log group, and then go to this particular... Then search all log groups, and then try to find what it is that you're looking for. And that's on one function. You're like, oh, now I got to go find the API gateway logs. And now I got to go find this. And what if I have four functions running together or they're communicating with this?
Jeremy: Because it is the biggest headache to try to pull all that stuff together. And AWS seems to do this with everything. And again, maybe it's the two pizza team thing. Maybe it's just the way that the isolation of the stacks work, but this is just a common pattern, I think, that AWS falls into, is that everything is segregated. And when you want to bring that all together, it's really hard to do. So, I'm just curious, maybe why... So maybe two questions here. One, is that the primary motivation for this, just to find that easy single pane of glass locally, whatever, using these existing tools? But more so, where do you think that disconnect is with AWS?
Tomasz Łakomy:
Okay. So this is a very good question, a very good point. As I mentioned effectively, what we are trying to build is something that allows developers to go into the root cause of an issue as soon as possible without having to fight with the UI, with the console and having this mental overhead of, okay, so I clicked on this log group. Now I have to go this, now I have to copy this ID. I have to paste it over here because when you have an incident, your mind is racing and it's not easy to understand what's happening even without the UI and the experience getting in the way. So we want to get out of your way. We want to minimize the time that it's needed to have an understanding of what's happening in your system to have view on the logs and the metrics and the charts as soon as possible.
Tomasz Łakomy:
And it's basically a horizontal view of the serverless landscape because we don't have a product manager that we report to or something like that. In fact, there's only two of us, so there's Maciej and myself in this. So we are able to iterate much faster, and we are not focused on only single particular service like Lambda. And then we have to talk to CloudWatch team to add something and stuff like that. And secondly, when it comes to AWS, I think you are absolutely right, that some of those concerns effectively are a result of teams being very independent because of course, having independent teams that can shape software independently is an excellent thing because they can move so much faster. There's less friction. Diversity goes up, but sometimes you need to take a step back and understanding how this entire experience shapes up for the customer.
Tomasz Łakomy:
And sometimes it works, sometimes it doesn't. And I am a front-end engineer. I do front-end CSS, HTML, React, and all of that in the browser. And I have this unpopular opinion that I do like AWS console. I think that AWS console is great given the constraints that they have because AWS is a remarkably complex product. And being able to serve as that to the customers in a browser, this is remarkably difficult. I think, of course there are [inaudible 00:14:16] for improvements. There's so many low hanging fruits in the console and so on, but it's a miracle that everything is possible for the console, even though I prefer CDK.
Jeremy: Well, you said something in there that I thought was played on a theme that is also something that I keep pulling on this thread, but it's this idea I guess the dynamics of what it means to be a developer. You said you're a front-end developer, but even as a front-end developer, you're probably still deploying some backend things or interacting with AWS. And for someone who even was a traditional backend developer, this is somebody who went from writing some code, maybe having a test environment to test it in, but then that very much so throw it over the wall and then let the ops team deal with it.
Jeremy: And we've seen this change in dynamics now where cloud developers, full stack cloud developers or backend cloud developers or whatever, they're becoming more and more responsible. Not only for their code and their code running in production environments, but also they're responsible for the services they pick and, oh, I decided to use DynamoDB or I decided to use EventBridge. Now even though that's a an ops thing you would think of, you are now responsible for a lot of that. So just, I guess your thoughts on the visibility into that, how important is that now become for your average developer to almost become an observability expert as well?
Tomasz Łakomy:
That's a good point. So I can probably answer that, but by describing how I work on a day to day basis at Stedi because I think this is relevant. So we have fully independent teams. So for instance, my team is working on our product which is called Mappings. Mappings is a product that allows you to build JSON to JSON data transformations, to put it very shortly. And everything at Stedi effectively is written in TypeScript. Everything is written using CDK and deployed using CDK. So my job title is a front-end engineer. I spend most of my time on the front-end side. But nevertheless, because we are using this single programming language, single paradigm of TypeScripts on the front-end, Lambda functions written with TypeScript and also CDK.
Tomasz Łakomy:
Like I said, those decisions that you need to make when it comes to infrastructure and deploying, how do we deploy stuff? How do we architect stuff? It keeps moving towards the developer, right? So in that sense, I think this is good. I genuinely don't mind expanding my horizons because like you said, in the before times before I was into the cloud, I was responsible only for writing the code. Right. Like I said, I was writing some stuff. I was pushing it to GitHub, and then it magically appeared somewhere on a server which I wasn't thinking about. Right now, I'm not thinking about servers either, but you know what I mean?
Tomasz Łakomy:
Whereas right now, with the advent of infrastructure as code and all of those other technologies, it's becoming I dare say simpler to have a greater understanding and greater influence when it comes to how your production staff gets architected. As opposed to joining a legacy enterprise company who has been building stuff this particular way for the last 20 years, and good luck changing anything there. With CDK and AWS infrastructure as code, we get to create, destroy production stacks in minutes. And I think this is something that if you are very much into cloud world, you keep forgetting about this, that you could create production stack in minutes and destroy it afterwards. This is remarkable power.
Rebecca: So I'm interested in... And at first I thought you were going to say, okay, the amount of decisions that are now being pushed in the developer direction is almost an overwhelming thing. And I shouldn't have completed that thought in my head because you're like, I really enjoy the number of decisions that are now being more pushed toward the developers sphere, if you will. And so I'm wondering if you have a framework or a mental model of what the right amount of decisions is and when something becomes developer mental overhead? When that decision making, or maybe it's decisions philosophically about how you handle something, or actually the tools you have to use to do it, and the tools are asking you to make too many decisions in a moment that's already super pressurized. So maybe you have some ideas around the, let's say, optimal mental model and number of decisions and when something just becomes overhead,
Tomasz Łakomy:
That's a good question. So I can be very cliche and say, it depends.
Rebecca: Love it. Go forth.
Tomasz Łakomy:
Yeah. But no, apart from that, I genuinely think that having developers make lots of decisions, it's nothing hugely painful within certain boundaries. So for instance, if you are working for a serverless startup, like me at Stedi, we have some of the decisions that are made up front, and this is what you sign for when you are joining Stedi. So for instance, we are using AWS for everything. So you are not going to ship stuff on Azure, for instance. We don't mind Azure, but we are using AWS.
Tomasz Łakomy:
Secondly, we do everything in serverless paradigm, right? So it's actually not possible to create an EC2 instance in any of our accounts. I haven't tried, but I was told that it's not possible. But when you have a certain amount of constraints when it comes to the paradigm and the programming language, for instance, some predefined sets of architecture decisions. Because for instance, again, using CDK, your company may have created a set of custom constructs that, Hey, we allow you to make decisions about the library that you're going to use in code, or how do you actually write the code and what do you use for tests as long as you write those tests, because testing is important.
Tomasz Łakomy:
But for instance, if you need a REST API, this is a construct that you can download from our internal MPM and use that because it has all the best practices and security capabilities built in. In my opinion, there's nothing worse than reinventing the wheel when it's not necessary, especially when it comes to stuff like security authentication. Nobody wants to implement their own authentication stack and so on.
Jeremy: Yeah, totally agree. And I think that, again, the ability for developers to make decisions is actually quite empowering. And then putting some of those guardrails in place like you said, like having some of those boiler plates to start. But that's one of the things I love about serverless is that it's like, you can do a lot of different things. And even if you didn't standardize on TypeScript, for example. If you wanted to write some functions in Python and some in Go or whatever, you have the flexibility to do that. You have the flexibility to spin things up and tear them down very quickly. And I do like the idea of standardizing on TypeScript. Although, the CDK isn't my cup of tea. I do definitely see the power in it. I love the idea of constructs.
Jeremy: I love the repeatable stuff there. But if you are a developer who can write TypeScript, and now you're saying, oh, not only can you write front-end code whether it's React or whatever using TypeScript. Now you can write your Lambda functions, your backend code doing it. Oh, and then by the way, you can also write your infrastructure as code using it as well. Which I think is a pretty good model for a company to have to break down those barriers in between, or reduce the learning curves and break down the barriers between different disciplines, I guess.
Tomasz Łakomy:
Exactly. Honestly, I was blown away when I find out about CDK back in 2019, late 2019, but hold the phone. I can do [inaudible 00:22:18] stuff in TypeScript. It's mind blowing. It's not only about CDK because I remember quite vividly when I saw for instance, serverless framework for the very first time, I had two weeks of experience with AWS. And then I saw a serverless framework template and somebody told me, hey, this is a declarative description of stuff that we're going to provision in the cloud. And they hit SLS deploy, and I saw all those databases and so on created in the cloud.
Tomasz Łakomy:
I was absolutely blown away that it's possible because as developer with a traditional front-end background, I was very much convinced for years that this is hugely difficult. This is beyond my range. And right now the tables have shifted because for instance, I see backend engineers going, no, I am not touching front-end. Front-end is way too difficult for me. I'm going to hug my DynamoDB table. This is so much easier. I don't want to do anything on the front-end side.
Rebecca: So something that really, really, really impresses Jeremy and I about you and your work is how passionate you are about learning. And so I want to make sure that we hold some time to talk to you about this specifically. But before we go too far in, generally as I like to do, as I want to do, I like to see, okay read some of the stuff that you've published, and then see what's going on on your Twitter to see what's on your mind right now. And then I like to go into GitHub.
Rebecca: And just for anyone listening, today is February 22nd where I am sitting, it is 8:35 in the morning. And I know that Tomasz is in Poland. So it's a bit of a time difference, but I was like, okay, what's he been doing on GitHub? And he made 17 contributions today on February 22nd before 8:00 AM my time. And I was like, what is going on? It's not even 8:00 AM and there's been 17 contributions because I was like, yeah, 78 reposts, sweet, 71 stars. Awesome. Nice. And then the contributions graph was just bright green. And I was like, what? It's not even 8:00 AM. And so before we go too far into learning, I'm curious if there's any contribution... What's the last contribution you made or what's your favorite one from today? 17 before 8:00 AM is pretty impressive.
Tomasz Łakomy:
My favorite one is not from today, but I have something that I did a while back and I thought that it was quite useful. This is probably going to also mentioned sometime later in the episode, but I also teach web development on egghead.io. So at some point I was building a CDK course which actually I have two CDK courses published, and the first one of them launched last year. And when I was working on this, I ended up preparing a CTK workshop, which is available on my GitHub account. And it's there. I don't monetize it, whatever. [inaudible 00:25:19]. I wrote it with this idea that somebody can just take this repo and learn CDK on their own. My favorite part is that every now and then I get a DM on Twitter with somebody who found this repo and they go, hey, this is so dang cool.
Tomasz Łakomy:
I've learned CDK from you from this particular repo. So I guess what I'm trying to say is that sometimes when you create content and you publish stuff, you never know what's going to click. So sometimes even something that was [inaudible 00:25:53] prepared for you, just I'm going to push it on GitHub so I don't forget. It's mind blowing that sometimes it takes back and somebody else can gain the benefit of just putting some stuff out there. This is partially why I also publish some notes on my blog because I go like, okay, I have some notes. Some of them are actually okay-ish to be published. Some of them are not. I don't publish those. But still, if I learn something new, it's worth it to just publish it. Worst case scenario is nobody's going to read that.
Jeremy: And that's a really interesting point that you made about you putting stuff out there that it will click for somebody, or sometimes it clicks. And we talk about this a lot where you see the same blog posts sometimes about the same subject written a thousand different times and a thousand different ways. But here's the important thing to remember is that you could rewrite a blog post in your viewpoint or from your viewpoint or how you see it, how you digest it or what your mental model is. And that might be the mental model of other people where then it finally makes sense, because I've read a ton of blog posts about things that make no sense to me. And then I read one that's basically exact same thing, but for some reason this time, it makes sense.
Jeremy: So I think that's super important. And you mentioned the notes that you do. So you're watching a lot of these videos. You mentioned [inaudible 00:27:13] course, some of the re:Invent sessions that you've watched, DynamoDB modeling with Alex DeBrie. So some of these things, I'm just curious, not only just this importance I think to you to have the accountability maybe to yourself to say, I've watched this. I've taken some notes. I'm going to put these notes out there. And then for you even being able to say to yourself, if these notes aren't good, either maybe the content wasn't good or maybe you didn't take very good notes. Maybe you didn't learn enough from it, but I'm just curious what your thoughts are on how important it is for developers to take the time to do things like that, to watch the re:Invent sessions or to buy a course from [inaudible 00:27:57] or something that? And to take the time to go through that, what's the importance of that for you?
Tomasz Łakomy:
Well, I think it's hugely useful and absolutely I dare say necessary if you want to stay in the game, especially when it comes to some of re:Invent videos, because, well, I am a visual learner, for instance. I do read blog posts, but I learn the best while I'm watching videos. So for instance, I end up watching quite a lot of re:Invent '21 videos because obviously I was not able to attend every single talk because this is not humanly possible. So I end up watching quite a lot of those and learning some stuff and trying to share as many of those that I find interesting on Twitter. [inaudible 00:28:45] yet to watch any bad session from last year events. All of them were absolutely excellent.
Rebecca: Kudos to the team.
Tomasz Łakomy:
Exactly. I think it's hugely important to be a lifelong learner when it comes to having a successful career in tech. It's not exactly a trade where you, I don't know, practice for three months, gain a particular skill and then you can fly with that for the next 25 years before you retire or whatever. It's something else. It does require stepping up, learning some stuff. And this is why I also enjoy both creating and consuming courses.
Tomasz Łakomy:
Like you said, [inaudible 00:29:30] stuff is absolutely excellent. I was going through his AppSync course last year and I've learned a ton because you have documentation, you have blog posts, you have all of those re:Invent videos. But very often what you need is somebody who's going to take the time and is going to compile all of this content together in something that is much more streamlined, that has order, that has focus. And it's so much easier to get in and understand, okay, those are the steps that I need to take in order to use the servers successfully. Because for instance, not every single re:Invent talk has a live demo. And if they do, they're probably going to play it safe. So it's usually [inaudible 00:30:12] stuff which I also do on stage. I'm not going to do, I don't know, production deployment on stage.
Jeremy: Right. Well, and actually before we get into the teaching aspect of this, the consuming aspect of this, you mentioned you like videos. And it's funny because sometimes I will watch a video, but if I watch a video, I wish YouTube had a 4X speed because I have to watch videos very fast. I don't have time for watching things slow. Even when I listen back to this podcast, I put it on the highest speed as possible, but I love to consume content very quickly. And I usually scan documents very quickly. So that's why I love blog posts.
Jeremy: But from a consuming standpoint, it's not just about the individual video or the individual blog post. You mentioned this idea of this consolidation, this idea of bringing in, maybe not all the details, but at least enough of the context of a problem or of a product or service or whatever it is that you're learning, bringing that all together. So from your standpoint, is there a balance between that because I always find the blog post randomly that talks about some specific edge case, which is helpful. But from your experience or from your, I guess, just what you like to do, and maybe your recommendation, do you find things like courses and more of these compiled things to be a better choice when people are trying to learn something new? Or for them to just go around and find a bunch of blog posts on the subject?
Tomasz Łakomy:
I am obviously biased because I do produce courses, but I would go with courses when it comes to learning something new from scratch. So effectively it's about being T-shaped. You have this idea of T-shaped developer. So you have horizontal skills and vertical that is your domain of knowledge. So I would say that if you are trying to learn for instance, a new service or a new paradigm, buying or getting into a course or a workshop is an excellent idea. And afterwards, like I said, I think that many blog posts are very much not edge case focused, but they're focused on a very particular problem. I don't imagine that somebody's going to write a blog post that's going to take you a week to read, compiling everything that you need to know in order to use AppSync and production.
Tomasz Łakomy:
But they're going to write about this one very specific setting or something that. So for instance, my colleague [inaudible 00:32:41] who like I said on Twitter, he should be the sponsor of [inaudible 00:32:46] newsletter because you end up featuring him every single week. He creates lots of blog posts who are short, very much to the point, but you always learn something new. It's usually a combination of those two, but I do tend to start with a course. For instance, when I was trying to get AWS certified in 2019, and later in 2020, I ended up going through stuff on A Cloud Guru, which is absolutely excellent. I do highly recommend them because if you want to get certified, you can either pay somebody to give you this content in a streamlined form. This is what you need in order to pass the exam. Or you can go to AWS documentation to try to understand which one of those 30 million pages I need to read in order to pass the exam.
Rebecca: So I loved how you said learning, especially for tech or really, I think you would expand that to all things, right? You used the word necessary. And I think to build this bridge from learning to teaching, there's something so special that happens when you start to teach something that you also learn where your own gaps were. Or that you learn something new about, oh wow, I was going to try to teach this to someone or put it together in a concise way. And instead I'm now understanding where my own limitations are and what else I need to learn next. And so to build this bridge into learning more about what you are doing in the teaching sphere, I'm wondering if there's a moment that you could talk about where you were building a course where you worked backwards and ended up learning something new in the building of that course?
Tomasz Łakomy:
I've had so many of those moments when I was working on some of my CDK stuff. For instance, I had a lesson plan because I tried to work backwards. So each one of my videos has a title and description. So I write those first and later work on the examples and the videos and so on to have an understanding first, what I want to teach. And secondly, how do I actually do it? But I was going through those and then I figured, okay, this might not be obvious to somebody, but what if somebody is not going to enable this setting? What's going to happen then? And then I figured, oh crap, they need to do this. Oh, right. So I'm going to add this additional one lesson, for instance, on generating types for your GraphQL schema.
Tomasz Łakomy:
Because, well, I made the typo, it broke my stuff, so it's probably going to break somebody else's stuff. So then I had to dig out, okay, how do I exactly generate types for AppSync GraphQL schema? There's a package for that. I found a blog post, by the way. I cannot remember who wrote it. I can share it on Twitter probably, but it was very short. It took me a minute to read ,solved my problem. I put that into the lesson. So the course got better as a result of me struggling for a bit.
Jeremy: Yeah. And I think that that idea of things not being obvious, it's something that we lose all the time. I do this all the time where I'll look at a blog post, it'll be a getting started blog post, you go through the first five steps and then step six, somehow seem to skip 45 steps. And you're like, wait a minute, how did you get from here to here? And you get stuck on those things. But we talked with Eric Johnson about this too, this idea where you don't want to necessarily be insulting to some people where you want to be like, okay, so now you type this and then go and turn the power on, on your computer. You know what I mean?
Tomasz Łakomy:
Use your keyboard.
Jeremy: Right, use your keyboard.
Tomasz Łakomy:
Left mouse button. Not right, left one.
Jeremy: Yes, exactly. And that can get a little bit... Again, it's a fine balance, but yes. I think that is important too where as you're writing or producing content for anybody that you go through this stuff. And so anyways, so you mentioned, or I guess Rebecca mentioned, some courses. You've done a few courses. We were trying to figure out what it was.
Rebecca: Just a few, though.
Jeremy: Yeah.
Rebecca: A paucity, really. We're just waiting for more.
Jeremy: Something like 800,000 I think, or something. Or maybe 210, whatever it is.
Rebecca: Nearing a mil.
Jeremy: There's a lot of courses on there.
Rebecca: Actually, wait, Jeremy, can I stop you for one second?
Jeremy: Yeah. Absolutely.
Rebecca: I did the math on this. I go and I'm like, let's look at Tomasz's courses. And I was like, okay, there's three across and seven down. I was like, oh, 21. And I was like, wait it paginates. And then I was like, oh, it paginates to seven. And then I paginates over and it's like, oh, paginates to 10. So 210 courses so far just instructed, constructed by Tomasz [inaudible 00:37:17].
Jeremy: So, why don't you tell us a little bit about some of the courses that you've done? What are they primarily focus on?
Tomasz Łakomy:
Sure. So I joined egghead [inaudible 00:37:29] in 2018. And the context was that I've learned web development from egghead.io back in late 2015, I was trying to find a new job, and React came out, at least in my sphere of influence. And I had no idea what this is. I bought an egghead subscription and I managed to level up in a month. Basically I doubled my income at the time, thanks to egghead. So I was very happy that I could have a chance to contribute back. And I was invited and basically the way egghead works and all of my videos is that you have courses which are a collection of multiple videos. And also you have those separate videos. So looking at the site right now, I have 207 videos published. Holy crap, over 200, I thought it was below 200.
Tomasz Łakomy:
So I have stuff on React. I have stuff on testing. I was the first person who recorded a course on React 360. That was a VR framework for React which suddenly doesn't exist anymore, but it was honestly exciting at the time. I have stuff on AWS. So I built two courses on AWS. So I have Build an App with the AWS Cloud Development Kit which is my magnum opus. And I also have something that I published last year. And it's about building a GraphQL API with AppSync. And the target audience for all of this is myself a year ago or two years ago. When I was starting to get into AWS in 2019... Actually I was encouraged by Maciej Winnicki at the time to become certified as a AWS solutions architect associate with zero experience with AWS at the time.
Tomasz Łakomy:
I had to struggle. That was not simple to say the least, so right now I'm trying to figure out, okay, what do I need to do in order to help other developers to make it so much easier? So this is particularly why I try to create all those courses and all of this material so that other people don't have to struggle. And so far I was lucky enough to get excellent feedback for basically all of my stuff. It's useful. Like I said earlier, there's nothing close to having a DM on Twitter by somebody who says, hey, this particular video, it opened my eyes. I learned something new. I was struggling with this way of deploying stuff. Or how do I write this particular test or something that? And this video helped me. And honestly it means a lot every single time somebody does that.
Jeremy: Yeah, totally agree.
Rebecca: So, let's say there's another you, or as you said, you're building courses for an audience of you or someone like you in your shoes. Let's say a developer wants to learn a new framework or language or platform today. You were inspired by a job opportunity you wanted to pursue, right. What would you recommend? It's been a year now, let's say, or actually a couple years. What would you recommend they choose today and why? If they were like, okay, I have one new framework, language or platform that I have the time and mental space to learn right now?
Tomasz Łakomy:
I would probably start by... Maybe a concrete example would be better. So for instance, if I want to Svelte which is a JavaScript front-end framework, I would start by reading the documentation. I know that we have been talking about courses and so on, but nowadays I tend to think that you can start with the documentation. Try to at least skim it to have a rough understanding, okay, this is how it looks like. This is the syntax. This is what I can use it for and so on. Afterwards, I would probably try to get a course or workshop or something that. And lastly, and this is also hugely important, to experiment with it because I do enjoy videos. Like I said, I watch ton of those, but only passive consuming content.
Tomasz Łakomy:
This clicks for some people, but it is not going to click for everyone. But if you get in, try to experiment with some of the stuff, find some problems and to have an understanding, okay, this is not optimal. This is not trivial. Okay. So I'm going to go back to the documentation or I'm to find a blog post addressing this particular problem. And last step which is something that I was trying to do, I am not active these days, is to share it afterwards. So publish some notes, create a blog post, publish a video or something like that. People tend to avoid writing blog post about the things that they have just learned. And I completely disagree. In my opinion, it's one of the best times to write a blog post because you have this experience and perspective of a beginner in this particular area. So your content is going to click with somebody who's also getting started.
Rebecca: Yeah. It's like that circular teaching, learning, teaching, learning, or learning, teaching, learning, teaching.
Tomasz Łakomy:
Exactly.
Jeremy: Totally. Maybe I heard your question a little bit differently, Rebecca, and we did the same thing with Eric Johnson. We asked what was his favorite programming language or what was the best programming language. I'd actually like to hear an answer to that in your opinion. Now CDK obviously TypeScript and I think you're big into React and all these other things, or and actually Svelte as well. But if somebody is coming into the space, maybe they're a JavaScript programmer or whatever now, and they're getting into cloud, is there a framework or a collection of tools? What is probably the best thing for someone to get started? What specific, I guess, framework should they learn maybe is an interesting question.
Tomasz Łakomy:
They should [inaudible 00:43:22] by hand. Learn the hard way. Just kidding. That's a good one because I think that it doesn't exist yet. My personal mental model is that there's so much to be done in this area of getting started with the cloud and learning all of this stuff. I saw that, for instance in serverless cloud, you guys are getting very close to what I'm thinking about. You have this idea of infrastructure from code. And I think this is also related to CDK. This is roughly where I envision all of those frameworks that are going to aim at, because if you want to get started with AWS, you probably want to build something from the get go. To have at least a rough understanding, okay, this is Lambda function.
Tomasz Łakomy:
I want to evoke a Lambda function in 10 minutes. I don't want to spend so much time fiddling with documentation on CloudFormation, or doing [ClickUps 00:44:33] in the console. So I don't have a very concrete answer to this. I think that the possibilities are still out there, but I would imagine that a mix between current solutions, CDK or serverless cloud or something totally different. What I'm trying to say is that this declarative model of building stuff in the cloud, this is the way to go. And it should be way more declarative. In terms of imagine 10 years from now, you have GitHub Copilot version 5.0, and I can talk to it, give me a REST API. Okay, there's a POST endpoint. There's a GET endpoint [inaudible 00:45:18]. And do this. It should have GraphQL, add some monitoring and wake me up in the middle of the night if something is broken. It should work like this.
Jeremy: Right. Yeah. I think actually that was a good answer because I think that's part of the... It's part of the reason why we're working on serverless cloud, but this complexity of people getting into this. And I know you had mentioned earlier in the podcast, you had said where it seems like it's getting easier. And it is once you understand all the pieces, right?
Tomasz Łakomy:
Yes.
Jeremy: But I think getting into it, it is a very, very broad ecosystem that is not easy to get into. And the DX, the developer experience is just something that needs a ton of work.
Tomasz Łakomy:
Yeah, exactly, because when you log into AWS console for the very first time, right now, they redesigned the AWS console so this doesn't work that well, what I'm about to say doesn't work that well. But before that, you logged in for the very first time and you saw a list of all of the services, where do I start? What do I do? Of course, on the right hand side, there's a welcome to AWS section. You have getting started with AWS stuff and so on, but it's still remarkably difficult to get started in this space.
Tomasz Łakomy:
And that was partially why I was struggling with the answer, where do I start? What's the best framework? Because I don't think that we are there yet. I think there's a tremendous potential for the next million or 10 million cloud customers to have a better understanding of how does this stuff work? Why do we do serverless? Why we are excited about not running [inaudible 00:46:55] and so on. [inaudible 00:46:55]? This is a hugely exciting time, but maybe we will get there in a couple of years. I'm excited to see what's going to happen.
Rebecca: Yeah. I was just going to say that you're like, I don't know if I really have an answer for that. And then you're like, it doesn't exist yet. And I'm like, that's a pretty fascinating answer. I think you should give yourself a little more credit. And maybe to bring this conversation full circle, we kicked off and you told us a little bit about what you're doing at Stedi before we dove into Cloudash. But let's go back to Stedi for a moment because it sounds like you're doing some excellent side projects from there. It sounds there might be some other side projects going on or that people have the ability to pursue.
Rebecca: And maybe one of these side projects will grow into that answer that you five years from now would be able to give us when we're like, hey, what is that framework? And you're like, oh, it exists now. It started as a side project at Stedi. And so I'm curious if you can tell us a bit about even Stedi's culture or how you've been able to find time for your side project and whether or not it's woven into your work at Stedi or how that company's being built? Or if it's just something where you're like, hey, here's advice for carving out time to find a side project if you're super passionate about it.
Tomasz Łakomy:
Good question. So Stedi is a collection of the most talented engineers I've ever met and myself. So everyone here is as talented, I mean, they're as kind as they are talented, honestly. It's an excellent team. In my opinion, it's the biggest collection of AWS experts outside of AWS. I think that we have the biggest AWS hero density when it comes to the company size of all of these startups out there. So because we are building everything on top of AWS, we seem to notice some of the cracks in AWS design or in AWS DX and so on. And sometimes some of us decide, maybe there's an opportunity there. Maybe I can crack something new.
Tomasz Łakomy:
I don't want to talk too much about what's what's coming for Stedi, but I can actually, there are some exciting thing comings for developers who want to build business integrations. Watch this space. But when it comes to side projects and so on, it's mostly, like I said, some of us noticing there are some cracks, let's start to fix that. So for instance, [inaudible 00:49:25], who is also on my team is working on Dynobase. I think he was a guest of this podcast.
Jeremy: He was, yep.
Tomasz Łakomy:
Last year or two years ago. Yeah. So he's working on Dynobase. So he's trying to solve the problem of DynamoDB single table design, and so on. Zac Charles, who's also my coworker. He's working on a tool for VTL which in my humble opinion is another area of database [inaudible 00:49:51]. I don't particularly enjoy VTL. I am not smart enough to handle it [inaudible 00:49:58]. We have lots of engineers who are building side projects on the side. And some of them are quite successful and all of them are hugely useful. At least I think that Cloudash is useful, at least it is for me. When it comes to carving the time and trying to understand when do I do that?
Tomasz Łakomy:
I think it's mostly about something that you actually care about because if you are trying to build a product only because you want to raise 10 gazillion dollars or crypto, whatever, but you don't care about solving this particular problem. You don't care about this problem domain. You don't care about your customers. You are probably not very likely to find this motivation, this interest and motivation that you need in order to pursue something on the side. Whereas when Maciej showed me Cloudash for the very first time, back in 20, at the end of 2020, if I remember correctly, I was like, this needs to exist. As in, I was getting into the space of serverless engineering and I was a bit frustrated with the experience when it comes to monitoring and logging and so on. And then I figured, okay, this is so much better, and this needs to exist. And it's about passion. It's about genuinely caring about providing better experiences for your both current and future customers. And also for us.
Jeremy: Yeah, totally agree. The passion piece of it is huge. And some of the projects that are coming out of there are amazing. We were talking about time quickly, how you carve out the time. Unfortunately, we are out of time. So we do need to wrap up, but I will say...
Rebecca: You made that go by so fast.
Jeremy: It did go by fast. I know. And the interesting thing was is that my dog didn't bark while I was speaking. So, that's good. I think we had had one little bit of Rebecca's... I don't know if it was your brother's dog or somebody was barking in the background, but for the most part...
Rebecca: Those four dogs are running around.
Jeremy: We were pretty good. And Tomasz, I didn't hear your wife's rabbits making any noise in the background.
Tomasz Łakomy:
So they are actually fairly quiet. So to give you some context, my wife and I, we have three bunnies. So their names are [Harry, Journey, and Luna 00:52:08]. As you can guess, those are from Harry Potter. I'm currently fighting the negotiation process to get a fourth one because I'm against, she's for, and the compromise is that we are probably going to get a fourth one.
Rebecca: Will it be Draco?
Tomasz Łakomy:
[crosstalk 00:52:25] probably.
Rebecca: Yes.
Tomasz Łakomy:
I'm renting an office as we speak. So I have to move somewhere. I'm not sure where.
Jeremy: But they have their own Instagram page.
Tomasz Łakomy:
They do. They do. They have more followers than my wife and I combined on Instagram.
Rebecca: So if we're going to find out more, if our listeners are going to find out more about where they can follow your bunnies, where would they do that?
Tomasz Łakomy:
Their Instagram page is Bunny Hogwarts, if I remember correctly.
Rebecca: Usually we ask about our guests. We usually, we're like, hey, where can listers find out more about you? And you're like, nah, we'll just go with the bunnies.
Tomasz Łakomy:
My long term retirement plan is basically for bunny's to retire me. They have to be the influencers.
Jeremy: I was saying we have a bunny guest at my house right now. My daughter has a rabbit and she is bunny sitting another rabbit and they're of the opposite sex and neither one of them are fixed. So they're in separate cages, but lot of excitement up in that room. So anyways, but besides bunnies and Hogwarts and all these other amazing things, let's talk about getting in touch with you. So if people want to find you on Twitter or check out Cloudash, things like that, how do they do that?
Tomasz Łakomy:
So you can find Cloudash or clouddash.dev. You can check what we are doing at Stedi at stedi.com. Make sure to subscribe to our changelog page because it gets updated quite rapidly. I'm overly active on Twitter. So unless you want to get half of your feed with my tweets, don't follow me. But if you want to, you can find me at, @tlakomy. So it's T-L-A-K-O-M-Y.
Jeremy: Yes.
Tomasz Łakomy:
I'm sure it's going to be in the show notes as well. Don't email me. I'm terrible at email. You can check out my stuff on tlakomy.com, but nowadays I will be probably blogging more on cloudash.dev/blog because it's our Cloudash blog. So if I have something to share, when it comes to serverless space, API gateway Lambdas, DynamoDB. All of that is probably to going to land there.
Jeremy: Awesome.
Rebecca: And Cloudash for those who are listening, only one D because I looked at Cloudash with two Ds at one point, and it was not the Cloudash I was looking for.
Tomasz Łakomy:
We bought a redirect, by the way so you can do the double D.
Rebecca: Ah, okay.
Jeremy: Ah, great. Good. All right.
Rebecca: Smart.
Jeremy: Well, we will put all of this stuff in the show notes and I just want to apologize collectively, or to all of the Polish people out there for my terrible pronunciations. But thank you so much, Tomasz. It was great having you.
Rebecca: Thanks so much, Tomasz.
Tomasz Łakomy:
Likewise. Thank you for having me.
