Screaming in the Cloud - How to Leverage AWS for Web Developers with Adam Elmore

Episode Date: August 23, 2022

About AdamAdam is an independent cloud consultant that helps startups build products on AWS. He’s also the host of AWS FM, a podcast with guests from around the AWS community, and an AWS DevTools Hero.Adam is passionate about open source and has made a handful of contributions to the AWS CDK over the years. In 2020 he created Ness, an open source CLI tool for deploying web sites and apps to AWS.Previously, Adam co-founded StatMuse—a Disney backed startup building technology that answers sports questions—and served as CTO for five years. He lives in Nixa, Missouri, with his wife and two children.Links Referenced:17 Ways to Run Containers On AWS: https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/Twitter: https://twitter.com/adamdotdevTwitch: https://www.twitch.tv/adamelmore

Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate.

Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other. Which one is up to you? Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business, production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io slash screaming

in the cloud. Observability, it's more than just hipster monitoring. access into your environment. They've also gone deep in depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense. Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while, I encounter someone in the wild that, well, I'll just be direct, makes me feel a little bit uneasy, almost like someone's walking over my grave. And I think I've finally figured out elements of what that is. It feels sometimes like I run into people, ideally not while driving, who are trying to occupy sort of the same space in the universe, and I never quite know how to

react to that. Today's guest is just one such person. Adam Elmore is an independent AWS consultant, has been all over the Twitters for a while, recently started live streaming, basically his every waking moment because he is just that interesting. Adam, thank you for suffering my slings and arrows and agreeing to chat with me today. I would say, first of all, you don't need to be worried about anyone walking over your grave. Honestly, I have big enterprise companies looking to put me in my grave, but that's a separate threat model. We're good on that for now. I got to set myself up here. I'm just going to laugh a lot.

And your editor or somebody is going to have to deal with that. Maybe the audience will see. Hey, I prefer that as opposed to talking to people who have absolutely no sense of humor of which they are aware. Awesome. I have a list of companies that they should apply for immediately. So when I say that we're trying to occupy elements of the same space in the universe, let me talk a little bit about what I mean by that. You are independent as a consultant, which is how I started this whole nonsense. And then I started gathering a company around me almost accidentally. You are an AWS

dev tools hero, whereas I am an AWS community villain, which is kind of the polar opposite slash anti-hero approach. And it's self-granted in my case. How did you stumble in to the universe of AWS? You just realized one day you were too happy and what can you do to make yourself miserable? And this was the answer or what? Yeah, I guess. So, I mean, I've been a software developer for 15 years, like my whole career. That's kind of what I've done. And at some point, I started a startup called StatMuse. And I was able, as sort of a co-founder there with venture backing, I was able to just kind of play with the cloud.

And we deployed everything on AWS. So that was like, I was there five years. It was sort of five years of running this. I would call it like a digital media studio. Like we built technology, but we did lots of experiments. So it felt like playing on AWS because we built kind of weird one-off, these digital experiences for various organizations. The Hall of Fame was one of them.

We did like a 3D talking bust of John Madden. So it was like all kinds of weird technology involved. But that was sort of five years of, I guess, spending venture money to play on AWS. And some of that was Google money. I guess I never thought about that. But Google was an investor in StatMuse. Yeah. So we sort of like, I ran that for five years and was able to learn just a lot of AWS stuff

that really excited me. I guess coming from normal web development stuff, it was exciting just how much leverage you have with AWS. So I sort of dove in pretty hard. And then, yeah, when I left StatMuse in 2019, I've just been, I guess, going even harder into that direction. I just really enjoy it. My first real exposure to AWS was at a company

where the CTO was a, I guess we'll call him an extraordinarily early cloud evangelist. I was there as a contractor, and he was super excited and would tweet nonsensical things like, I'm never going to rack a server ever again. And I was a grumpy sysadmin type. I came from the ops world, where anything that is new should be treated with disdain and suspicion. Because once you've been a sysadmin for 20 minutes, you've been there long enough to

see today's shiny new shit become tomorrow's legacy garbage that you're stuck supporting. So, oh, great. What now? I was very down on cloud in those days, and I encountered it with increasing frequencies. I stumbled my way through my career, and at the end of 2016, I wound up deciding to go out independent and fix, well, what problems am I good at fixing that I can articulate in a sentence? And well, I'd gotten surprised by AWS bills from time to time, fortunately with someone else's money, the best kind of mistake to make. And well, I know a few things. Let's get really into it. In time, I came to learn that cost and architecture are the same thing in cloud. And now I don't know how the hell to describe myself. Other people love to describe me, usually with varying forms of profanity, but here we are. It really turns into the idea of

forging something of your own path, and you've absolutely been doing that for at least the last three years as you become someone who's increasingly well-known and simultaneously harder to describe. Yeah, I would say if you figure it out, if you know how to describe me, I would love to know, because just coming up with the title for this episode, you needed like my title. I don't know what my title is. I'm also like we talked about independent. So nobody sort of gives me a title. I would love to just receive one. If you if you think of one, if anyone listening thinks of one, it's increasingly hard to sort of like even decide what I care most about. I know I need to like probably niche down. I feel like you've kind of niched into the billing stuff. I can't just be

like, I'm an AWS guy because AWS is so big. But yeah, I have no idea. Anyone who claims, oh, I'm an expert in AWS is lying or trying to sell something. I love that. It's really, I have some questions to establish that for you. Yeah. As far as naming what it is you do, first piece of advice, never, ever, ever listen to someone who works at AWS. Those people are awful at naming things, as evidenced by basically every service they've ever launched. But you are actually fairly close to being an AWS expert. You did a six-week speed run through every certification that they offer. And that is nothing short of astonishing.

How'd it come about? It's a unique intersection of skills that I think I have. And I'm not very self-aware. I don't know all my strengths and weaknesses, and I struggle to sort of nail those down. But I think one of my strengths is just ability to consume information, I guess, at a high volume. So I'm like an auditory learner. I can listen to content really fast and sort of retain enough. And then I think the other skill I have is just I'm good at tests. I've always said that, like going back to school, like high school, I always felt like I was really good at multiple choice tests. I don't know if that's a skill or some kind of innate talent, but I think those two things combined and then like eight years of building

on AWS and that sort of frames how I was able to take all that on. And I don't know that I really set out thinking I'd do it in six weeks. I took the first few and then did them pretty fast and thought, I wonder how quickly I could do all of them. And I just kind of, at that point, it became this sort of goal. I have to take on certain challenges occasionally that just sound fun for no reason other than they sound fun. And that was kind of the thing for those six weeks. I have two certifications, Cloud Practitioner and the SysOps Administrator Associate. Those were interesting.

You took the new one, right? The new SysOps with the labs and stuff. I'd love to hear about that. I did back when it was in beta. That was a really interesting experience. And I'll definitely get to that. But I wound up, for example, getting a question wrong on the Cloud Practitioner exam four years ago or so,

and it was, how long does it take to restore an RDS instance from backup? And I gave the honest answer instead of the by-the-book correct answer. And that's part of the problem, is that I've been doing this stuff too long, and I know how these things break and what the real world looks like. Certifications are also very much a snapshot at a point in time. Because I write the last week in AWS newsletter, I'm generally up to the minute on what has changed and things that were not possible yesterday suddenly are possible today. So I need to know, when was this certification launched? Oh, it was in early 2021.

Yeah, I need to be a lot more specific. Which week? And then people look at me very strangely, and here we are. The SysOps administrator certification was interesting because this is the first one, to my knowledge, where they started doing a live lab as a component of this. And I don't think it's a breach of the NDA to point out that one of the exams was,

great, configure CloudWatch out of the box to do this thing that it's supposed to do out of the box. And I've got to say that making the service do what it's supposed to do with no caveats is probably the sickest shade I've ever seen anyone throw at AWS. Like, configuring the service is so bad that it is going to be our test to prove you know what you're doing. That is amazing. Yeah, I don't have any shade to throw. I'm not as good with the ability to come off witty and kind while still criticizing things. So I generally just try not to because I'm bad at it. It's why I generally advise people don't try. It's in seriousness. It's not that people can't be clever. It's that the failure mode of clever is asshole. And I'm not a big fan of making people

feel worse based upon the things that I say and do. It's occasionally I wind up getting yelled at by Amazonians saying that the people who built a service didn't feel great about something I said. And my instinctive immediate reaction is, oh shit, that wasn't my intention. How did I screw this up? Given a bit of time, I realized, well, hang on a minute, because I'm not, they're not my target audience. I'm trying to explain this to other customers. And on some level, if you're going to charge tens of millions of dollars a month for a service or more, maybe make a better one, not for nothing. So I see both sides of it. I'm not intentionally trying to cause pain, but I'm also not out here insulting people individually. Sometimes people

make bad decisions, sometimes individually, sometimes in a group. And then we have a service name we have to live with. And all right, I guess I'm going to make fun of that forever. It's fun. It keeps it engaging for me because otherwise it's boring. No, I hear you. No, and somebody's got to do it. I'm glad you do it and do it so well because, I mean, you got to keep them honest. Like, that's a thing. Keep AWS in check. Something that I went through somewhat recently was a bit of an awakening. I have no problem revisiting old opinions and discovering that, huh, I no longer agree with it. It's time to evolve that opinion. The CDK, specifically, was one of those, where I looked at it and thought, this thing looks a little hokey.

So I started using it in Python, and sure enough, the experience was garbage. So cool. The CDK is a piece of crap. There we go. My job is easy. I was convinced to take a second look at it via TypeScript, a language I do not know and did not have any previous real experience with. So I spent a few days just powering through it, and now I'm a convert. I think it's amazing. It is my default go-to for building AWS infrastructure. And all it took was a little bit of poking and prodding to get me to change my mind on that. You've taken it to another level, and you've started actively contributing to the AWS CDK. What was your journey with that honestly remarkable piece of software? Yeah, so I started contributing to the CDK when I was actually doing a lot of Python

development. So I worked with a company that was doing, there's a Python shop. So I actually, the first thing I contributed was a Python function construct, which is sort of the equivalent of the Node.js function construct, which like you can just basically point at a TypeScript file and it transpiles it and bundles it and does all of that, right? So it makes it easy to deploy TypeScript as a Lambda function. I mean, it ends up being a JavaScript Lambda function. But anyway, that was the Python function construct.

And then I sort of got really into it. So I got pretty hooked on using the CDK in every place that I could. I'm a huge fan, and I do primarily write in TypeScript these days. I love being able to write TypeScript front end and back. So build a lot of like Next.js front ends and then I'm building back ends with CDK TypeScript. Yeah, I've had like a lot of conversations about CDK. I think there's definitely a group that's sort of against the CDK if you're thinking in terms of like beginners.

And I do see where for people who aren't as familiar with AWS or maybe this is their entry point into cloud development, it does a lot of things that maybe you're not aware of that you're now kind of responsible for. So it's deploying,

like it makes it really easy to write like three lines of TypeScript that stand up an entire VPC with all this configuration and manage NAT gateways and everything else. And you may not be aware of all the things you just stood up. So CloudFormation maybe is a little more, sort of gives you that better visibility

into what you're creating. So I've definitely seen that pushback, but I think for people who really like have built a lot of applications on AWS, I think the CDK is just such a time saver. I mean, I spend so much less time building the same things in the CDK versus CloudFormation. I'm a big fan. For me, I've learned enough about JavaScript to be dangerous, and it seems like TypeScript is more or less trying to automate a bunch of people's jobs away,

which is basically, from what I can tell, their job is to go on the internet and complain about someone's JavaScript. So, great, that's really all it does, is it complains, oh, this is ambiguous, you should be more specific about it. And great, awesome. I still haven't gotten into scenarios where I've been caught out by typing issues, and very often I find that it just feels like sheer bloody-mindedness, but I smile, nod, bend the knee, and life goes on. When you've got a sheer bloody mindedness but I smile nod bend the

knee and life goes on when you've got a project that's like I don't know a few months old or better a few years old and you and you need to do like major refactoring that's when TypeScript really saves you just a ton of time like when you can make a change in a type or in actual implementation stuff and then see the ripple effects and then sort of go around the code base and fix those things it's just a lot easier than doing it in javascript and discovering stuff at runtime so i'm i'm a big typescript fan i don't know where it's all headed i know there's people that are not fans of like transpiling your lambda functions for instance like why not just ship good javascript and i get that case too. Yeah. But I've definitely, I felt the productivity

boost, I guess, if that's a thing from TypeScript. For me, I'm still at a point where I'm learning the edges of where things start and where they stop. But one of the big changes I made was that I finally, after 15 years, gave up my beloved Vim as my editor for this and started using VS Code. Because the reasons that I originally went with VI were understandable when you realized what I was. I'm always going to be remoting into network gear or random unmaintained Unix boxes. VI is going to be everywhere on everything, and that's fine.

Yeah, I don't do that anymore. And increasingly, I find that everything I'm writing is local. It is not something that is tied to a remote thing that I need to log in and edit by hand. At that point, we are in disaster area. And suddenly it's nice having things like tab completion where it just winds up completing the rest of the variable name or once you enable Copilot and absolutely not CodeWhisperer yet,

it winds up you tab complete your entire application. Why not? It's just outsourcing it to um stack overflow without that pesky copy and paste step yeah i don't know how in the weeds you want to get on your i don't know in terms of technical stuff but copilot both blows me away there are days where it auto completes something that i just i can't fathom how it pulled in not just like the patterns that it found, obviously, in training, but like the context in the file I'm working and sort of figured out what I was trying to do.

Sometimes it blows me away. A lot of times, though, it frustrates me because of TypeScript. Like I'm used to TypeScript and types saving me from typing a lot. Like I can tab complete stuff because I have good types to find, right? Or it's just inferred from the libraries I'm using. It's tough, though, when GitHub is fighting with TypeScript and VS right? Or it's just inferred from the libraries I'm using. It's tough though when GitHub is fighting with TypeScript and VS Code. But it's funny that you came from Vim and you now live in VS Code. I really am trying to move from VS Code

to like the Vim world, mostly because of Twitch streamers that blow my mind with what they can do in Vim and how fast they can move. I do every time I move my hand like over to the arrow keys, I feel a little sad and I wish I just did Vim and how fast they can move. I do every time I move my hand like over to the arrow keys, I feel a little sad and I wish I just did Vim. This episode is sponsored in part

by our friends at Lambda Cloud. They offer GPU instances with pricing that's not only SCADs better than other cloud providers, but is also accessible and transparent. Also, check this out. They get a lot more granular in terms of what's available.

AWS offers NVIDIA A100 GPUs on instances that only come in one size and cost $32 an hour. Lambda offers instances that offer those GPUs as single card instances for $1.10 an hour. That's 73% less per GPU. That doesn't require any long-term commitments or predicting what your usage is going to look like years down the road. So if you need GPUs, check out Lambda. In beta, they're offering 10 terabytes of free storage, and this is key, data ingress and egress are both free. Check them out at lambdalabs.com slash cloud. That's L-A-M-B-D-A-L-A-B-S dot com slash cloud. There are people who have just made it into an entire lifestyle on some level.

And I'm fair to middling. I've known people who are dark wizards at it. In practice, I found that my productivity was never constrained by how quickly I can type. It's one of those things where I actually want to stop and my brain catch up sometimes, believe it or not, for those who follow me on Twitter. It's the idea of wanting to make sure that I am able to intelligently and rationally wrap my head around what it is I'm doing. And okay, just type out a whole bunch of boilerplate is like the least valuable use of anything.

And that is where I find things like Copilot working on super well. Where if I'm doing CloudFormation, for example, the fact that it tab completes all the necessary attributes and I can go back and change them or whatnot, that's an enormous time saver. Same story with the CDK, although with some constructs,

I just didn't quite understand which ones get certain values to it. And I really like the idea behind it. I think this is in some ways the future of IDEs to a point. Oh, for sure. I think like the case you called out with CloudFormation,

you don't have really type ahead in VS Code. At least I'm not using anything. Maybe there are extensions that give you that in VS Code. But to have Copilot fill in required props on a CloudFormation template, that's a lifesaver. Because I just, every time I write CloudFormation,

I've just got the docs up, and I'm copying stuff I've done before or whatever. To save that time, it's huge. But CodeWhisperer, not so much. Is it not, I guess, up to snuff? I haven't seen it or played with it at all. It's still very early days, and it hasn't had exposure outside of Amazonian codebases,

to my understanding. So it's like, learn to code like an Amazonian, and you can fill in your own joke here on that one. I imagine it's like, isn't that primarily a Java shop, for one? And all right. Yeah, it turns out most of my code doesn't need to operate the way that theirs does. I didn't know that they were training it just internally. Like, I'm assuming Copilot is trained on like Stack Overflow or something, right? Or just all of GitHub, I guess. And GitHub and a bunch of other things, and people are yelling at them for it, and I haven't been tracking that.

But honestly, the CodeWhisperer announcement taught me things about Copilot, which is weird, which tells me that none of these companies are great at explaining this. I can just write a comment in this of, add an S3 bucket, and then Copilot will tab complete the entirety of adding an S3 bucket, usually even secure, which is awesome. They also fixed the early Copilot teething problems of tab completing people's AWS API credentials. So, you know, yeah, they fixed a lot of that, thankfully. But it's still one of those neat things that

you can just basically start... It gets a little bit closer to describe what you want the application to do, and then it'll automatically write it for you on the backend. Sure, sometimes it makes naive decisions that do not bear out, but again, still early days.

I'm optimistic. Yeah, that reminds me of like the, I mean, the serverless cloud, so serverless framework folks, like what they're doing, where they're sort of inferring your infrastructure based on, you just write an app, and it sort of creates the infrastructure as code for you,

or just sort of infers it all from your code. So if you start using a bucket, it'll create a bucket for that. That definitely seems to be a movement as well, where just do less as a developer seems to be the theme. Yeah, just move up the stack. We see this time and time again. I use this analogy from time to time again. I mean, look at the, I use this analogy from time to time

from the sysadmin world. But in the late 90s, if you wanted to build a web server, you needed a spare week and an intimate knowledge of GCC's compiler flags. In time, it became, oh, great, now it's RPM install,

then yum install, then ensure present with something like Puppet, and then Docker has it, and now it's just a checkbox on the S3 page and you're running a static site. Things don't get harder with time, and I don't think that as a developer, your time is best spent writing by hand the proper syntax for a for loop or whatnot. It's not the differentiated value. Talk to me instead about what you want that thing to do. That was my big problem with Lambda when it first came out, and I

spent two weeks writing my first Lambda function because I'm bad at programming, where I had to learn the exact format of it expected for input and output. And now any Lambda function I write takes me a couple minutes to write because I'm also bad at programming and don't know what tests are.

Tests are overrated. I don't spend a lot of time writing tests. I mean, I do a lot of stuff alone and I do a lot of stuff for myself so in those contexts I'm not writing tests if I'm being honest I stream now and everyone on stream is constantly asking where are the tests like there are no tests

I'm sorry it used to be though that you had to be a little sneakier to have other people do work for you Copilot makes it easier and presumably CodeWhisperer will too used to be that if AWS launched a new service and I didn't know how to configure it, all I would do is restrict a role down to only being able to work with that service, attach that to a user, and then just drop the credentials on Twitter or GitHub. And I waited 20 minutes and I came back. And sure enough,

someone had configured it and was already up and mining Bitcoin. So turn that off, take what they built and off the production with it. Problem solved. Oh, and rotate those credentials unless you enjoy pain. Problem solved. The end. And I don't know if it's a best practice, but it sure was effective. Yeah, that would do it.

There's like scanners now, right? Like that are just scanning GitHub public repos for any credentials that are leaked like that. And they're available within seconds. You can literally push a public repo with credentials, and it is being used within minutes. It's nuts. GitHub has some automatic back-channel thing, I believe.

I haven't done an experiment lately, but I believe that AWS will intentionally shoot down the credential as soon as it gets reported, which is kind of amazing. I really should do some more experiments with it just to see how disastrous this can get. Yeah, no, I'd be curious. Please let me know. I guess you'll tweet about it. Can I borrow your account for a few minutes? Yeah, it's fun. Now, the secret to my 17 ways to run containers on AWS is in almost every case,

those containers can be crypto miners. So it's not just about having too many services do the same thing. It's the attack surface continues to grow and expand in the fullness of time. I'm not saying this is right or wrong. It is what it is, but it's also something that I think people have an understated appreciation for. Let's change topic a little bit. Something you've been doing lately and talking about is the idea of building a course on AWS. You're clearly capable of doing the engineering work. That's not in question. You've been a successful consultant for years, which tells me you also know how to deliver software that meets customer requirements as opposed to, well, the

spec was shitty, but I wrote it anyway, because you don't last long as a consultant if you enjoy being able to afford to eat, if that's the direction you go in. Now you're drifting toward becoming a teacher. Tell me about that. First, what makes you think that's something you're good at? So I don't know. I don't know that I'm good at it. And I guess I'll find out. I've been streaming like on Twitch, just my work days and that's been early signs that I'm I think I'm okay at it at least. I think it's very different obviously like a self-paced course is gonna be very different from streaming for hours so there's a lot more editing and thoughtfulness involved but I do think like I've always wanted to teach so even before I got into technology I was pretty late into technology it was after high school. Like back in high school, I always thought I wanted to be a professor.

I just enjoyed, I guess, the idea of presenting ideas in ways that people understood. And I live in an area, so I live in the Ozarks. It's not a very tech literate area. It became like this thing where I felt like I could really explain technology to people who are non-technical. And that's not necessarily what my course, what I'm aiming to do. I'm trying to teach web developers how to leverage AWS and sort of get out of the maybe front end only or maybe traditional web frameworks. Like they've only worked with stuff that they deployed

or Heroku or whatever, trying to teach that crowd how to leverage AWS and all these wonderful primitives that we have. So that's not exactly the same thing, but that's sort of like, I feel like I do have the ability to translate technology to non-technical folks. And then I guess like for me at this stage of my career, you know, I've done a lot of work for a company, for startups, for individual clients. And it feels very like, I just always feel like I'm going in a hole. Like I feel like I'm doing this little thing and I'm serving this one customer. But the idea of being able to,

I guess, serve more people and sort of spread my reach, the idea of creating something that I can share with a lot of developers who would maybe benefit from it, it just feels better, I guess. I don't know exactly all the reasons why that feels better. But like, at the end of the day, my consulting kind of feels like this thing I do because I just need money. And now that I need money less and less, I just feel like I'd rather do stuff that I actually am excited about.

I'm actually really excited about the outcomes for creating a course where, you know, I think I can maybe my style of teaching or something could resonate with some group of people. Yeah, so that's it. It's AWS for web devs. The thought is that I'm going to create courses after this. I hope to move into more education, less consulting. That's where I'm at. I would say you're probably selling yourself fairly short.

I've seen a lot of the content you've put out over the years, and I learn a lot from it every time. I think that there are some folks who put courses out where, one, they don't have the baseline knowledge around what it is that they're teaching. It just feels like a grift. And another failure mode is that people know how to do the thing, but they have no idea how to teach it to someone who isn't them. And there's nothing inherently wrong with not knowing how to teach. It is its own distinct skill. The problem is when you don't recognize that about yourself and in turn wind up having some somewhat significant challenges. Yeah. No, I know that one of the struggles is I work with pretty obscure technologies on AWS. I'm not obscure, but like I have a very specific

way I build APIs on AWS. And I don't know that that's generally, if you're taking a bunch of web developers and trying to move them into AWS, it's probably not the stack that I use. So that is part of it. But that's also kind of to my benefit, I guess it works for me a little bit in that I'm less familiar with maybe the more beginner friendly way to enter into AWS. It's been years. So I think I can kind of come at it a little fresh and that'll help me produce a course that maybe meets them where they're at better. Yeah. The grifting thing, I'm definitely sensitive to just this idea of putting out a course. It was hard for me to really go out there and say I was making a course even on Twitter because I just feel like there's like some stereotype. I don't know. There's an association with that for me, at least

for my perception of course creation. But I know that there are people who've done it right and do it for the right reasons. And I think to the extent that I could hit that, you know, both those things, do it right and do it for the right reasons, then it's exciting to me. And if I can't and it, you know, I turn out not good at teaching, then I'll move on and do more consulting, I guess, or streaming on Twitch. You are very clearly self-aware enough that if you put something out and it isn't effective, I have zero doubt that you won't just stop selling it. You'll take it down and reach out to people. Because you, more so than most, seem very cognizant of the fact that a poor experience learning something does not in most people's case translate to oh my teacher is shitty instead it's oh i'm bad at this and i'm not smart enough to figure it out but

that's that's still the problem i run into with bad developer experience on a bunch of things that get launched if i have a bad time i assume it's oh'm stupid. I wish someone had told me. And first, they did. Secondly, it's the sense that, no, it's just not being very clearly explained. And the folks who wrote the documentation are talking about it are too close to what they've built to understand what it's like to look at this thing from fresh eyes. They're doing a poor job of setting the stage to explain the value it brings and in what scenario you should be using this. It's a long process. I want to launch the course in the fall, but in the process of building out the course, I'm really going to be doing workshops and individual, like I just have a lot of friends

that are web developers and I'm going to be kind of getting on with them and teaching them this material and just trying to see what resonates. I'm going to a lot of trouble, I guess, to make sure I'm not just putting out a thing just to say I made a course. I don't actually want to say I made a course. So if I'm going to do it, it's like most things I do, I really kind of throw myself into.

And I know if I spend enough energy and effort, I think I can make something that at least helps some people. I guess we'll see. I look forward to it. Any idea as far as rough timeline goes? Yeah, I hope to launch it in the fall. But if it takes longer, I don't know.

I've heard people say to do a course right, you should spend a year on it. And maybe that's what I do. No, I love that answer. It's great. You're saying, I want to launch in the fall, which is sufficiently vague. And if that winds up not being vague enough, you could always qualify with, well, I didn't say what year. So it's always going to be the fall somewhere. I just know when someone says you should spend a year,

I just do things very hard. I really throw a lot of time and I just obsess. I'm very obsessive. And when I do something, it's hard for me to imagine doing any one thing for a year because I burn myself out. I obsess very hard for usually three months. It's usually like a quarter. And then I fall off the face of the earth for three months and I basically mope around the house and I'm just too tired to do anything else.

So I think right now I'm streaming and that's kind of been my obsession. I'm three weeks in, so we got a few more months and we'll see how I maintain it. Well, I look forward to seeing how it comes out. You'll have to come back and let us know when it's ready for launch yeah that sounds great i really want to thank you for being so generous with your time and taking me through what you're up to if people want to learn more what's the best place for them to find you yeah

i think twitter i mean i mostly hang out on Twitter and these days Twitch. So Twitter, my handle, I guess you'll put it like in the thing, description or something. It's like the phonetic- Oh, we will absolutely toss it into the show notes where useful content goes to linger. It's like A-E-D-U-H-M. It's like a,

it's the phonetic way of saying Adam, I guess. And then on Twitch, I'm Adam Elmore. So those are the two places I spend most of my time. And off to the show notes, it goes. Thank you so much for being so generous with your time. I really appreciate it. Thank you so much for having me, Corey. I really appreciate it. Adam Elmore, independent AWS consultant. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast,

please leave a five-star review on your podcast platform of choice, along with an insulting comment that attempts to teach us exactly what we got wrong, but fails utterly because you're terrible at teaching things. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying.

The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.