Podcasts about Apis

The advent of the cloud introduced a new form of technical debt in which organizations can lose track of what infrastructure they have and how it relates to the business.  While the cloud's native APIs offer some transparency into your infrastructure, these offerings are often described as necessary but not sufficient.  When companies have a The post CloudGraph with Tyson Kunovsky appeared first on Software Engineering Daily.

Our expert host, Kate Moody, is joined by some great guests to delve into Egypt's fintech scene. While we in the West may associate Egypt with its grand history – the truth is that the North African country is currently looking extremely youthful. With this young population comes new expectations on banking and financial services – with many from the outside of the country also looking at this hugely profitable market as a place to expand into. So in this episode, we're asking: How does the market look today? What challenges are still to be overcome? And what does the future hold for Egypt? This week's guests include: Momtaz Moussa, Co-Founder & CEO, Lucky Eslam Darwish, General Partner, Nclude By Global Ventures This episode is sponsored by Alto IRA Did you know the majority of people are investing in cryptocurrency through a taxable account, when they could be using an IRA and avoiding or deferring the taxes? With an Alto CryptoIRA, you can invest in crypto without tax headaches. Create a free account in minutes. Choose from over 150 coins, and invest with as little as $10. No setup charges and no account fees. To open an Alto CryptoIRA with as little as $10, just go to www.altoira.com/insider This episode is sponsored by TrueLayer Let's face it, cards were not designed for online. Payments can take days to settle, hurting customer loyalty. While high fraud, clunky checkouts and expensive fees mean millions in missed revenue. At TrueLayer, we've made instant payments available for businesses across Europe and the UK. So you can cut costs, fight fraud and get money moving fast. To learn more visit: www.TrueLayer.com/payments Fintech Insider by 11:FS is a podcast dedicated to all things fintech, banking, technology and financial services. It's hosted by a rotation of 11:FS experts including David M. Brear, Simon Taylor, Jason Bates and Gwera Kiwana, as well as a range of brilliant guests. We cover the latest global news, bring you interviews from industry experts or take a deep dive into subject matters such as APIs, AI or digital banking. If you enjoyed this episode, don't forget to subscribe and please leave a review Follow us on Twitter: @fintechinsiders where you can ask the hosts questions, or email podcasts@11fs.com! Special Guests: Eslam Darwish and Momtaz Moussa.

This week on the API Intersection podcast, we chatted with Balan Subramanian, Partner Director of Product for Azure App Platform Services at Microsoft. At Microsoft, he leads the product team that works on the Azure app platform. This includes microservices frameworks such as Dapr, cloud services such as Azure API platform, Azure Logic Apps for integration, Azure Cache for Redis, Azure Spring Apps and a few other services. Additionally, Balan is responsible for ecosystem enablement for Azure developers–meaning he works with some of the well-known names in the developer community such as Elastic, Confluent, Redis, Nginx etc. and enables them to bring their SaaS to developers with Azure-native integrations.Balan provided a few insights on how Microsoft works to create an enticing partner environment, how they use the design-first approach internally, and how they help customers think of their APIs as products (even when they're not monetized!). Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here: stoplight.io/question/

Just how much of your data is being processed by AI systems? And to what end? Most of us don't have a clue what's happening to the data we share with businesses on a day to day basis. We don't even know what data is being captured in the first place. Throw AI assistants into the mix and we're even more lost than we were. With algorithms making decisions and AI assistants mediating our interactions, understanding what data is being captured, how it's stored and used is crucial if we're ever going to fully trust AI services and the companies that run them. Yet most companies are way behind here. Most have big blind spots. Joining us to shed light on this and reveal these blind spots is Patricia Thaine, CEO, Private AI.**Presented by Deepgram**Deepgram is a Speech Company whose goal is to have every voice heard and understood. We have revolutionized speech-to-text (STT) with an End-to-End Deep Learning platform. This AI architectural advantage means you don't have to compromise on speed, accuracy, scalability, or cost to build the next big idea in voice. Our easy-to-use SDKs and APIs allow developers to quickly test and embed our STT solution into their voice products. For more information, visit: https://deepgram.com/vuxworld See acast.com/privacy for privacy and opt-out information.

Our expert host, Gwera Kiwana, is joined by Mauricio Magaldi, Global Strategy Director for Crypto at 11:FS, to talk about something exciting we've been cooking up here at 11:FS. Our latest report - How web3 is shaping the future of finance - is out now! There's so much hype floating around about web3, but also so much opportunity. So we decided to do an explainer that unpacks what web3 actually means, how it'll impact financial services, the risks and the opportunities. Time to take a deep dive. All this and much much more on today's bonus episode! Fintech Insider by 11:FS is a podcast dedicated to all things fintech, banking, technology and financial services. It's hosted by a rotation of 11:FS experts including David M. Brear, Simon Taylor, Jason Bates and Gwera Kiwana, as well as a range of brilliant guests. We cover the latest global news, bring you interviews from industry experts or take a deep dive into subject matters such as APIs, AI or digital banking. If you enjoyed this episode, don't forget to subscribe and please leave a review Follow us on Twitter: @fintechinsiders where you can ask the hosts questions, or email podcasts@11fs.com! Special Guest: Mauricio Magaldi.

Jordan Wright loves building great companies. He's co-founded and led several startups from inception through to successful exits. Currently, Jordan is Co-Founder and CEO at Atomic and the Vice-Chairman of the Board of Directors of Solera National Bank. Atomic is the market-leading provider for payroll connectivity, trusted by 12 of the leading fintech brands, including digital-first neobanks, alternative lenders, and digital brokerages such as Coinbase, Dave, and Propel, among others.Prior to starting Atomic, Jordan was the Co-Founder and Chief Executive Officer at Unbill, a FinTech payment company he sold to online banking software provider Q2 (QTWO). Previously, he helped start a cybersecurity company, NextPage, which was acquired by Proofpoint (PFPT) as well as Mobile Butler, acquired by Amenify.As both Vice-Chairman of Solera National Bank and Co-Founder and CEO of Atomic, Jordan bridges the gap between traditional banking and technology-enabled financial services. At Atomic, he works with nearly all of the leading fintech companies, including digital-first neobanks, alternative lenders and digital brokerages, and traditional banks, community banks, and credit unions. He has led Atomic to simplify complicated payroll integrations to cover 75% of the U.S. workforce with a combined reach of 125 million workers. Atomic's payroll APIs are the leading way for consumers to securely connect their payroll accounts to a third-party banking app to set up or switch direct deposit payments, and access financial data for income (VOI) and employment (VOE) verifications, and setup or update W-4 tax withholdings. Put simply, Atomic makes banking easier for the customer and the bank. Atomic is a member of the Financial Health Network, the Innovative Payments Association, and the Visa North America Fintech Partner Connect Program, among others.Jordan earned his B.S. from Brigham Young University in 2012. In his spare time, he enjoys fishing with his family.Connect with him on LinkedIn & Twitter

AMRO Bank is the market-leading bank in The Netherlands, and Jeroen Das is leading the conversational automation charge. We chat with Jeroen about use cases, channels, business drivers and outcomes, as well as tips and tricks for scaling your conversational AI from nothing to over 1.5 million conversations per year.**Presented by Deepgram**Deepgram is a Speech Company whose goal is to have every voice heard and understood. We have revolutionized speech-to-text (STT) with an End-to-End Deep Learning platform. This AI architectural advantage means you don't have to compromise on speed, accuracy, scalability, or cost to build the next big idea in voice. Our easy-to-use SDKs and APIs allow developers to quickly test and embed our STT solution into their voice products. For more information, visit: https://deepgram.com/vuxworld See acast.com/privacy for privacy and opt-out information.

What was it like to be Shoreline for Google IO this year? Android 13 Beta 2 released during IO! Here's everything new in Android 13 Beta 2. Migrate an app that uses unsupported back navigation APIs to platform APIs. Android Auto is Getting a Much-Needed Makeover. Google TV is Getting a Neat Picture-in-Picture Mode. Google Adopts 10-Step Skin Tone Scale to Teach Diversity to Its AI. Google unveils new Results About You page, ecosystem-wide Google Account Safety Status. Google Pixel 6a Coming This Summer, 7/7 Pro Likely to Follow This Fall. Google unveils the Pixel Buds Pro with a custom audio chip, future Spatial Audio, and ANC. Google's Pixel Watch is Real, and It's Coming Later This Year. The Google Pixel Watch needs a good chip, but which? Google gives us our first glimpse of the Pixel 7. The Pixel Tablet is coming in 2023. Google Glass's successor teased at I/O. Google Search's futuristic new tools will be able to identify and filter products in the real world. Google Translate adds 24 new languages, including its first indigenous languages of the Americas. Google is updating and optimizing over 20 of its Android apps for tablets. @RonAmadeo: Google's "20+ tablet apps" graphic contains 18 screenshots. It's basically the entire future tablet app lineup. Google Wallet wants to replace your physical wallet (and the old Google Pay app). Google Chrome is getting built-in virtual credit cards. Google Messages will get end-to-end encryption for RCS group chats 'later this year' in beta. RCS has over 500 million active users as Google digs at Apple yet again for ignoring the standard. Google Maps bringing a new 'immersive view' of select cities, Live View's AR for other apps. TL;DR? Google Docs to Include Auto-Generated Summaries. Google is Beta Testing its AI Future. Google I/O 2022: What's new in Android Development Tools. Everything new for developers at Google I/O: Android Studio, Jetpack Compose, and more. Announcing Compose for Wear OS Beta! Android Studio Electric Eel Canary brings Live Edit to the Compose Preview. Live Edit. Read our show notes here: https://bit.ly/3Pv5O2i Hosts: Jason Howell, Ron Richards, Huyen Tue Dao, and Florence Ion Guest: Michael Wolfson Subscribe to All About Android at https://twit.tv/shows/all-about-android. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsor: drinktrade.com/aaa

What was it like to be Shoreline for Google IO this year? Android 13 Beta 2 released during IO! Here's everything new in Android 13 Beta 2. Migrate an app that uses unsupported back navigation APIs to platform APIs. Android Auto is Getting a Much-Needed Makeover. Google TV is Getting a Neat Picture-in-Picture Mode. Google Adopts 10-Step Skin Tone Scale to Teach Diversity to Its AI. Google unveils new Results About You page, ecosystem-wide Google Account Safety Status. Google Pixel 6a Coming This Summer, 7/7 Pro Likely to Follow This Fall. Google unveils the Pixel Buds Pro with a custom audio chip, future Spatial Audio, and ANC. Google's Pixel Watch is Real, and It's Coming Later This Year. The Google Pixel Watch needs a good chip, but which? Google gives us our first glimpse of the Pixel 7. The Pixel Tablet is coming in 2023. Google Glass's successor teased at I/O. Google Search's futuristic new tools will be able to identify and filter products in the real world. Google Translate adds 24 new languages, including its first indigenous languages of the Americas. Google is updating and optimizing over 20 of its Android apps for tablets. @RonAmadeo: Google's "20+ tablet apps" graphic contains 18 screenshots. It's basically the entire future tablet app lineup. Google Wallet wants to replace your physical wallet (and the old Google Pay app). Google Chrome is getting built-in virtual credit cards. Google Messages will get end-to-end encryption for RCS group chats 'later this year' in beta. RCS has over 500 million active users as Google digs at Apple yet again for ignoring the standard. Google Maps bringing a new 'immersive view' of select cities, Live View's AR for other apps. TL;DR? Google Docs to Include Auto-Generated Summaries. Google is Beta Testing its AI Future. Google I/O 2022: What's new in Android Development Tools. Everything new for developers at Google I/O: Android Studio, Jetpack Compose, and more. Announcing Compose for Wear OS Beta! Android Studio Electric Eel Canary brings Live Edit to the Compose Preview. Live Edit. Read our show notes here: https://bit.ly/3Pv5O2i Hosts: Jason Howell, Ron Richards, Huyen Tue Dao, and Florence Ion Guest: Michael Wolfson Subscribe to All About Android at https://twit.tv/shows/all-about-android. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsor: drinktrade.com/aaa

What was it like to be Shoreline for Google IO this year? Android 13 Beta 2 released during IO! Here's everything new in Android 13 Beta 2. Migrate an app that uses unsupported back navigation APIs to platform APIs. Android Auto is Getting a Much-Needed Makeover. Google TV is Getting a Neat Picture-in-Picture Mode. Google Adopts 10-Step Skin Tone Scale to Teach Diversity to Its AI. Google unveils new Results About You page, ecosystem-wide Google Account Safety Status. Google Pixel 6a Coming This Summer, 7/7 Pro Likely to Follow This Fall. Google unveils the Pixel Buds Pro with a custom audio chip, future Spatial Audio, and ANC. Google's Pixel Watch is Real, and It's Coming Later This Year. The Google Pixel Watch needs a good chip, but which? Google gives us our first glimpse of the Pixel 7. The Pixel Tablet is coming in 2023. Google Glass's successor teased at I/O. Google Search's futuristic new tools will be able to identify and filter products in the real world. Google Translate adds 24 new languages, including its first indigenous languages of the Americas. Google is updating and optimizing over 20 of its Android apps for tablets. @RonAmadeo: Google's "20+ tablet apps" graphic contains 18 screenshots. It's basically the entire future tablet app lineup. Google Wallet wants to replace your physical wallet (and the old Google Pay app). Google Chrome is getting built-in virtual credit cards. Google Messages will get end-to-end encryption for RCS group chats 'later this year' in beta. RCS has over 500 million active users as Google digs at Apple yet again for ignoring the standard. Google Maps bringing a new 'immersive view' of select cities, Live View's AR for other apps. TL;DR? Google Docs to Include Auto-Generated Summaries. Google is Beta Testing its AI Future. Google I/O 2022: What's new in Android Development Tools. Everything new for developers at Google I/O: Android Studio, Jetpack Compose, and more. Announcing Compose for Wear OS Beta! Android Studio Electric Eel Canary brings Live Edit to the Compose Preview. Live Edit. Read our show notes here: https://bit.ly/3Pv5O2i Hosts: Jason Howell, Ron Richards, Huyen Tue Dao, and Florence Ion Guest: Michael Wolfson Subscribe to All About Android at https://twit.tv/shows/all-about-android. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsor: drinktrade.com/aaa

What was it like to be Shoreline for Google IO this year? Android 13 Beta 2 released during IO! Here's everything new in Android 13 Beta 2. Migrate an app that uses unsupported back navigation APIs to platform APIs. Android Auto is Getting a Much-Needed Makeover. Google TV is Getting a Neat Picture-in-Picture Mode. Google Adopts 10-Step Skin Tone Scale to Teach Diversity to Its AI. Google unveils new Results About You page, ecosystem-wide Google Account Safety Status. Google Pixel 6a Coming This Summer, 7/7 Pro Likely to Follow This Fall. Google unveils the Pixel Buds Pro with a custom audio chip, future Spatial Audio, and ANC. Google's Pixel Watch is Real, and It's Coming Later This Year. The Google Pixel Watch needs a good chip, but which? Google gives us our first glimpse of the Pixel 7. The Pixel Tablet is coming in 2023. Google Glass's successor teased at I/O. Google Search's futuristic new tools will be able to identify and filter products in the real world. Google Translate adds 24 new languages, including its first indigenous languages of the Americas. Google is updating and optimizing over 20 of its Android apps for tablets. @RonAmadeo: Google's "20+ tablet apps" graphic contains 18 screenshots. It's basically the entire future tablet app lineup. Google Wallet wants to replace your physical wallet (and the old Google Pay app). Google Chrome is getting built-in virtual credit cards. Google Messages will get end-to-end encryption for RCS group chats 'later this year' in beta. RCS has over 500 million active users as Google digs at Apple yet again for ignoring the standard. Google Maps bringing a new 'immersive view' of select cities, Live View's AR for other apps. TL;DR? Google Docs to Include Auto-Generated Summaries. Google is Beta Testing its AI Future. Google I/O 2022: What's new in Android Development Tools. Everything new for developers at Google I/O: Android Studio, Jetpack Compose, and more. Announcing Compose for Wear OS Beta! Android Studio Electric Eel Canary brings Live Edit to the Compose Preview. Live Edit. Read our show notes here: https://bit.ly/3Pv5O2i Hosts: Jason Howell, Ron Richards, Huyen Tue Dao, and Florence Ion Guest: Michael Wolfson Subscribe to All About Android at https://twit.tv/shows/all-about-android. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsor: drinktrade.com/aaa

Chewing glass is what Solana developers do. Introducing the fifth episode in a new series on the Solana Podcast, Chewing Glass. Chase Barker (Developer Relations Lead at Solana Labs) talks shop with the most interesting builders in the Solana ecosystem. It's for devs, by devs.Today's guest is T.J. Littlejohn, the founder of MtnPay, which won 1st Prize in the Payments Track of the recent Riptide Hackathon. 01:30 - Origin Story and Background05:12 - MntDAO08:42 - Building with Solana12:04 - MntPay13:25 - The APIs15:43 - Winning at Riptide17:37 - From starting in Solana to winning 20:41 - Starting to build in Solana23:38 - Improving onboarding on Solana25:26 - The Developer ecosystem27:07 - Missing Tooling29:30 - Advice for newcomers DISCLAIMERThe information on this podcast is provided for educational, informational, and entertainment purposes only, without any express or implied warranty of any kind, including warranties of accuracy, completeness, or fitness for any particular purpose.The information contained in or provided from or through this podcast is not intended to be and does not constitute financial advice, investment advice, trading advice, or any other advice.The information on this podcast is general in nature and is not specific to you, the user or anyone else. You should not make any decision, financial, investment, trading or otherwise, based on any of the information presented on this podcast without undertaking independent due diligence and consultation with a professional broker or financial advisor. Chase (00:29):Hey everybody and welcome to Chewing Glass, the show where we talk to developers building in the Solana Ecosystem. Today we have with us, TJ LittleJohn. He is the founder of mtnPay, winner of the most recent Solana Hackathon Payments Track for Riptide. TJ, how's it going, man?TJ (00:55):Dude, it's going good. We're stoked to be here. Thanks for having me on.Chase (01:00):Yeah, man. You and I basically met, I feel like a few months ago when you were building some stuff for iOS. Basically some IDL stuff with Anchor and we were talking about potentially getting you some work going on and then next thing you know, a couple of things happen and here we are. But before we dive too much into that, let's hear a little introduction. I know a lot of people probably don't know a ton about you. Where'd you start your journey and how'd you end up here, building in the Solana Ecosystem?TJ (01:31):Yeah. Wow. For sure. Abridged version. So, I'm from Florida originally born and raised. Grew up in South Florida, went to school in Tallahassee, Florida State Granoles. Originally I was a big Math guy. Always wanted to do pure Math and trying to see how I could make a career out of that. Finance was an option. And so I was exploring that and someone told me I should learn to code. So, I started learning to code, from that found Hackathons, from that found iOS development. And just down the rabbit hole there. At a hackathon, I ended up securing an internship at Apple, which turned into a job. And then I spent four years there doing research and development and experience prototyping. And then about a year ago I decided I was done with that and I wanted to be in startups. And so I left, joined a startup. Five months after that I found Solana through some friends and I just noticed the point in time we were at. And I was just stoked. And so I quit and I just immediately started building.Chase (02:36):Wow. So you don't have a CS degree, you're self-taught programmer and landed an internship at Apple dealing on the development side of things?TJ (02:44):No, I do have a CS degree.Chase (02:46):Oh, you do?TJ (02:46):So, I did both. I did Math and CS, but the CS portion to me was the less interesting one. I loved pure Math. I thought it was so cool. CS was more of the necessity one. And then I thought it was cool when I started doing it. But I think I learned a lot more through just the apps I built outside of class. So, partially self-taught. Because that was the more important part, but my education was super important too.Chase (03:13):You have a CS degree, you ended up interning for Apple. You did that for how long was it again?TJ (03:20):It was four years.Chase (03:22):Four years. And you said research, were you actually doing development while you were there?TJ (03:26):Yeah, so we did data collection for new products. So think how face ID was trained on millions of images. We built the software to facilitate those user studies that captured the data to train the models, to enable face ID. So we were brought in super early product.Chase (03:44):Oh, so I mean, I guess that's a little more interesting, like somebody who's into Math, you're dealing with lots of data and information, or opposed to just writing a high level code or something like that.TJ (03:55):Not exactly. The Math thing, it's like pure Math. I don't do with data and numbers and processing. I just think pure Math is fucking cool. And when I have an itch about something, I just want to dive. And so, that was the Math thing for me. That was just pure. I love it and I think it taught me how to understand stuff, which I think I still, every now and then, I'll see, I have the power to do that, which is really cool. The thing with Apple was that it let me just hack on shit. I had month long projects and software efforts that, because I get bored really quick, which is a blessing and a curse. Historically. Apple just let me work on a project and then a month later I was working on something else.Chase (04:41):Yeah, we've had some conversations, like you said, you get bored really quick, it comes through a little bit in your personality. You get super excited about things and bounce around and that's why I like your energy, it's super crazy and incredible. So it's nice to have people so excited about these things and especially considering the fact of some of the more recent, great things that have happened. I want to really start this whole conversation outside of your past on where it all truly, truly began, which from what I understand was really mtnDAO. That's like, lit this whole fire off. I don't know if everybody knows about it and if they do, maybe not how great of a thing that it turned out to be. Maybe about Barrett and Edgar and what they set up and how it was and then how that whole month went for you, that led to this moment.TJ (05:31):So yeah, mtnDAO, for people that don't know was a month long hacker house in Salt Lake City, Utah, where people from all over just congregated and we spent a month working on whatever it is you want to work on, in this co-working space called The Shop. And like you said, Edgar and Barrett, they're actually the ones that got me into Solana. They were the first people to introduce me and they just threw this hack house to grow the ecosystem out of the kindness of their own hearts and love for co-working and developing and hacking. And so yeah, a bunch of us came through and we just were chilling in Utah. We'd go snowboarding on the weekends. We'd throw parties on Fridays and bring in people from around the City and just strips, just get after it.And that was the best part. We'd be working from like 10:00, 11:00 AM was when I would roll in till like 1:00, 2:00 in the morning, most days. And a good crew of people were always there doing that too. Maybe if you wanted to go grab dinner, you could and people would come back. But yeah, it was just a lot of incredibly focused work and a nice little crew formed out of that. And so I've seen a lot of the same mtnDAO folks at the next hacker houses and stuff, and that's always fun. And you just become friends with these people.Chase (06:51):Yeah, it seems like there was a lot of building going on. I'm not going to lie, I saw that notion that Edgar and Barrett, or I think it might have been Edgar, correct me if I'm wrong, put together this notion. And I was like, a Dev did this? Just because it was so organized and well put together. And then, those guys pretty much put this thing, from start to finish, got this thing going.TJ (07:09):Yeah. There was a lot of people that participated in the setup of it. I know Sam had a big part, Edgar and Barrett had a big part. A lot of those core Salt Lake City people were doing this stuff. But yeah. I mean, they took out the trash. There was, under the tables the first day, taping extension cords. So they, I mean, yeah, they did the stuff.Chase (07:28):Yeah. I talked to him in Miami and he was like, yeah, I have a room and an office that's filled with about a hundred monitors. I can't remember what it is at some point, but it looked like there was tons of building going on there. Whenever I see the community, they didn't really ask for permission. And a lot of people would say, why don't you bring a hacker house to our city or this or that? And the reality is, you don't need that. You have an idea, you execute, you make it known. And people are going to come there and you're probably going to likely get some sponsors to help you put it on because this is like an incubator. And obviously mtnPay came out of this, which is incredible. Let's talk a little bit about that. I'm pretty sure, maybe I'm wrong, is that Solana Pay, was it announced before you got to mtnDAO? Or was it announced while you were there?TJ (08:13):It was actually the same day. February 1st is when I rolled through.Chase (08:19):I was on a phone call with you actually, whenever you showed up, you remember that?TJ (08:22):Really?Chase (08:23):Yeah, you were like, I just got to mtnDAO. Yeah. We were...TJ (08:27):I probably called you from the airport. Yeah. I've been like--Chase (08:29):You did.TJ (08:30):Probably over-committing myself. And I remember we were talking about doing a possible grant or something for that IDL stuff. And I was like, just trying to not lose that. Not doing my end of it. You were like, TJ, if you just write a notion page on your idea, I can move it through. And I was like, ah, I don't know. I'm building. And yeah. So we never got through there, but yeah.Chase (08:55):Well, I think it worked out pretty well. So, you got there, Solana Pay's announced, and you were just like, okay, well I'm just going to build something with this.TJ (09:04):No, not at all.Chase (09:06):Okay.TJ (09:07):There was two funny touch points with Solana Pay that got me rolling. The first one was, I hopped out of mtnDAO to go to the LA hacker house for a two day stint, because I was working with these people. And then as I was about to leave, I remember my friend Greg from Solana News was like, I missed the news cycle on Solana Pay. They must have had insider information, that was a couple of days after it was announced. And I was like, what do you mean, dude? It's been going on. He's like, what? I'm like, yeah. Are you not on Twitter? Do you not see this stuff? So, that was funny.And so, that had top of mind a little bit, but the idea for mtnPay, it was Friday night, it was the night of the first party we were having, we had parties every Friday or Saturday. And I was grabbing a Red Bull from, they had this self-service checkout kiosk, as I do. I just consume just stupid amounts of Red Bull. And I was buying another one and you pay through square, tap your phone. I don't know. I just had a random idea that it was like, yo, wouldn't it be hilarious if we rebuilt this self checkout experience and then just added the Solana Pay stuff, because we're all Solana people here for a month, this the first week and that would just be funny.And I told him, I was like, I'm just going to do it. And they're like, that's hilarious. Do it. And then so on Sunday, my boy Scott was in town and we were at the hacker house just trying to think of things to work on for Riptide. And we were skating through all these different ideas on creator tokens or I don't remember all the different things. And it was like, what if we do that Point of Sale thing? That'd be cool. And whatever, we could probably build this in a two day stint. Not a big deal and yeah, that's why we built it.Chase (11:00):Yeah, I remember starting to see a couple of days after Solana Pay launched, I started to see all these videos of people filming themselves and you guys paying with Solana Pay. I was like, this is crazy. This just came out. I can't believe, well, I could believe that you had put that together already. And then from there, Solana Pay's really gained a ton of traction, but you were really the first person to come out and be like, look, hey guys, I did it. And it's actually live in this place right now. And it's still there to this day? They keep that?TJ (11:32):Yeah. As far as I know. Our customer success could use some work. And so I haven't followed up with them in a couple weeks. But we got them set up on our new version, which was a more self-service thing. So as far as I know, it's still running there. There's even a week where it wasn't working and Barrett was texting me nonstop. Like, bro, you need to get this working again because I need this. And so, that's that classic, build something, people would be upset if it goes away. And so we did that.Chase (12:01):Yeah. So you did this in a short amount of time and since then, there was a lot left in the hackathon to go. So, since that first day or that you got that live, I guess you've been doing a ton of work up until the point where you made your final submission, tell us a little bit about mtnPay and what work was involved and what are the features and maybe what's the future of mtnPay.TJ (12:30):Yeah, for sure. So the first half the gate was just, it's an iOS Point of Sale app that enables users to use Solana Pay to pay. And then the second thing is a square integration. So, we use the square APIs to tie it into your current Point of Sale System. So the transactions show up in line. Chase bought a Red Bull here for $3 with his MasterCard and then he bought a cookie for a dollar using Solana Pay. And so that was the core thing. And we had built it specifically for The Shop. We got a bunch of inbound of like, how can I set this up? How can I do it? So we had to take a step back and use a couple weeks to make it more robust and actually usable in self-service. Which was our base for what we wanted to submit to the hackathon, was just like a usable Point of Sale by everyone, it's still in test flight.And then Solana Pay evolved to a new spec while we were there. And then immediately became gas on that. And ever since the wheels have been turning there and then that initial spec change is what led us to where we are today, which is honestly, and not a lot of people know this, but we're more of an API company now. We're more like SaaS APIs and stuff like that.Chase (13:43):I guess, doing the API side makes it a little more versatile so that anybody can use it and they don't have to use a specific device or framework or anything like that.TJ (13:55):Yeah. I think the APIs, to be honest, they came more out of this idea of defensibility, because with a lot of the attention we got, it was like, what's the opportunity here? Is there something worth building out? And in that, there's a lot of things that could make you super existential, like just square adding Solana pay themselves. And so how do we actually build a moat in this industry or something. And so we were like, this transaction request thing came up, which enables you to use APIs in Solana Pay, what if we open that up to people and then let that be our defensibility and our moat. And so we spent a lot of time thinking about what that API suite would look like and then realize that, that's the bigger opportunity from our point of view, but probably more importantly, it's what we want to build in this space.I think there's a lot of opportunities for a lot of people to participate and building out the client that people would use. There's also a lot of stuff that we weren't interested in building. Like inventory management and tax reporting and accounting. Like, nah. I want to do the Solana stuff. And the APIs is the Solana stuff. And so that's where we're at now.Chase (15:08):Now. Yeah. I mean, it makes sense. Here's the thing, you build a project and you don't want to start taking on things that you don't enjoy because then you probably stop enjoying your job. So you do what excites you and then you offload or allow connection points for other people to build that stuff who see that opportunity. But it makes a lot of sense. I've talked to people who have created businesses and then they pull in, maybe not this specifically, but like the tax stuff and all these different sort of inventory management. And then it becomes like, I don't really like this anymore. This is not what I signed up for.TJ (15:42):That's what was happening. And so it was like, really I had to focus on something specifically in there and that's, we picked the APIs and it's been cool. We've been working with different protocols to add their functionality to our APIs. And yeah, it's been fun since we started focusing there.Chase (16:04):So obviously it was the right move because you, just to circle back to this is, you won the Payments Track of the Riptide Hackathon. There was a lot of competition. There was a lot of good stuff in there. So I'm just curious, how did that feel when you saw that?TJ (16:18):I'm dumb competitive. And so it was so funny because it was like, it started off as people are, oh, you going to submit this to Riptide? And it was like, yeah, probably, but we're not really focused on that. And the closer we got to Riptide, we're like, we want to win. And then so we had been paying a lot of attention to other people that were building in this space, seeing where people's attention was. The whole time we were like, I don't know, fairly confident we would do well to some extent, but then I think it was up to, what did the judges value? You don't know. But we were super proud of what we built and we're hoping other people saw what we saw and seeing that we won the Payments Track, it was just like a pat on the back. It was like, we agree.Chase (17:07):We agree.TJ (17:09):Yeah. That's what it was. And there was some chest pounding, there was something like, yes. But I also think the part I was more stoked on was just the attention that would follow and knowing that we could leverage that to build something. Because I think the attention is just like, it's fuel. And you can't do it with only attention you have to follow it up. But we knew it would empower a lot of the things that we wanted to do.Chase (17:37):Yeah, for sure. And I think these aren't necessarily your classic typical hackathon, where you hack on some little thing for a week or a month. These sorts of events are actually catalysts to build real businesses. And this is meant to be inspirational to developers that are watching this, that may or may not have dipped their toes into Solana. Maybe they have, but they haven't gotten anywhere. These stories are super inspirational. So I want to put it in context. What is the timeframe from the day that TJ wrote his first piece or read his first Solana doc to winning Riptide Payments Track? What's that timeframe?TJ (18:13):September, August. I was reading, I was staying up late. I was still working at the startup and I was staying up till like 3:00, 4:00 in the morning, reading that classic, Paul article on doing an escrow. It was partly that it was partly that Packy podcast.Chase (18:30):Oh yeah.TJ (18:30):On Solana Summer. That was super dope. I remember I was at the gym and I was listening to him talk about the DJ Apes Mint and two weeks prior I was at Miami hack week, it was like, I remember I was chilling with Barrett, I met him for the first time, we had met through our friend Eve, shoutout Eve. And it was just me, Barrett, Edgar and Eve in this apartment and they were just talking about crypto and I knew nothing. So I wanted to fit in and I was like, oh, I bought some Ethereum lately.I thought I would impress him. And he is like, nah, and he's looking at me, he's like, fuck Ethereum. And I was like, what? And just turns around and he goes, Solana. And I was like, what is Solana? I thought it was like some shit coin. And that was just when it got on my map. And then I saw the Packy thing. I did that. And then all these NFT things were popping up and I'm like, all right, what's going on? And then Candy Machine pops up. So I'm like reading that contract and I'm reading the Levi's thing and trying to set one up for myself and it feels like explosions all around me. And I'm like, what is this world? And people are just shipping and I can't keep up. And it was like overwhelming. And then I quit.Chase (19:41):So it's been about, from zero to hero in seven months, basically. Is what I'm hearing right here. Seven or eight months.TJ (19:49):Yeah. Something like that. Yeah. I feel like I got onboarded fairly quick. I feel like I was doing stuff to me that felt like mattered, immediately. All that iOS stuff that I was doing, to me felt groundbreaking.Chase (20:04):Yeah.TJ (20:05):And I felt like a hero then, honestly. That stuff made me feel more of a hero than what I felt like with Riptide.Chase (20:11):Really?TJ (20:12):To be totally honest.Chase (20:12):So it was more so just that you win Riptide, like, wow, I got this thing, but the more part for you was the personal win of actually just starting on this new journey and figuring out how to build on Solana.TJ (20:26):Like I said, I'm dummy competitive. So winning Riptide was great. It was a good job power, but with mtnPay, I don't feel like I've done anything yet. I think there's opportunities too. And we're on a path to actually really contribute to the Solana Ecosystem. But I don't feel like I've had a major accomplishment there yet. But with the iOS stuff, I totally did. I, from native iOS code, minted an NFT through Candy Machine. I figured out how to talk to Anchor programs from native iOS code. And that to me was like, that gave me so much energy.Chase (21:05):So tell me about that. You started building on Solana, did you start messing around with Rust? Did you start messing around with Anchor? Or did you go straight to those SWIFT SDKs that existed? What was your process for getting rolling on Solana?TJ (21:18):Totally. Yeah. That's a great thing to preface here is, I've done barely any Rust. I haven't shipped a smart contract to Mainnet. Mostly client work. So there's massive opportunities in this space to really participate and have impact just doing client work. That being said, the way I really learned it was just wanting to write an iOS app that would work with Solana. And so I found a couple of open source SWIFT packages that was doing iOS transaction stuff. And so, that's how I learned what a transaction object looked like and where you serialize it and how you add accounts to that. And what's an account. And what's [inaudible 00:22:02] coding. All of that stuff I just learned because I had to, to make an iOS app that talked to Anchor. And so me and my friend, Michael, we went to college together, and so we were up till like 4:00 in the morning for weeks just printing out transaction objects in JavaScript, on the Anchor thing and figuring out how do we bridge that to iOS? And that was the coolest.Chase (22:30):And then this is exactly the point we've talked about a couple times on this show. And I say it on my Twitter all the time. You just won Riptide Payments Track and you'd never shipped a smart contract. How? Well it's because not everybody needs to be this guy who writes the smart contracts. You just need to know how to talk to them, using these different APIs, SWIFT, JavaScript. There's a C# SDK, there's a Unity One built on top of that. There's a [inaudible 00:22:57] one, they're all out there and you can learn Solana, and in a way you're comfortable, which is in your native language. And you're talking about just doing print lines and printing out and just reading, what is this object? And now I get it.TJ (23:10):Yeah. That was the process. And it was great. And I think we have a long way to go before developers can step in and build incredibly easily and efficiently, but the process is still fun. And there's a lot of toys you get to use when building this up, a lot of exposure, you feel super low level. And yet, they encourage everyone to just dig in and start building shit.Chase (23:38):In your opinion, what are some of those things that need to improve to make this easier for the new guys or the old guys? It doesn't really matter. What needs to happen? And what do we need?TJ (23:47):Error messages.Chase (23:49):Error messages.TJ (23:52):It is like, you will get like, Error A4, and there's nowhere to go. And you're digging around. I'm like, dude, you literally got to clone the repo and go line by line and figure out what's that error? What are we doing? It's fun. And from when I got into it to like what Armani's done with Anchor now and the Anchor books, that's there, the Solana Cookbook, that's all there now. So it's easier to do it now. And even when I try to do more on-chain stuff or build out stuff that I'm not comfortable with, I'm able to go reference those materials, but they weren't there in September.Chase (24:30):Yeah.TJ (24:31):And that was kind of fun though. It was like a point in time. And I was always envious of people that got to code in machine code, because they had to and what a point in time that must have been to get to be a part of that. And that's why I started building in Solana, I saw that point in time again, I thought Solana was going to pop and I was like, I'm not missing it.Chase (24:53):You were basically like, I see Solana, I see that not everything's been created and there's massive opportunities and I'm going to carve myself out a slice of that and just do it. So it's pretty crazy to be talking about this now.TJ (25:05):Yeah, it's been a journey.Chase (25:07):Yeah. And a lot of this was all Discord Support. It was a huge pain in the ass. You answer the same questions 5,000 times a day. Shoutout to the [inaudible 00:25:16] team at Solana labs that really just spent way too much time in Discord and the core engineers that shouldn't be there all.TJ (25:22):Shoutout Alan.Chase (25:23):Yeah. Alan has actually been obviously incredible.TJ (25:26):Fun story, in that with Alan, we were working on that iOS stuff till dumb hours at night, I think it might have been 2:00 in the morning. And we were having these errors we could not figure out. And so we posted in Discord and Alan answered and we're going back and forth with this guy. Didn't know him at all. This is our first thing. He's like, I'm happy to hop on a call with you to help you sort it out. And we were on that call for three hours. But that to me is such a story of people in Solana. There is so many people that just are cool with just helping you. And they're in the weeds with you and it's that developer ecosystem that attracted me and I think is going to attract so many people after me.):Which to your credit, I think you've set up a lot of it. Being the dev relations at Solana, just creating the environment for those developers to thrive and giving them the resources. I think that's where this has come from, but yeah, that was just a monster classic Solana moment for me that I wanted to highlight.Chase (26:31):Yeah, for sure. And there's a lot of people. It started with Toly and Raj and then that attitude and welcomeness humor came down to me and Armani and so many different people that feels like you can approach anybody in the ecosystem. And I agree, I think this side of tone and vibe is what will attract a lot of younger developers.TJ (26:56):Yeah.Chase (26:57):There's lots of different complaints out there. One of the biggest ones we've been hearing a lot is about tooling. If you agree with that, what web tooling or blockchain tooling are we missing right now at Solana? Do you have anything personally that you would like to see?TJ (27:12):No, I don't have the most robust engineering background. When I was at Apple, we used Apple internal tools. So that was all I really knew. And so, even now, I'll be coding on something with someone at a hackathon and they're like, wait, you're not using this plugin. You're not using the Anchor plugin for VS code. I'm like, no, what is that?Chase (27:34):Here's the old-school.TJ (27:36):Yeah. They're like, baby come here. They would set me up with some stuff. So, that's so cool. I think examples are going to be great. I think just like getting examples out there for people so that they could learn that they can do it too is going to be really cool.Chase (27:48):And self-onboard.TJ (27:48):Yeah. Self-onboarding's massive. And that's one of the ways we want to go with mtnPay, because we're just like a set of APIs. I think we can open up these APIs to iOS native developers to be able to build apps, they don't need to do the exact transaction building. We can have just a normal API that lets them build the transaction themselves. So that's one of the directions we definitely want to go into and we feel like can bring native developers to Solana, hopefully.Chase (28:16):Yeah. It's about giving the tools, the education to onboard people like mtnPay and the rest of the ecosystem who then drives in the users and then that it just spreads outwardly from there. So it's pretty incredible to watch right now, I'm not going to say, like I started last May about, next month will be my one year. And the difference in one year has made, like you said, even in September, you didn't have half the things that are available now. It's happening at the speed of light and it's, who knows? In one year from now it's going to be, again, unrecognizable. So I mean, it'll be unrecognizable in like six months, most likely or less. We'll see.TJ (28:57):Yeah. Just being along for the journey, I feel grateful.Chase (29:00):Yeah.TJ (29:01):Just what a point in time that we're in. I was talking with Edgar the other day, I was like, we got to remember, we're in the good old days right now.Chase (29:08):I guess, to round this off and you kind of already touched on this and I always do this at the end of every single episode of the show is, to just give some advice to whoever you want to give to advice to, maybe it's the new devs looking to come into blockchain that might be scared or intimidated by just the name, blockchain, scares some people.TJ (29:30):I mean, just start. Just start and just build. There's so many opportunities within yourself to push things off and it's so easy to complain or give yourself reasons to not build stuff. Even within myself every day I'd catch myself either complaining or giving excuses or whatever. But reality is, just build because when you just start building, you'll figure it out. You can ask the questions, you'll get there. And then that building really gives you momentum to keep going.Chase (30:09):Yeah man.TJ (30:10):Yeah. And it attracts people to you and then those people are going to give you energy and it just, it all cycles. But you have to be the one to start.Chase (30:21):Yeah. I mean, I don't think anybody's really given that advice and it is, like, we're all engineers, we've all just put things off. We all have 200 projects that we started one night and then never got back to. So it's really just getting started and just following through.TJ (30:35):Yeah. And don't be afraid to chase the energy. There's so many things I've tried doing in Solana that I would work on for a week and then stop. But even now I go back to them and they're just tools in the belt. And you'll be able to leverage learnings later on.Chase (30:51):Yeah. For sure. Well, TJ, congratulations for winning the Riptide Payments Track with mtnPay. Glad to get you on the show. Glad to have a conversation. Love the energy. Just keep it up, man. And thanks again for doing what you do. And thanks for being here.TJ (31:09):Yeah, no, I appreciate the opportunity. I feel there's definitely the longest we've been able to chat for how long we've known each other. It's funny. I feel like we kept missing each other in Miami. So, I'm glad we got this opportunity and hopefully I'll see you in The Bahamas.Chase (31:23):Thanks for coming on. 

It's time to shoot for the stars with Dan Isla, VP of Product at itopia, to talk about everything from astronomical importance of reliability to time zones on Mars. Dan's trajectory has been a propulsion of jobs bordering on the science fiction, with a history at NASA, modernizing cloud computing for them, and loads more. Dan discusses the finite room for risk and failure in space travel with an anecdote from his work on Curiosity. Dan talks about his major take aways from working at Google, his “baby” Selkies, his work at itopia, and the crazy math involved with accounting for time on Mars!In this episode, we cover: Introduction (00:00) Dan's work at JPL (01:58) Razor thin margins for risk (05:40) Transition to Google (09:08)  Selkies and itopia (13:20) Building a reliability community (16:20) What itopia is doing (20:20) Learning, building a “toolbox,” and teams (22:30) Clockdrift (27:36) Links Referenced: itopia: https://itopia.com/ Selkies: https://github.com/danisla/selkies selkies.io: https://selkies.io Twitter: https://twitter.com/danisla LinkedIn: https://www.linkedin.com/in/danisla/ TranscriptDan: I mean, at JPL we had an issue adding a leap second to our system planning software, and that was a fully coordinated, many months of planning, for one second. [laugh]. Because when you're traveling at 15,000 miles per hour, one second off in your guidance algorithms means you missed the planet, right? [laugh]. So, we were very careful. Yeah, our navigation parameters had, like, 15 decimal places, it was crazy.Julie: Welcome to Break Things on Purpose, a podcast about reliability, building things with purpose, and embracing learning. In this episode, we talked to Dan Isla, VP of Product at itopia about the importance of reliability, astronomical units, and time zones on Mars.Jason: Welcome to the show, Dan.Dan: Thanks for having me, Jason and Julie.Jason: Awesome. Also, yeah, Julie is here. [laugh].Julie: Yeah. Hi, Dan.Jason: Julie's having internet latency issues. I swear we are not running a Gremlin latency attack on her. Although she might be running one on herself. Have you checked in in the Gremlin control panel?Julie: You know, let me go ahead and do that while you two talk. [laugh]. But no, hi and I hope it's not too problematic here. But I'm really excited to have Dan with us here today because Dan is a Boise native, which is where I'm from as well. So Dan, thanks for being here and chatting with us today about all the things.Dan: You're very welcome. It's great to be here to chat on the podcast.Jason: So, Dan has mentioned working at a few places and I think they're all fascinating and interesting. But probably the most fascinating—being a science and technology nerd—Dan, you worked at JPL.Dan: I did. I was at the NASA Jet Propulsion Lab in Pasadena, California, right, after graduating from Boise State, from 2009 to around 2017. So, it was a quite the adventure, got work on some, literally, out-of-this-world projects. And it was like drinking from a firehose, being kind of fresh out to some degree. I was an intern before that so I had some experience, but working on a Mars rover mission was kind of my primary task. And the Mars rover Curiosity was what I worked on as a systems engineer and flight software test engineer, doing launch operations, and surface operations, pretty much the whole, like, lifecycle of the spacecraft I got to experience. And had some long days and some problems we had to solve, and it was a lot of fun. I learned a lot at JPL, a lot about how government, like, agencies are run, a lot about how spacecraft are built, and then towards the end a lot about how you can modernize systems with cloud computing. That led to my exit [laugh] from there.Jason: I'm curious if you could dive into that, the modernization, right? Because I think that's fascinating. When I went to college, I initially thought I was going to be an aerospace engineer. And so, because of that, they were like, “By the way, you should learn Fortran because everything's written in Fortran and nothing gets updated.” Which I was a little bit dubious about, so correct folks that are potentially looking into jobs in engineering with NASA. Is it all Fortran, or… what [laugh] what do things look like?Dan: That's an interesting observation. Believe it or not, Fortran is still used. Fortran 77 and Fortran—what is it, 95. But it's mostly in the science community. So, a lot of data processing algorithms and things for actually computing science, written by PhDs and postdocs is still in use today, mostly because those were algorithms that, like, people built their entire dissertation around, and to change them added so much risk to the integrity of the science, even just changing the language where you go to language with different levels of precision or computing repeatability, introduced risk to the integrity of the science. So, we just, like, reused the [laugh] same algorithms for decades. It was pretty amazing yeah.Jason: So, you mentioned modernizing; then how do you modernize with systems like that? You just take that codebase, stuff it in a VM or a container and pretend it's okay?Dan: Yeah, so a lot of it is done very carefully. It goes kind of beyond the language down to even some of the hardware that you run on, you know? Hardware computing has different endianness, which means the order of bits in your data structures, as well as different levels of precision, whether it's a RISC system or an AMD64 system. And so, just putting the software in a container and making it run wasn't enough. You had to actually compute it, compare it against the study that was done and the papers that were written on it to make sure you got the same result. So, it was pretty—we had to be very careful when we were containerizing some of these applications in the software.Julie: You know, Dan, one thing that I remember from one of the very first talks I heard of yours back in, I think, 2015 was you actually talked about how we say within DevOps, embrace failure and embrace risk, but when you're talking about space travel, that becomes something that has a completely different connotation. And I'm kind of curious, like, how do you work around that?Dan: Yeah, so failing fast is not really an option when you only have one thing [laugh] that you have built or can build. And so yeah, there's definitely a lot of adverseness to failing. And what happens is it becomes a focus on testing, stress testing—we call it robustness testing—and being able to observe failures and automate repairs. So, one of the tests programs I was involved with at JPL was, during the descent part of the rover's approach to Mars, there was a power descent phase where the rover actually had a rocket-propelled jetpack and it would descend to the surface autonomously and deliver the rover to the surface. And during that phase it's moving so fast that we couldn't actually remote control it, so it had to do everything by itself.And there were two flight computers that are online, pretty much redundant, everything hardware-wise, and so it's kind of up to the software to recover itself. And so, that's called entry descent and landing, and one of my jobs towards the end of the development phase was to ensure that we tested all of the possible breakage points. So, we would do kind of evil Gremlin-like things. We actually—the people in the testbed, we actually call Gremlins. And [laugh] we would—we—they inject faults during the simulation.So, we had copies of the hardware running on a desk, the software was running, and then we'd have Gremlins go and say like, “Hey, flight computer one just went out. You know, what's going to happen?” And you watch the software, kind of, take over and either do the right thing or simulate a crash landing. And we find bugs in the software this way, we'd find, like, hangs in the control loops for recovery, and we had to fix those before we made it to Mars, just in case that ever happened. So, that was like how we, like, really stressed test the hardware, we did the same thing with situational awareness and operations, we had to simulate things that would happen, like, during launch or during the transit from Earth to Mars, and then see how the team itself reacted to those. You know, do our playbooks work? Can we run these in enough time and recover the spacecraft? So, it was a lot of fun. That's I guess that's about as close to, like, actually breaking something I can claim to. [laugh].Julie: Well, I have to say, you've done a good job because according to Wikipedia—which we all know is a very reliable source—as of May 9th, 2022, Curiosity has been active on Mars for 3468 sols or 3563 days, and is still active. Which is really amazing because I don't—was it ever intended to actually be operational that long?Dan: Not really. [laugh]. The hardware was built to last for a very long time, but you know, as with most missions that are funded, they only have a certain amount of number of years that they can be operated, to fund the team, to fund the development and all that. And so, the prime mission was only, like, two years. And so, it just keeps getting extended. As long as the spacecraft is healthy, and, like, doing science and showing results, we usually extend the missions until they just fall apart or die, or be intentionally decommissioned, kind of like the Cassini project. But yeah.Julie: Well, you've heard it here first, folks. In order to keep funding, you just need to be, quote, “Doing science.” [laugh]. But Dan, after JPL, that's when you went over to Google, right?Dan: Yeah, yeah. So, it was kind of that transition from learning how to modernize with cloud. I'd been doing a lot with data, a lot with Amazon's government cloud, which is the only cloud we could use at JPL, and falling in love with these APIs and ways to work with data that were not possible before, and saw this as a great way to, you know, move the needle forward in terms of modernization. Cloud is a safe place to prototype a safe place to get things done quick. And I always wanted to work for a big tech company as well, so that was always another thing I was itching to scratch.And so Google, I interviewed there and finally made it in. It was not easy. I definitely failed my first interview. [laugh]. But then try it again a few years later, and I came in as a cloud solution architect to help customers adopt cloud more quickly, get through roadblocks.My manager used to say the solution architects were the Navy Seals of cloud, they would drop in, drop a bunch of knowledge bombs, and then, like, get out, [laugh] and go to the next customer. It was a lot of fun. I got to build some cool technology and I learned a lot about what it's like working in a big public company.Julie: Well, one of my favorite resources is the Google SRE book, which, as much as I talk about it, I'm just going to admit it here now, to everybody that I have not read the entire thing.Dan: It's okay.Julie: Okay, thank you.Dan: Most people probably haven't.Julie: I also haven't read all of Lord of the Rings either. But that said, you know, when you talk about the learnings, how much of that did you find that you practiced day-to-day at Google?Dan: In cloud—I've mostly worked in cloud sales, so we were kind of post-sales, the experts from the technology side, kind of a bridge to engineering and sales. So, I didn't get to, like, interact with the SREs directly, but we have been definitely encouraged, I had to learn the principles so that we could share them with our customers. And so, like, everyone wanted to do things like Google did, you know? Oh, these SREs are there, and they're to the rescue, and they have amazing skills. And they did, and they were very special at Google to operate Google's what I would call alien technology.And so, you know, from a principles point of view, it was actually kind of reminded me a lot of what I learned at JPL, you know, from redundant systems and automating everything, having the correct level of monitoring. The tools that I encountered at Google, were incredible. The level of detail you could get very quickly, everything was kind of at your fingertips. So, I saw the SREs being very productive. When there was an outage, things were communicated really well and everyone just kind of knew what they were doing.And that was really inspiring, for one, just to see, like, how everything came together. That's kind of what the best part of working at Google was kind of seeing how the sausage was made, you know? I was like, “Oh, this is kind of interesting.” [laugh]. And still had some of its big company problems; it wasn't all roses. But yeah, it was definitely a very interesting adventure.Jason: So, you went from Google, and did you go directly to the company that you helped start, right now?Dan: I did. I did. I made the jump directly. So, while I was at Google, you know, not only seeing how SRE worked, but seeing how software was built in general and by our customers, and by Google, really inspired me to build a new solution around remote productivity. And I've always been a big fan of containers since the birth of Docker and Kubernetes.And I built the solution that let you run, kind of, per-user workloads on Kubernetes and containers. And this proved to be interesting because you could, you know, stand up your own little data processing system and scale it out to your team, as well as, like, build remote code editors, or remote desktop experiences from containers. And I was very excited about this solution. The customers were really starting to adopt it. And as a solution architect, once the stuff we built, we always open-source it.So, I put it on GitHub as a project called Selkies. And so, Selkies is the Kubernetes components and there's also the high performance streaming to a web browser with WebRTC on GitHub. And a small company, itopia, I met at a Google conference, they saw my talk and they loved the technology. They were looking for something like that, to help some of their product line, and they brought me in as VP of Product.So, they said, “We wanted to productize this.” And I'm like, “Well, you're not doing that without me.” [laugh]. Right? So, through the pandemic and work from home and everything, I was like, you know, now is probably a good time to go try something new.This is going to be—and I get to keep working on my baby, which is Selkies. So yeah, I've been itopia since beginning of 2021, building a remote desktop, really just remote developer environments and other remote productivity tools for itopia.Julie: Well and, Dan, that's pretty exciting because you actually talked a little bit about that at DevOpsDays Boise, which if that video is posted by the time of publication of this podcast, we'll put a link to that in the show notes. But you're also giving a talk about this at SCaLE 19x in July, right?Dan: Yeah, that's right. Yeah, so SCaLE is the Southern California Linux Expo, and it's a conference I really enjoy going to get to see people from Southern California and other out of town, a lot of JPLers usually go as well and present. And so, it's a good time to reconnect with folks. But yeah, so SCaLE, you know, they usually want to talk more about Linux and some of the technologies and open-source. And so yeah, really looking forward to sharing more about selfies and kind of how it came to be, how containers can be used for more than just web servers and microservices, but also, you know, maybe, like, streaming video games that have your container with the GPU attached. The DevOpsDays Boise had a little demo of that, so hopefully, that video gets attached. But yeah, I'm looking forward to that talk at the end of July.Jason: Now, I'm really disappointed that I missed your talk at DevOpsDays Boise. So Julie, since that's your domain, please get those videos online quickly.Julie: I am working on it. But Dan, one of the things that you know you talk about is that you are the primary maintainer on this and that you're looking to grow and improve with input from the community. So, tell us, how can the community get involved with this?Dan: Yeah, so Selkies is on GitHub. You can also get to it from selkies.io. And basically, we're looking for people to try it out, run it, to find problems, you know, battle test it. [laugh]. We've been running it in production at itopia, it's powering the products they're building now.So, we are the primary maintainers. I only have a few others, but, you know, we're just trying to build more of an open-source community and level up the, you know, the number of contributors and folks that are using it and making it better. I think it's an interesting technology that has a lot of potential.Jason: I think as we talk about reliability, one of the things that we haven't covered, and maybe it's time for us to actually dive into that with you is reliability around open-source. And particularly, I think one of the problems that always happens with open-source projects like this is, you're the sole maintainer, right? And how do you actually build a reliable community and start to grow this out? Like, what happens if Dan suddenly just decides to rage quit tech and ups and leaves and lives on his own little private island somewhere? What happens to Selkies?Do you have any advice for people who've really done this, right? They have a pet project, they put it on GitHub, it starts to gain some traction, but ultimately, it's still sort of their project. Do you have any advice for how people can take that project and actually build a reliable, growing, thriving community around it?Dan: Honestly, I'm still trying to figure that out [laugh] myself. It's not easy. Having the right people on your team helps a lot. Like, having a developer advocate, developer relations to showcase what it's capable of in order to create interest around the project, I think is a big component of that. The license that you choose is also pretty important to that.You know, there's some software licenses that kind of force the open-sourcing of any derivative of what you build, and so that can kind of keep it open, as well, as you know, move it forward a little bit. So, I think that's a component. And then, you know, just, especially with conferences being not a thing in the last couple of years, it's been really hard to get the word out and generate buzz about some of these newer open-source technologies. One of the things I kind of like really hope comes out of a two-year heads-down time for developers is that we're going to see some, like, crazy, amazing tech on the other side. So, I'm really looking forward to the conferences later this year as they're opening up more to see what people have been building. Yeah, very interested in that.Jason: I think the conversation around open-source licenses is one that's particularly interesting, just because there's a lot involved there. And there's been some controversy over the past couple of years as very popular open-source projects have decided to change licenses, thinking of things like Elastic and MongoDB and some other things.Dan: Yeah. Totally.Jason: You chose, for Selkies, it looks like it's Apache v2.Dan: Yep. That was mostly from a Google legal point of view. When I was open-sourcing it, everything had to be—you know, had to have the right license, and Apache was the one that we published things under. You know, open-source projects change their license frequently. You saw that, like what you said, with Elastic and Mongo.And that's a delicate thing, you know, because you got to make sure you preserve the community. You can definitely alienate a lot of your community if you do it wrong. So, you got to be careful, but you also, you know, as companies build this tech and they're proud of it and they want to turn it into a product, you want to—it's a very delicate process, trying to productize open-source. It can be really helpful because it can give confidence to your customers, meaning that, like, “Hey, you're building this thing; if it goes away, it's okay. There's this open-source piece of it.”So, is instills a little bit of confidence there, but it also gets a little tricky, you know? Like, what features are we adding the add value that people will still pay for versus what they can get for free? Because free is great, but you know, it's a community, and I think there are things that private companies can add. My philosophy is basically around packaging, right? If you can package up an open-source product to make it more easier to consume, easier to deploy, easier to observe and manage, then you know, that's a lot of value that the rest of the free community may not necessarily need.If they're just kind of kicking the tires, or if they have very experienced Kubernetes team on-site, they can run this thing by themselves, go for it, you know? But for those, the majority that may not have that, you know, companies can come in and repackage things to make it easier to run open-source. I think there's a lot of value there.Jason: So, speaking of companies repackaging things, you mentioned that itopia had really sort of acquired you in order to really build on top of Selkies. What are the folks at itopia doing and how are they leveraging the software?Dan: That's a good question. So, itopia's mission is to radically improve work-from-anywhere. And we do that by building software to orchestrate and automate access to remote computing. And that orchestration and automation is a key component to this, like, SaaS-like model for cloud computing.And so, Selkies is a core piece of that technology. It's designed for orchestrating per-user workloads, like, remote environments that you would need to stand up. And so, you know, we're adding on things that make it more consumable for an enterprise, things like VPN peering and single-sign-on, a lot of these things that enterprises need from day one in order to check all the boxes with their security teams. And at the heart of that is really just increasing the amount of the productivity you have through onboarding.Basically, you know, setting up a developer environment can take days or weeks to get all the dependencies set up. And the point of itopia—Spaces is the product I'm working on—is to reduce that amount of time as much as possible. And, you know, this can increase risk. If you have a product that needs to get shipped and you're trying to grow or scale your company and team and they can't do that, you can slip deadlines and introduce problems, and having a environment that's not consistent, introduces reliability problems, right, because now you have developers that, “Hey, works on my machine.” But you know, they may have—they don't have the same machine, same environment as everyone else, and now when it comes to reproducing bugs or even fixing them, that you can introduce more problems to the software supply chain.Julie: I mean, that sounds like a great problem to solve and I'm glad you're working on it. With your background being varied, starting as an intern to now where you personally are being acquired by organizations. What's something that you've really learned or taken from that? Because one thing that you said was that you failed your first Google interview badly? And—Dan: Yes. [laugh].Julie: I find that interesting because that sounds like you know, you've taken that learning from failure, you've embraced the fact that you failed it. Actually, I just kind of want to go back. Tell us, do you know what you did?Dan: It was definitely a failure. I don't know how spectacular it was, but, like, [laugh] google interviews are hard. I mean—and that's just how it is, and it's been—it's notorious for that. And I didn't have enough of the software, core software experience at the time to pass the interview. These are, like, five interviews for a software engineer.And I made it through, like, four of them. The last one was, like, just really, really, really hard and I could not figure it out. You know, because this is, like, back in the day—and I think they still do this, like, where you're, like, coding on a whiteboard, right? Like, okay, right, this C code on a whiteboard, and it has to work. You know, the dude is, like, right, there compiling it, right? Like, “Okay, [unintelligible 00:23:29], boy.” [laugh].So, not only is a high stress, but it has to be right as well. [laugh]. And so, like, it was just a very difficult experience. And what I learned from that was basically, “Okay, I need to, one, get more experience in this style and this domain of programming, as well, as you know, get more comfortable speaking and being in front of people I don't know.” [laugh].So yeah, there's definitely components there of personal growth as well as technical growth. From a technical point of view, like, my philosophy as being an engineer in general, and software developer, is have a really big toolbox and use the tools that are appropriate for the job. This is, like, one of my core philosophies. Like, people ask, you know, ‘what language do you use?' And I'm like, “Whatever language you needed to solve the problem.”Like, if you're writing software, in a—with libraries that are all written in C, then don't try to do that in, like, Java or something, in some other language that doesn't have those language bindings. Don't reinvent the language bindings. You follow the problem and you follow the tech. What language, what tool will best solve this problem? And I'm always working backwards from the problem and then bringing in the right tools to solve it.And that's something that has paid off in dividends because it's very—problem-solving is fun and it's something I always had a passion for, but when you have a toolbox that is full of interesting gadgets and things you can use, you get excited every time you get to use that tool. Like, just like power tools here, I have a—I don't know, but it's like, “Yeah, I get to use the miter saw for this thing. Awesome. I don't have one? Okay, I'm going to go buy one.” [laugh].Julie: That's actually—that's a really good point, one of the talks that I gave was, “You Can't Buy DevOps.” And it was really all about letting developers be part of the process in choosing the tools that they're going to use. Because sometimes I think organizations put too many constraints around that and force you to use these tools that might not be the best for what you're trying to accomplish. So, I like that you bring up having the ability to be excited about your toolbox, or your miter saw. For me, it would be my dremel. Right? But what tool is going to—Dan: [crosstalk 00:25:39] cool.Julie: Yeah, I mean, they really are—what tool is going to be best for the job that you are trying to accomplish? And I think that that's, that's a big thing. So, when you look to bring people onto your team, what kind of questions do you ask them? What are you looking for?Dan: Well, we're just now starting to really grow the company and try and scale it up. And so we're, you know, we're starting to get into more and more interview stuff, I try to tell myself, I don't want to put someone through the Google experience again. And part of that is just because it wasn't pleasant, but also, like, I don't know if it was really that useful [laugh] at the end of the day. And so, you know, there's a lot about culture fit that is really important. People have to be able to communicate and feel comfortable with your team and the pace that your team is working at. And so, that's really important.But you know, technically, you know, I like to see a lot of, you know—you got to be able to show me that you can solve problems. And that can be from, you know, just work that you've done an open-source, you know, having a good resume of projects you've worked on is really important because then we can just talk about tech and story about how you solve the problem. I don't have to—I don't need you to go to the whiteboard and code me something because you have, like, 30 repos on GitHub or something, right? And so, the questions are much more around problem-solving: you know, how would you solve this problem? What technology choices would you use, and why?Sometimes I'll get the fundamentals, like, do you understand how this database works at its core or not? You know, or why is it… why is that good or bad? And so, looking for people who can really think within the toolbox they have—it doesn't have to be a big one, but do they know how to use the tools that they've acquired so far, and really, just really, really critically think through with your problems? So, to me, that's a better skill to have than just, you know, being able to write code on the whiteboard.Julie: Thanks for that, Dan. And earlier, before we started the official recording here, you were talking a little bit about time drift. Do you want to fill everybody in on what you were talking about because I don't think it was Doctor Strange and the Multiverse of Madness?Dan: No. [laugh]. I think there were some—we were talking about um…clocks?Julie: Clocks skew.Dan: Daylight savings time?Julie: Yeah.Dan: Clock skew, clock drift. There was a time at JPL when we were inserting a leap second to the time. This actually happened all throughout the world, where periodically that the clocks will drift far enough because the orbits and the rotation of the planet are not, like, perfectly aligned to 365 days in a year and 24 hours in a day. And so, every so decades, you have to insert these leap seconds in order to catch up and make time more precise. Well, space travel, when you're planning, you have to—you're planning to the position of the stars and the planets and the orbital bodies, and those measurements are done at such a large scale that you have—your precision goes, like, way out, you know, many, many decimal places in order to properly plan to the bodies up big.And with the Mars Rover, one of these leap seconds happened to come in, like, right, before we launched. And it was like, oh my gosh, this is going to be to—change all of our ephemeris files—the data that you use to track positions—and we had to do it, like, synchronize it all, like, right, when the leap second was going in. And we tested this extensively because if you get it wrong with your spacecraft is traveling, like, 15,000 miles an hour towards Mars, and a one-second pointing error from Earth means, like, you missed the whole planet, you won't even get there. [laugh]. We're not talking about, like, missing the landing site of, like, a few kilometers. No, it's like thousands of kilometers in pointing error.So yeah, things are astronomical [laugh] in units. Actually, that's why they're called AU, astronomical units, when you're measuring the distance from the Sun. So yeah, it was a pretty fun time. A little bit nerve-wracking just because the number of systems that had to be updated and changed at the same time. It's kind of like doing a rolling update on a piece of software that just had to go out all at the same time. Yeah.Jason: I think that's really interesting, particularly because, you know, for most of us, I think, as we build things whether that's locally or in the cloud or wherever our servers are at, we're so used to things like NTP, right, where things just automatically sync and I don't have to really think about it and I don't really have to worry about the accuracy because NTP stays pretty tight. Usually, generally.Dan: Mm-hm.Jason: Yeah. So, I'm imagining, obviously, like, on a spacecraft flying 15,000 miles a second or whatever, no NTP out there.Dan: [laugh]. Yeah, no NTP and no GPS. Like, all the things you take for granted, on Mars are just not there. And Mars even has a different time system altogether. Like the days on Mars are about 40 minutes longer because the planet spins slower.And my first 90 sols—or days on Mars—of the mission, the entire planning team on earth that I was a part of, we lived on Mars time. So, we had to synchronize our Earth's schedule with what the rover was doing so that when the rover was asleep, we were planning the next day's activities. And when it woke up, it was ready to go and do work during the day. [laugh]. So, we did this Mars time thing for 90 days. That was mostly inherited from the Mars Exploration rovers, Spirit and Opportunity because they were only designed to live for, like, 90 days.So, the whole team shifted. And we—and now it's kind of done in spirit of that mission. [laugh]. Our rover, we knew it was going to last a bit longer, but just in case, let's shift everyone to Mars time and see what happened. And it was not good. We had to [laugh] we had to end that after 90 days. People—your brain just gets completely fried after that. But it was bizarre.And there's no time. You have invent your own time system for Mars. Like, there's no, it was called LMST, or Local Mars Standard Time, local mean standard time. But it was all, like, relative to, you know, the equator and where you were on the planet. And so, Mars had his own Mars time that counted at a different rate per second.And so, it was funny, we had these clocks in the Mission Control Room that—there was this giant TV screen that had, like, four different time clocks running. It had, like, Pasadena time, UTC time, Mars time, and, like, whatever time it was at the Space Network. And I was like, “Oh, my gosh.” And so, we were always doing these, like, time conversions in our heads. It was mental. [laugh]. So, can't we just all be on UTC time? [laugh].Jason: So, I'm curious, with that time shift of being on Mars time and 40 minutes longer, that inherently means that by the end of that 90 days, like, suddenly, your 8 a.m. Mars local time is, like, shifted, and is now, like, hours off, right? You're waking—Dan: Yeah.Jason: Up in the middle of the night?Dan: Totally, yeah.Jason: Wow.Dan: Yeah, within, like, two weeks, your schedule will be, like, upside down. It's like, every day, you're coming in 40 minutes later. And yeah, it was… it was brutal. [laugh]. Humans are not supposed to do that.If you're actually living on Mars, you're probably okay, but like, [laugh] trying to synchronize those schedules. I thought you were going from East Coast to West Coast time, working remote was hard. And, like, [laugh] that's really remote.Julie: Dan, that's just astronomical.Dan: [laugh].Julie: I'm so sorry. I had to do it. But with that—[laugh].Jason: [laugh].Dan: [laugh]. [unintelligible 00:33:15].Julie: With that, Dan, I really just want to thank you for your time on Break Things on Purpose with us today. And as promised, if I can find the links to Dan's talks, if they're available before this episode posts, we will put those in the show notes. Otherwise, we'll put the link to the YouTube channel in the show notes to check for updates. And with that, I just want to thank you, Dan, and wish you a wonderful day.Jason: Before we go, Dan, do you have anything that you'd like to plug? Any projects that people should check out, where they can find you on the internet, stuff like that?Dan: Yeah, thank you guys very much for having me. It was a great conversation. Really enjoyed it. Please check out our new product, itopia Spaces, remote developer environments delivered, powered by Selkies. We launched it last fall and we're really trying to ramp that up.And then check out the open-source Selkies project, selkies.io will get you there. And yeah, we're looking for contributors. Beyond that, you can also find me on Twitter, I'm @danisla, or on LinkedIn.Jason: Awesome. Well, thanks again for being a part of the show. It's been fantastic.Dan: You're very welcome. Thanks for having me.Jason: For links to all the information mentioned, visit our website at gremlin.com/podcast. If you liked this episode, subscribe to the Break Things on Purpose podcast on Spotify, Apple Podcasts, or your favorite podcast platform. Our theme song is called, “Battle of Pogs” by Komiku, and it's available on loyaltyfreakmusic.com.

Anand Babu Periasamy, Co-Founder, CEO of MinIO, Inc. discusses object storage and the rise of SaaS or Software as a Service, the importance of using microservices in the data protection space, and the role APIs play in data management.

Tuesday, 17 May 2022   And they made a calf in those days, offered sacrifices to the idol, and rejoiced in the works of their own hands. Acts 7:41   Included among other words in the previous verse, Stephen quoted the people of Israel saying, “Make us gods to go before us.” He continues with that now, saying, “And they made a calf in those days.”    The word translated as “they made a calf” is found only here, moschopoieó. It is not used in the Greek Old Testament. It comes from moschos (a calf, heifer, or bull) and poieó (to construct or make). Stephen coins a new word to show the disdainful nature of what occurred. The event is recorded in Exodus 32 –   “And Aaron said to them, ‘Break off the golden earrings which are in the ears of your wives, your sons, and your daughters, and bring them to me.' 3 So all the people broke off the golden earrings which were in their ears, and brought them to Aaron. 4 And he received the gold from their hand, and he fashioned it with an engraving tool, and made a molded calf. Then they said, ‘This is your god, O Israel, that brought you out of the land of Egypt!'” Exodus 32:2-4   The reason for making this calf is not perfectly evident without understanding the symbolism. It said in Exodus 32:39 that “their hearts turned back to Egypt.” Vincent's Word Studies explains how the calf is so intimately connected to Egypt –   ---------------   This was in imitation of the Egyptian bull-worship. Several of these animals were worshipped at different places in Egypt. Apis was worshipped at Memphis. Herodotus says: "Now this Apis, or Epaphus, is the calf of a cow which is never afterward able to bear young. The Egyptians say that fire comes down from heaven upon the cow, which thereupon conceives Apis. The calf which is so called has the following marks: He is black, with a square spot of white upon his forehead, and on his back the figure of an eagle. The hairs in his tail are double, and there is a beetle upon his tongue" (iii., 28). He was regarded by the Egyptians, not merely as an emblem, but as a god. He was lodged in a magnificent court, ornamented with figures twelve cubits high, which he never quitted except on fixed days, when he was led in procession through the streets. His festival lasted seven days, and all came forward from their houses to welcome him as he passed. He was not allowed to reach the natural term of his life. If a natural death did not remove him earlier, he was drowned when he reached the age of twenty-five, and was then embalmed and entombed in one of the sepulchral chambers of the Serapeum, a temple devoted expressly to the burial of these animals.   Another sacred bull was maintained at Heliopolis, in the great Temple of the Sun, under the name of Mnevis, and was honored with a reverence next to Apis. Wilkinson thinks that it was from this, and not from Apis, that the Israelites borrowed their notions of the golden calf. "The offerings, dancing, and rejoicings practised on the occasion, were doubtless in imitation of a ceremony they had witnessed in honor of Mnevis during their sojourn in Egypt" ("Ancient Egyptians," 2 sen, vol. ii., p. 197). A third sacred bull, called Bacis, was maintained at Hermonthis, near Thebes. It was a huge, black animal, and its hairs were said to grow the wrong way. Other bulls and cows did not hold the rank of gods, but were only sacred.   ---------------   With this symbol of Egypt now before them, Stephen next says that the people “offered sacrifices to the idol.”   Sacrifices were made as offerings of devotion, for appeasement, for atonement, for fellowship, and so on. In offering sacrifices, they were aligning themselves with this idol as a representation of the Lord (YHVH). Aaron stated this explicitly. This was in violation of the covenant they agreed to when the Lord spoke out the Ten Commandments. Rather than obtaining favor, they were bringing wrath down upon themselves. Stephen then finishes the verse with “and rejoiced in the works of their own hands.”   The thought of this and the previous clause are found in Exodus 32 –   “So when Aaron saw it, he built an altar before it. And Aaron made a proclamation and said, ‘Tomorrow is a feast to the Lord.' 6 Then they rose early on the next day, offered burnt offerings, and brought peace offerings; and the people sat down to eat and drink, and rose up to play.” Exodus 32:5, 6   The thought of rejoicing in the work of their own hands means that they fashioned their own god, and they were thus participants in their own supposed reconnection to the divine. This is what Adam and Eve did when “they sewed fig leaves together and made themselves coverings” (Genesis 3:7). They were attempting to reestablish the connection to God that had been lost, covering over their sinful state in order to restore a propitious relationship with Him. But the Lord rejected that. It is not through our effort, but through His that a covering is provided and restoration is realized.   Israel made the same mistake, rejecting the Lord and attempting to obtain their own path to appeasement, atonement, and fellowship.   Life application: The same concepts come up again and again in Scripture, attempting to help us think through what is going on. In the case of salvation, Paul says that it is by grace through faith. It is not of ourselves, but rather it is the gift of God.   If you ask almost any teacher or preacher if that is so, they will immediately agree with it. They could do no less. The words are clear, precise, and unambiguous. And yet, no sooner do many avow that this is true, than they immediately turn around and inject their own works back into the equation. They may do it by saying you can lose your salvation. They may do it by saying you must submit to the law of Moses or certain precepts from it. They may say that you need to give up your sin before you can be saved, and so on.   Such things either directly contradict the notion of salvation being a gift that comes by grace through faith, or they put the cart before the horse by claiming you must do something before receiving the gift (which is contradictory as well).   Be sure to keep simple what is simple. Don't allow anyone to rob you of the very basics of theology and be sure not to rob others of them as well. Grace! Grace! We are saved by God's grace! Why should we take such a pure and simple message and tarnish it? Hold fast to the grace of God that is found in Jesus Christ our Lord.   Lord God, forgive us for always trying to fashion our own path to salvation by rejecting the simple message of grace that Your word speaks of. Help us to never add to the glory of what You have done through the giving of Jesus. His cross! His death! His burial! His resurrection! What could we ever add to that? Only after receiving it will we attempt to please You with lives lived in holiness. Amen.

Our expert hosts, Benjamin Ensor and Kate Moody, are joined by some great guests to talk about the most notable fintech, financial services and banking news from the past week. This week's guests include: Barb Maclean, VP Integration & Analytics, Celero Aya Ibrahim, Commercial Director, Paymob Mary Ann Azevedo, Senior Editor, TechCrunch We cover the following stories from the fintech and financial services space: Canadian Neo Financial's $185 million fund raise signals confidence in neobanks - 4:10 Egyptian fintech Paymob raises $50M led by PayPal Ventures and Kora Capital - 16:30 Tiger Global hit by $17bn losses in tech rout - 27:45 Sequoia, Binance and a16z among 19 investors backing Elon Musk's Twitter bid - 37:08 Stripe's Patrick Collison hits back at Plaid CEO's accusations - 46:30 Dutch fintech Bunq vies for Ulster Bank and KBC account holders - 48:32 Google Chrome is getting built-in virtual credit cards - 50:45 The Vatican Will Create an NFT Gallery to ‘Democratise Art' - 52:25 This episode is sponsored by Alto IRA Did you know the majority of people are investing in cryptocurrency through a taxable account, when they could be using an IRA and avoiding or deferring the taxes? With an Alto CryptoIRA, you can invest in crypto without tax headaches. Create a free account in minutes. Choose from over 150 coins, and invest with as little as $10. No setup charges and no account fees. To open an Alto CryptoIRA with as little as $10, just go to www.altoira.com/insider This episode is sponsored by TrueLayer Let's face it, cards were not designed for online. Payments can take days to settle, hurting customer loyalty. While high fraud, clunky checkouts and expensive fees mean millions in missed revenue. At TrueLayer, we've made instant payments available for businesses across Europe and the UK. So you can cut costs, fight fraud and get money moving fast. To learn more visit: www.TrueLayer.com/payments Fintech Insider by 11:FS is a podcast dedicated to all things fintech, banking, technology and financial services. It's hosted by a rotation of 11:FS experts including David M. Brear, Simon Taylor, Jason Bates and Gwera Kiwana, as well as a range of brilliant guests. We cover the latest global news, bring you interviews from industry experts or take a deep dive into subject matters such as APIs, AI or digital banking. If you enjoyed this episode, don't forget to subscribe and please leave a review Follow us on Twitter: @fintechinsiders where you can ask the hosts questions, or email podcasts@11fs.com! Special Guests: Aya Ibrahim, Barb MacLean, and Mary Ann Azevedo.

On today's episode of Empire, Joe Lallouz, Head of Coinbase Cloud, joins Jason and Santiago to discuss how Coinbase Cloud is building the AWS of crypto. Coinbase Cloud is building blockchain infrastructure and APIs that abstract the complexities of staking, data access, deployment and more. Joe explains the challenges of building in crypto, how Coinbase Cloud is taking on this challenge, and why developer tooling is critical for rapid innovation. We then discuss the importance of crypto's low switching costs, proof-of-stake systems, Lido's staking dominance, and Coinbase's approach to MEV. Blockchain infrastructure isn't the hot topic on Crypto Twitter, but it's the base layer of the entire ecosystem and will soon be a primary talking point. Don't miss this fantastic conversation to stay ahead of the blockchain infrastructure narrative! - - Follow Jason: https://twitter.com/JasonYanowitz Follow Joe: https://twitter.com/JoeLallouz Subscribe To Our YouTube Channel: https://tinyurl.com/4fdhhb2j Subscribe on Apple Podcasts: https://tinyurl.com/mv4frfv7 Subscribe on Spotify: https://tinyurl.com/wbaypprw -- ParaSwap: If you want to make a swap at the best price across the DeFi market, check out paraswap.io. ParaSwap's state-of-the-art algorithm beats the market price across all major DEXs and brings you the most optimized swaps with the best prices and lowest slippage. -- (00:00) Introduction (01:27) The AWS of Crypto (10:57) The Multichain Thesis (16:24) Bundling and Unbundling in Web3 (21:56) The Magic of Low Switching Costs (28:11) Move Fast and Don't Break Things (33:48) Building The Secure Foundation (35:19) Is Coinbase a Bridge? (37:27) Paraswap Ad (38:35) Is Lido a Threat to ETH? (45:40) A Coinbase ETH Staking Derivative (48:16) How Coinbase Approaches MEV (51:43) MEV's Moral Hazard (55:19) Blockchain On Demand (59:38) Why ApeCoin Doesn't Need Its Own Chain (1:03:11) Every Company Will Be a Crypto Company (1:06:08) Segments Ripe For Innovation -- Disclaimer: Nothing said on Empire is a recommendation to buy or sell securities or tokens. This podcast is for informational purposes only, and any views expressed by anyone on the show are solely our opinions, not financial advice. Santiago, Jason, and our guests may hold positions in the companies, funds, or projects discussed.

Our expert host, Simon Taylor, is joined by some great guests to ask: 'How did payroll data become the new gold rush?' Payroll data has become the topic of much hype over the last few years – from projected market values of over $10bn, to being referred to as the ‘holy grail of fintech'. So why are people so excited about something which has been in front of us the whole time? And in the midst of ‘The Great Resignation', will this gold rush last? This week's guest include: Ahmed Siddiqui, Head of Product, Branch Lindsay Davis, Head of Markets, Atomic Andrew Brown, Founder and CEO, Check This episode is sponsored by Alto IRA Did you know the majority of people are investing in cryptocurrency through a taxable account, when they could be using an IRA and avoiding or deferring the taxes? With an Alto CryptoIRA, you can invest in crypto without tax headaches. Create a free account in minutes. Choose from over 150 coins, and invest with as little as $10. No setup charges and no account fees. To open an Alto CryptoIRA with as little as $10, just go to www.altoira.com/insider This episode is sponsored by TrueLayer Let's face it, cards were not designed for online. Payments can take days to settle, hurting customer loyalty. While high fraud, clunky checkouts and expensive fees mean millions in missed revenue. At TrueLayer, we've made instant payments available for businesses across Europe and the UK. So you can cut costs, fight fraud and get money moving fast. To learn more visit: www.TrueLayer.com/payments Fintech Insider by 11:FS is a podcast dedicated to all things fintech, banking, technology and financial services. It's hosted by a rotation of 11:FS experts including David M. Brear, Simon Taylor, Jason Bates and Gwera Kiwana, as well as a range of brilliant guests. We cover the latest global news, bring you interviews from industry experts or take a deep dive into subject matters such as APIs, AI or digital banking. If you enjoyed this episode, don't forget to subscribe and please leave a review Follow us on Twitter: @fintechinsiders where you can ask the hosts questions, or email podcasts@11fs.com! Special Guests: Ahmed Siddiqui, Andrew Brown, and Lindsay Davis .

About PriyankaPriyanka Vergadia is currently a Staff  Developer Advocate at Google Cloud where she works with enterprises to build and architect their cloud platforms. She enjoys building engaging technical content and continuously experiments with new ways to tell stories and solve business problems using Google Cloud tools. You can check out some of the stories that she has created for the developer community on the Google Cloud Platform Youtube channel. These include "Deconstructing Chatbots", "Get Cooking in Cloud", "Pub/Sub Made Easy" and more. ..Links Referenced: LinkedIn: https://www.linkedin.com/in/pvergadia/ Twitter: https://twitter.com/pvergadia Priyanka's book: https://www.amazon.com/Visualizing-Google-Cloud-Illustrated-References/dp/1119816327 TranscriptAnnouncer: 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.Corey: Finding skilled DevOps engineers is a pain in the neck! And if you need to deploy a secure and compliant application to AWS, forgettaboutit! But that's where DuploCloud can help. Their comprehensive no-code/low-code software platform guarantees a secure and compliant infrastructure in as little as two weeks, while automating the full DevSecOps lifestyle. Get started with DevOps-as-a-Service from DuploCloud so that your cloud configurations are done right the first time. Tell them I sent you and your first two months are free. To learn more visit: snark.cloud/duplo. Thats's snark.cloud/D-U-P-L-O-C-L-O-U-D. Corey: What if there were a single place to get an inventory of what you're running in the cloud that wasn't "the monthly bill?" Further, what if there were a way to compare that inventory to what you were already managing via Terraform, Pulumi, or CloudFormation, but then automatically add the missing unmanaged or drifted parts to it? And what if there were a policy engine to immediately flag and remediate a wide variety of misconfigurations? Well, stop dreaming and start doing; visit snark.cloud/firefly to learn more.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. Periodically, I get the privilege of speaking to people who work in varying aspects of some would call it developer evangelism, some would call it developer advocacy, developer relations is a commonly accepted term, and I of course call it devrelopers because I enjoy annoying absolutely everyone by giving things terrible names. My guest today is Priyanka Vergadia, who is a staff developer advocate at Google Cloud. Priyanka, thank you for joining me.Priyanka: Thank you so much for having me. Corey. I'm so excited to be your developer—what did you call it again?Corey: Devreloper. Yes indeed.Priyanka: Devreloper. That is the term I'm going to be using from now on. I am a devreloper. Anyway.Corey: Excellent.Priyanka: Yeah.Corey: I'm starting to spread this out so that eventually we're going to form a giant, insufferable army of people who pronounce it that way, and it's going to be great.Priyanka: It's going to be awesome. [laugh].Corey: One of the challenges, even as I alluded to different titles within this space, everyone has a slightly different definition of where the role starts and stops, just in terms of its function, let alone the myriad ways that can be expressed. In the before times, I knew a number of folks in the developer advocacy space who were more or less worldwide experts in accumulating airline miles and racking up status and going from conference to conference to conference to more or less talk about things that had a tenuous at best connection to where they worked. Great. Other folks have done things in very different ways. Some people write extensively, blog posts and the rest, others build things a sample code, et cetera, et cetera.It seems like every time I talk to someone in the space, they have found some new and exciting way of carrying the message of what their company does to arguably a very cynical customer group. Where do you start and stop with your devrelopment?Priyanka: Yeah. So, that is such—like, all the devrelopers have their own style that they have either adopted or learned over time that works for them. When I started, I think about three years ago, I did go to conferences, did those events, give talks, all of that, but I was also—my actual introduction to DevRel [laugh] was with videos. I started creating my first series was deconstructing chatbots, and I was very interested in learning more about chatbots. So, I was like, you know what, I'm just going to teach everybody, and learn.So like, learn and teach at the same time was my motto, and that's kind of how I got started into, like, okay, I'm going to create a few videos to learn this and teach it. And during the process I was like, “I want to do this more.” And that's kind of transitioned, my move from being in front of customers, which I still end up doing, but I was doing more of just, you know, working with customers extensively to get their deployments done. This was a segue for me to, you know, think back, sit back and think about what's working and what I personally enjoy doing more, and that's what got me into creating videos. And it's like, okay, I'm going to become a devreloper now.And that's kind of how the whole, like, journey started. And for me, like you were pointing out earlier—should I just stop because I've been talking too long? [laugh].Corey: No, keep going. Please, [unintelligible 00:04:10] it's fine.Priyanka: [laugh]. For me, I started—I found my, I would say, in the last two years—it was all before the pandemic, we were all either writing blogs or doing videos or going to conferences, so it was, you know, the pandemic kind of brought us to a point where it's like, “Okay, let's think about—we can't meet each other; let's think about other ways to communicate and how can we make it creative and exciting?”Corey: And the old way started breaking down, too, where it's, “Yay, I'm going to watch an online conference.” “What is it?” “Oh, it's like a crappy Zoom only you don't have to pretend to pay attention in the same way.” And as a presenter, then you've got to modify what you're doing to understand that people's attention spans are shorter, distraction is always a browser tab away, and unlike a physical event, people don't feel the same sense of shame of getting up from the front row and weaving in front of 300 people, and not watching the rest of your talk. I mean, don't get me wrong, I'll still do it, but I'll feel bad about it.Now it's, “Oh, nope, I'm sitting here in my own little… hovel, I'm just going to do and watch whatever I want to do.” So, you've got to—it forces you to up your game, and it—Priyanka: Yep.Corey: Still doesn't quite have the same impact.Priyanka: Yeah. Or just switch off the camera, if you're like me, and just—uh, shut off the camera, go away or do something else. And, yeah, it's very easy to do that. So, it's not the same, which is why it prompted, I think all of us DevRel people to think about new ways to connect, which is for me that way to connect is art and visual aspects, to kind of bring that—because that—we are all whether we accept it or not or like it or not, we're all visual learners, so that's kind of how I think when it comes to creating content is visually appealing, and that's when people can dive in. [laugh].Corey: I am in the, I guess opposite side of the universe from you, where I acknowledge and agree with everything you're saying that people are visual creatures inherently, but I have effectively zero ability in that direction. My medium has always been playing games with words and language. And over time, I had the effectively significantly belated realization that wait a minute, just because I'm not good at a thing doesn't mean that other people might not be good at that thing, and I don't have to do every last part of it myself. Suddenly, I didn't have to do my own crappy graphic design because you can pay people who are worlds better than I'll ever be, and so on and so forth. I don't edit my own podcast audio because I'm bad at that, too.But talking about things is a different story, writing about things, building things is where I tend to see a lot of what I do tend to resonate. But I admit I bias for the things that I enjoy doing and the way that I enjoy consuming things. You do as well because relatively recently, as of time of this recording, you have done what I don't believe anyone actually wants to do. You wrote a book. Now, everyone wants to have written a book, but no one actually wants to write a book.Priyanka: So, true. [laugh].Corey: But it's not like most technical books. Tell me about it.Priyanka: Yeah, I actually never thought I would write a book. If you asked me two years ago—three years ago, I would say, I would have never thought that I would write a book because I am not a text person. So, I don't like to read a lot of texts because it zones out. So, for me, when I started creating some of these sketches, and sharing it on social media and in blogs and things like that, and gotten the attention that it has gotten from people, that's when I was like, okay, ding, ding, ding. I think I can do a visual book with these images.And this was like, halfway through, I'd already created, like, 30 sketches at this point. And I was like, “Okay, maybe I can turn this into a book,” which would be interesting for me because I like doing art-type things along with teaching, and it's not text because I wanted to do this in a very unique way. So yeah, that's kind of how it ended up happening.Corey: I have a keen appreciation for people who approach things with a different point of view. One of your colleagues, Forrest Brazeal, took a somewhat similar approach in the in his book, The Read Aloud Cloud, where it was illustrated, and everything he did was in rhyme, which is a constant source of envy for me, where it's, “Mmm, I've got to find a way to one-up him again.” And it's… he is inexorable, as far as just continuing to self-improve. So, all right, we're going to find a way to wind up defeating that. With you, it's way easier.I read a book, like, wow, this is gorgeous and well-written that it's attractive to look at, and I will never be able to do any of those things. That's all you. It doesn't feel like we're trying to stand at the same spot in the universe in quite the same way. Nothing but love for Forrest. Let's be clear. I am teasing. I consider him a friend.Priyanka: He is amazing. Well honestly, like, I actually got to know Forrest when I decided to do this book. Wiley, who's the publisher, sent me Forrest's book, and he said, “You should look at this book because the idea that you are presenting to me, we could lay it out in this format.” Like, in the, you know, physical format. So, he sent me that book. And that's how I know Forrest, honestly.So, I told him that—this is a little story that I told him after. But anyway, yeah. I—the—[sigh]—I was going to make a point about the vid—the aspect of creating images, like, honestly, like, I designed the aspects of, like, how you layout information in the sketches, I studied a bunch of stuff to come up with, how do I make it precise and things like that. But there's no way this book was possible without some design help. Like, I can't possibly do the entire thing unless I have, like, five years. [laugh]. So—Corey: Right on top of all of this, you do presumptively have a day job as well—and while—Priyanka: Exactly.Corey: This is definitely related. “I'm just going to go write a book.” “Oh, is it a dissertation?” “No, it's going to look more like a children's book than that,” is what they're going to hear. And it's yeah, I'm predicting some problems with the performance evaluation process at large companies when you start down those paths.Priyanka: Exactly. So, I ended up, like, showing all these numbers, like, of the blog views and reads and social media, the presence of some of these images that were going wider. And in the GCPSketchnote GitHub repo got a huge number of stars. And it was like, everybody could see that writing a book would be amazing. From that point on, I was just like, I don't think I can scale that.So, when I was drawing—this is an example—when I drew my first sketch, it took me an entire weekend to just draw one sketch, which is what—I was only doing that the entire weekend—like, assume, like, 16 hours of work, just drawing the one sketch. So, if I went with that pace, this book was not possible. So, you know, after I had the idea laid out, had the process in place, I got some design help, which made it—which expedited the process much, much faster. [laugh].Corey: There's a lot to be said, for doing something that you enjoy. Do you do live sketchnoting during conference talks as well, or do you tend to not do it while someone is talking at a reasonably fast clip, and well, in 45 minutes, this had better be done, so let's go. I've seen people who can do that, and I just marvel in awe at what they do.Priyanka: I don't do live. I don't do live sketching. For me, paper and pen is a better medium so that's just the medium that I like to work with. So, when the talk is happening, I'm actually taking notes on a pen and a paper. And then after, I can sketch it out, faster in a fast way.Like, I did one sketchnote for Next 2020, I think, and that was done, like, a day after Next was over so I could take all the bits and pieces that were important and put it into that sketch. But I can't do it live. That's just one of the things I haven't figured out yet. [laugh].Corey: For me, I was always writing my email newsletter, so it was relatively rapid turnaround, and Twitter was interesting for me. I finally cracked the nut on how to express myself in a way that worked. The challenge that I ran into then was okay, there are thoughts I occasionally have that don't lend themselves to then 140—now 280—characters, so I should probably start writing long-form. And then I want to start writing 1000 to 1500-word blog posts every week that goes out. And that forced me to become a better writer across the board. And then it became about one-upping myself, sort of, live-tweeting conference talks.And the personal secret of why I do that is I'm ADHD in a bottle. Someone gets on stage—you say you zone out when you read a giant quantity of data; you prefer something more visual, more interactive. For me, I'm the opposite, where when someone gets on stage and starts talking, it's, “Okay, get to—yes, you're doing the intro of what a cloud might be. I get that point. This is supposed to be a more advanced talk. Can we speed it up a bit?”And doing the live-tweeting about it, but not just relating what is said, but by making a joke about it, it's how I keep myself engaged and from zoning out. Because let's face it, this industry is extraordinarily boring, if you don't bring a little bit of light to it.Priyanka: Yeah, that is—Corey: And that how to continue and how to do that was hard, and it took me time to get there.Priyanka: Yeah. Yeah, no, I totally agree. Like, that's exactly why I got into, like, training videos and sketches. Like, and videos and also. Like, I come up with, like, fake examples of companies that may or may not exist.Like, I made up a dog shoe making company that ships out shoes when you need them and then return them and there's a size and stuff, like, you have to come up with interesting things to make the content interesting because otherwise, this can get boring pretty quickly, which is going back to your example of, “Speed it up; get to the point.” [laugh].Corey: This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on premises, private cloud, and they just announced a fully managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half dozen manage databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications, including Oracle, to the cloud.To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: It's always just fun to start experimenting with it, too, because all right, once I was done learn learning how to live-tweet other people's talk and mostly get it correct because someone says something, I have three to five seconds to come up with what I want to talk about and maybe grab a picture and then move on to the next thing. And it's easy to get that wrong and say things you don't necessarily intend to and get taken the wrong way. I've mostly gotten past that. And—I'm not saying I'm always right, but I better than I used to be. And then it was okay, “How do I top this?”And I started live-tweeting conference talks that I was giving live, which is always fun, but being able to pre-write some tweets at certain times, have certain webhooks in your slide deck and whatnot that fire these things off. And again, I'm not saying that he this is recommended or even a good idea, but it definitely wasn't boring. And—Priyanka: Yeah.Corey: And continue to find ways to make the same type of material new and interesting is one of the challenges because the stuff is complex.Priyanka: Also bite-size, right? Like, it's—I think Twitter is, like, the [unintelligible 00:15:54] words are obviously limiting, but it also forces you to think about it in bite-size, right? Like, okay, if I have a blog post then I'm summarizing it, how would I do it in two sentences? It forces me to think about it that way, which makes it very applicable to the time span that we have now, right, which is maybe, like, 30 seconds, you can have somebody on [unintelligible 00:16:18]Corey: Attention is a rare and precious commodity.Priyanka: Yeah. Yeah.Corey: People who [unintelligible 00:16:21] engagement, I think that's the wrong metric to go after because that inspires a whole bunch of terrible incentives, whereas finding something that is interesting, and a way to bring light to it and have a perspective on it that makes people think about it differently. For me, it's been humor, but that's my own approach to things. Your direction, it seems to be telling a story through visual arts. And that is something we don't see nearly as much of.Priyanka: Yeah. I think it's also because it's something that you—you know, like, I grew up drawing and painting. I was drawing since I was three years old, so that's my way of thinking. Like, I don't—I was talking to another devreloper the other day, and we were talking about—Corey: It's catching on. I love it.Priyanka: —[laugh]. Two different ways of how we think. So, for me, when I design a piece of content, I have my visuals first, and then he was talking about when he designs his content, he has his bullet points and a blog post first. So, it's like, two very different ways of approaching this similar thing. And then from that, from the images or the deck that I'm building up, I would come up with the narrative and stuff like that.My thinking starts with images and narrative of tying, like, the images together. But it's, that is the whole, like, fun of being in DevRel, right? Like, you are your own personality, and bringing whatever your personality, like you mentioned, humor and your case, art in my case, in somebody else's case, it could be totally different thing, right? So, yeah.Corey: Now, please correct me if I'm wrong on this, but an area of emphasis for you has been data analytics as well as Kubernetes, more or less things that are traditionally considered to be much more back-end if you're looking at a spectrum of all things technology. Is that directionally accurate, or am I dramatically is understanding a lot of what you're saying?Priyanka: No, that's very much accurate. I like to—I tend to be on the infrastructure back-and creating pipeline, creating easier processes, sort of person, not much into front-end. I dabble into it, but don't enjoy it. [laugh].Corey: This makes you something of a unicorn, in the sense of there are a tremendous number of devreloper types in the front-end slash JavaScript world because their entire career is focused on making things look visually appealing. That is what front-end is. I know this because I am rubbish at it. My idea of a well-designed interface that everyone looks at and smiles at [unintelligible 00:19:12] of command-line arguments when you're writing a script for something. And it's on a green screen, and sometimes I'll have someone helped me coordinate to come up with a better color palette for the way that I'm looking at my terminal on my Mac. Real exciting times over here, I assure you.So, the folks who are working in that space and they have beautifully designed slides, yeah, you tend to expect that. I gave a talk years ago at the front-end conference in Zurich, and I was speaking in the afternoon. And I went there and every presentation, slides were beautiful. And this was before I was working here and had a graphic designer on retainer to make my slides look not horrible. It was black Helvetica text on a white background, and I'm looking at this and I'm feeling ashamed that it's—okay, I have two hours to fix this. What do I do?I did the only thing I could think of; I changed Helvetica text to Comic Sans because if it's going to look terrible and it's going to be a designer thing that puts them off, you may as well go all-in. And that was a recurring meme at the time. I've since learned that there is an argument—I don't know if it's true or not—that Comic Sans is easier to read for folks with dyslexia, for example. And that's fine. I don't know if that's accurate or not, but I stopped making jokes about it just because if people—even if it's not true, and people believe that it's, “Are you being unintentionally crappy to people?” It's, “Well, I sure hope not. I'm rarely intentionally crappy. But when I do, I don't want to be mistaken for not being.” It's, save it up and use it when it counts.Priyanka: Yeah, yeah. I've—yeah, I think, when it comes to these big events—and like front-end for me is—I would think, like, I actually thought that I would be great at front-end because I have interest in art and stuff. I do make things that [crosstalk 00:20:57]—Corey: That's my naive assumption, too. I'm learning as you speak here. Please continue[.Priyanka: Yeah. And I was just—I thought that I would be and I have tried it, and I only like it to an extent, to present my idea. But I don't like to go in deeper and, like, make my CSS pretty or make this—make it look pretty. I am very much intrigued by all the back-end stuff, and most of my experience, over the past ten years in Cloud has been in the back-end stuff, mainly just because I love APIs, I love—like, you know, as long as I can connect, or the idea of creating a demo or something that involves a bunch of APIs and a back-end, to present an idea in a front-end, I would work on that front-end. But otherwise, I'm not going to choose to do it. [laugh]. Which I found interesting for myself as well. It's a realization. [laugh].Corey: Every time I try and do something with front-end, it doesn't matter the framework, I find myself more confused at the end than I was when I started. There's something I don't get. And anytime I see someone on Twitter, for example, talking about how a front-end is easier or somehow less than, I read that and I can't help myself. It's, “You ridiculous clown. You have no idea what you're talking about.”I don't believe that I'm bad at all of the things under engineering—just most of them—and I think I pick things up reasonably quickly. It is a mystery that does not align with this, and if it's easy for you, you don't recognize—arguably—a skill that you have, but not everyone does, by a landslide. And that's a human nature thing, too. It's if it was easy for me, it's obviously easy for everyone. If something's hard for me, no one would understand how this works and the people that do are wizards from the future.Priyanka: Yep. So true.Corey: It never works that way.Priyanka: Yeah. It never works that way. At least we have this in common, that you don't like to work on front-ends. [laugh].Corey: There's that too. And I think that no matter where you fall on the spectrum of technology, I would argue that something that we all share in common is, it doesn't matter how far we are down in the course of our entire career, from the very beginning to the very end, it is always a consistent, constant process of being humbled and made to feel like a fool by things you are supposedly professionally good at. And oh my stars, I've just learned to finally give up and embrace it. It's like, “So, what's going to make me feel dumb today?”Priyanka: Exactly.Corey: It's the learn in public approach, which is important.Priyanka: It's so important. Especially, like, if you're thinking about it, like that's the part of DevRel that makes it so exciting, too, right? Like, just learning a new thing today and sharing it with you. Like, I'm not claiming that I'm an expert, but hey, let's talk about it. And sure, I might end up looking dumb one day, I might end up looking smart the other day, but that's not the point. The point is, I end up learning every day, right? And that's the most important part, which is why I love this particular job, which is—what did we call it—devreloper.Corey: Devreloping. And as a part of that, you're talking to people constantly, be it people in the community and ecosystem, people who—you say you've talk to customers, but you also talk to these other folks. I would challenge you on that, where when you're at a company like Google Cloud, increasingly everyone in the community in the ecosystem is in one way or another, indistinguishable from being your customer; it all starts to converge at some point. All major cloud providers have that luxury, to be perfectly honest. What do you see in the ecosystem that people are struggling with as you talk to them?And again, any one person is going to have a problem or bone to pick with some particular service or implementation, and okay, great. What I'm always interested in is what is the broad sweep of things? Because when I hear someone complaining that a given service from a given cloud provider is terrible. Okay, great. Everyone has an opinion. When I started to hear that four or five, six times, it's okay, there's something afoot here, and now I'm curious as to what it is. What patterns are you seeing emerge these days?Priyanka: Yeah. I think more and more patterns along the lines of how can you make it automated? How can you make anything automated, right? Like, from machine learning's perspective, how do I not need ML skills to build an ML model? Like, how can we get there faster, right?Same for, like, in the infrastructure side, the serverless… aspect? How can you make it easy for me so I can just build an application and just deploy it so it becomes your problem to run it and not mine?Corey: Oh, the—you are preaching to the choir on that. I feel like all of these services that talk about, “This is how you build and train a machine learning model,” yadda, yadda, it's for an awful lot of the use cases out there, it's exposing implementation details about which I could not possibly care less. It's the, I want an API that I throw something at—like, be it a picture—and then I want to get a response of, “Yes, it's a hot dog,” or, “That's disgusting,” or whatever it is that it decides that it wants to say, great because that's the business outcome I'm after, and I do not care what wizardry happens on the back-end, I don't care if it's people who are underpaid and working extremely quickly by hand to do it, as long as it's from a business perspective, it hits a certain level of performance, reliability, et cetera. And then price, of course, yeah.And that is not to say I'm in favor of exploiting people, let's be clear here because I'm pretty sure most of these are not actually humans on the back-end, but okay. I just want that as the outcome that I think people are after, and so much of the conversation around how to build and train models and all misses the point because there are companies out there that need that, absolutely, there are, but there are a lot more that need the outcome, not the focus on this. And let's face it, an awful lot of businesses that would benefit from this don't have the budget to hire the team of incredibly expensive people it takes to effectively leverage these things because I have an awful lot of observations about people in machine learning space, one of them is absolutely not that, “Wow, I bet those people are inexpensive for me to hire.” It doesn't work that way.Priyanka: It doesn't. Yeah. And so, yeah. I think the future of, like, the whole cloud space, like, when it started, we started with how can I run my server not in my basement, but somewhere else, right? Now, we are at a different stage where we have a different sets of problems and requirements for businesses, right?And that's where I see it growing. It's like, how can I make this automated fast, not my problem? How can I make it not my problem is, like, the biggest [laugh] biggest, I think, theme that we are seeing, whether it's infrastructure, data science, data analytics, in all of these spaces.Corey: I get a lot of interesting feedback for my comparative takes on the various cloud providers, and one thing that I've said for a while about Google Cloud has been that its developer experience is unparalleled compared to basically anything else on the market. It makes things just work, and that's important because a bad developer experience has the unfortunate expression—at least for me—of, “Oh, this isn't working the way I want it to. I must be dumb.” No, it's a bad user experience for you. What I am seeing emerge as well from Google Cloud is an incredible emphasis—and I do think they're aligned here—on storytelling, and doing so effectively.You're there communicating visually; Forrest is there, basically trying to be the me of Google Cloud—which is what I assume he's doing; he would argue everything about that and he'd be right to do it, but that's what I'm calling it because this is my show; he can come on and argue with me himself if he takes issue with it. But I love the emphasis on storytelling and unifying solutions and the rest, as opposed to throwing everything at the wall to see what sticks to it. I think there's more intention being put into an awful lot of not just what you're building, but how you're talking about it, now it's integrated with the other things that you're building. That's no small thing.Priyanka: Yeah. That is so hard, especially when you know the cloud space; like, hundreds of products, they all have their unique requirement to solve a problem, but nobody cares, right? Like, as a consumer, I shouldn't have to care that there are 127 products or whatever. It doesn't matter to me as a consumer or customer, all that matters is whether I can solve my business problem with a set of your tools, right? So, that's exactly why, like, we have this team that I work in that I'm a part of, which has an entire focus on storytelling.We do YouTube videos with storytelling, we do art like this, I've also dabbled into comics a little bit. And we continue to go back to the drawing board with how else we can tell these stories. I know—I mentioned this to Forrest—I'm working on a song as well, which I have never done before, and [laugh] I think I'm going to butcher it. I kind of have it ready for, like, six months but never released it, right, because I'm just too scared to do that. [laugh] but anyway.Corey: Ship and then turn the internet off for a week and it'll be gone regardless, by the time you come back. Problem solved until the reporters start calling, and then you have problems.Priyanka: I might have to just do that, and be, like, you know what world? Keep saying whatever you want to say, I'm not here. [laugh]. But anyway, going back to that point of storytelling, and it's so—I think we have weaved it into the process. And it's going really well, and now we are investing more in, like, R&D and doing more of how we can tell stories in different ways.Corey: I have to say, I'm a big fan of the way that you're approaching this. If people want to learn more about what you're up to—and arguably, as I argue they should get a copy of your book because it is glorious—where's the best place to find you?Priyanka: Thank you. Okay, so LinkedIn and Twitter are my platforms that I check every single day, so you can message me, connect with me, I am available as—my handle is pvergadia. I don't know if they have [crosstalk 00:31:11]—Corey: Oh, this is all going in the [show notes 00:31:13] you need not worry.Priyanka: Okay, perfect. So yeah, I don't have to spell it because my last name is hard. [laugh]. So, you'll find it in the show notes. But yeah, you can connect with me there. And you will find at the top of both of my profiles, the link to order the book, so you can do it there.Corey: Excellent. And I've already done so, and I'm just waiting for it to arrive. So, this is—it's going to be an exciting read if nothing else. One of these days, I'd have to actually live-tweet a reading thereof. We'll see how that plays out.Priyanka: That would be amazing.Corey: Be careful what you wish for. Some of the snark could be a little too cutting; we have to be cautious of that.Priyanka: [laugh]. I'm always scared of your tweets. Like, do I want to read this or not? [laugh].Corey: If nothing else, it at least tries to be funny. So, there is that.Priyanka: Yes. Yes, for sure.Corey: I really—Priyanka: No, I'm excited. I'm excited for when you get a chance to read it and just tweet whatever you feel like, from, you know, all the bits and pieces that I've brought together. So, I would love to get your take. [laugh].Corey: Oh, you will, one way or another. That's one of those non-optional things. It's one of the fun parts of dealing with me. It's, “Aw crap. That shitposter is back again.” Like the kid outside of your yard just from across the street, staring at your house and pointing and it's, “Oh, dear. Here we go.” Throwing stones.Priyanka: [laugh]. I'm excited either way. [laugh].Corey: He's got a platypus with him this time. What's going on? It happens. We deal with what we have to. Thank you so much for being so generous with your time. I appreciate it.Priyanka: Thank you so much for having me. It was amazing. You are a celebrity, and I wanted to be, you know, a part of your show for a long time, so I'm glad we're able to make it work.Corey: You are welcome back anytime.Priyanka: I will. [laugh].Corey: An absolute pleasure to talk with you. Thanks again.Priyanka: Thank you.Corey: Priyanka Vergadia staff developer—but you call it developer advocate—at Google Cloud. 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 whatever platform you're using to listen to this thing, whereas if you've hated it, please do the exact same thing, making sure to hit the like and subscribe buttons on the YouTubes because that's where it is. But if you did hate it, also leave an insulting, angry comment but not using words. I want you to draw a picture telling me exactly what you didn't like about this episode.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Watch the live stream: Watch on YouTube About the show Sponsored: RedHat: Compiler Podcast Special guest: Tonya Sims Michael #1: Pathy: a Path interface for local and cloud bucket storage via Spencer Pathy is a python package (with type annotations) for working with Cloud Bucket storage providers using a pathlib interface. It provides an easy-to-use API bundled with a CLI app for basic file operations between local files and remote buckets. It enables a smooth developer experience by letting developers work against the local file system during development and only switch over to live APIs for deployment. Also has optional local file caching. From Spenser The really cool function is "Pathy.fluid" which can take any type of local, GCS, or S3 path string and then just give you back a Path object that you can interact with agnostic of what platform it was. So this has worked amazingly for me in local testing since i can just change the file path from the "s3://bucket/path" that i use in prod to a local "test_dir/path" and it works automatically. Brian #2: Robyn “Robyn is a fast, high-performance Python web framework with a Rust runtime.” Hello, Robyn! - intro article docs, repo Neat things doesn't need WSGI or ASGI async very Flask-like Early, so still needs some TLC docs, etc. getting started and demo apps would be good. Tonya #3: Python package 'nba_api' is a package to access data for NBA.com This package is maintained by Swar Patel API Client package for NBA.com, more accessible endpoints, and better documentation The NBA.com API's are not well documented and change frequently (player traded, injured, retired, points per game, stats, etc) The nba_api package has tons of features: The nba_api starts with static data on players and teams (Full name, team name, etc). Each player and Team has an id. Can get game data from the playergamelog API endpoint The package also has many different API endpoints that it can hit by passing in features from the static data to the API endpoints as parameters Michael #4: Termshot From Jay Miller Creates screenshots based on terminal command output Just run termshot YOUR_CMD or termshot --show-cmd -- python program.py Even termshot /bin/zsh for full interactive “recording” Example I made: Brian #5: When Python can't thread: a deep-dive into the GIL's impact Itamar Turner-Trauring Building a mental model of the GIL using profiler graphs of simple two thread applications. The graphs really help a lot to see when the CPU is active or waiting on each thread. Tonya #6: Sportsipy: A free sports API written for python Free python API that pulls the stats from www.sports-reference.com sports-reference.com - great website for getting sports stats for professional sports(NBA, NFL, NHL, MLB, college sports) Looks like an HTML website for the 90s - great for scraping (email site owners) You can get API queries for every sport (North American sports) like the list of teams for that sport, the date and time of a game, the total number of wins for a team during the season, and many more team-related metrics. You can also get stats from players and box scores - so you can build cool stuff around how a team performed during a game or during a season. Extras Michael: Python 3.11.0 beta 1 is out Test with GitHub Actions against Python 3.11 Joke: Finding my family

About AmyAmy Tobey has worked in tech for more than 20 years at companies of every size, working with everything from kernel code to user interfaces. These days she spends her time building an innovative Site Reliability Engineering program at Equinix, where she is a principal engineer. When she's not working, she can be found with her nose in a book, watching anime with her son, making noise with electronics, or doing yoga poses in the sun.Links Referenced: Equinix Metal: https://metal.equinix.com Personal Twitter: https://twitter.com/MissAmyTobey Personal Blog: https://tobert.github.io/ TranscriptAnnouncer: 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.Corey: This episode is sponsored in part by our friends at Vultr. Optimized cloud compute plans have landed at Vultr to deliver lightning-fast processing power, courtesy of third-gen AMD EPYC processors without the IO or hardware limitations of a traditional multi-tenant cloud server. Starting at just 28 bucks a month, users can deploy general-purpose, CPU, memory, or storage optimized cloud instances in more than 20 locations across five continents. Without looking, I know that once again, Antarctica has gotten the short end of the stick. Launch your Vultr optimized compute instance in 60 seconds or less on your choice of included operating systems, or bring your own. It's time to ditch convoluted and unpredictable giant tech company billing practices and say goodbye to noisy neighbors and egregious egress forever. Vultr delivers the power of the cloud with none of the bloat. “Screaming in the Cloud” listeners can try Vultr for free today with a $150 in credit when they visit getvultr.com/screaming. That's G-E-T-V-U-L-T-R dot com slash screaming. My thanks to them for sponsoring this ridiculous podcast.Corey: Finding skilled DevOps engineers is a pain in the neck! And if you need to deploy a secure and compliant application to AWS, forgettaboutit! But that's where DuploCloud can help. Their comprehensive no-code/low-code software platform guarantees a secure and compliant infrastructure in as little as two weeks, while automating the full DevSecOps lifestyle. Get started with DevOps-as-a-Service from DuploCloud so that your cloud configurations are done right the first time. Tell them I sent you and your first two months are free. To learn more visit: snark.cloud/duplo. Thats's snark.cloud/D-U-P-L-O-C-L-O-U-D.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while I catch up with someone that it feels like I've known for ages, and I realize somehow I have never been able to line up getting them on this show as a guest. Today is just one of those days. And my guest is Amy Tobey who has been someone I've been talking to for ages, even in the before-times, if you can remember such a thing. Today, she's a Senior Principal Engineer at Equinix. Amy, thank you for finally giving in to my endless wheedling.Amy: Thanks for having me. You mentioned the before-times. Like, I remember it was, like, right before the pandemic we had beers in San Francisco wasn't it? There was Ian there—Corey: Yeah, I—Amy: —and a couple other people. It was a really great time. And then—Corey: I vaguely remember beer. Yeah. And then—Amy: And then the world ended.Corey: Oh, my God. Yes. It's still March of 2020, right?Amy: As far as I know. Like, I haven't checked in a couple years.Corey: So, you do an awful lot. And it's always a difficult question to ask someone, so can you encapsulate your entire existence in a paragraph? It's—Amy: [sigh].Corey: —awful, so I'd like to give a bit more structure to it. Let's start with the introduction: You are a Senior Principal Engineer. We know it's high level because of all the adjectives that get put in there, and none of those adjectives are ‘associate' or ‘beginner' or ‘junior,' or all the other diminutives that companies like to play games with to justify paying people less. And you're at Equinix, which is a company that is a bit unlike most of the, shall we say, traditional cloud providers. What do you do over there and both as a company, as a person?Amy: So, as a company Equinix, what most people know about is that we have a whole bunch of data centers all over the world. I think we have the most of any company. And what we do is we lease out space in that data center, and then we have a number of other products that people don't know as well, which one is Equinix Metal, which is what I specifically work on, where we rent you bare-metal servers. None of that fancy stuff that you get any other clouds on top of it, there's things you can get that are… partner things that you can add-on, like, you know, storage and other things like that, but we just deliver you bare-metal servers with really great networking. So, what I work on is the reliability of that whole system. All of the things that go into provisioning the servers, making them come up, making sure that they get delivered to the server, make sure the API works right, all of that stuff.Corey: So, you're on the Equinix cloud side of the world more so than you are on the building data centers by the sweat of your brow, as they say?Amy: Correct. Yeah, yeah. Software side.Corey: Excellent. I spent some time in data centers in the early part of my career before cloud ate that. That was sort of cotemporaneous with the discovery that I'm the hardware destruction bunny, and I should go to great pains to keep my aura from anything expensive and important, like, you know, the SAN. So—Amy: Right, yeah.Corey: Companies moving out of data centers, and me getting out was a great thing.Amy: But the thing about SANs though, is, like, it might not be you. They're just kind of cursed from the start, right? They just always were kind of fussy and easy to break.Corey: Oh, yeah. I used to think—and I kid you not—that I had a limited upside to my career in tech because I sometimes got sloppy and I was fairly slow at crimping ethernet cables.Amy: [laugh].Corey: That is very similar to growing up in third grade when it became apparent that I was going to have problems in my career because my handwriting was sloppy. Yeah, it turns out the future doesn't look like we predicted it would.Amy: Oh, gosh. Are we going to talk about, like, neurological development now or… [laugh] okay, that's a thing I struggle with, too right, is I started typing as soon as they would let—in fact, before they would let me. I remember in high school, I had teachers who would grade me down for typing a paper out. They want me to handwrite it and I would go, “Cool. Go ahead and take a grade off because if I handwrite it, you're going to take two grades off my handwriting, so I'm cool with this deal.”Corey: Yeah, it was pretty easy early on. I don't know when the actual shift was, but it became more and more apparent that more and more things are moving towards a world where you could type. And I was almost five when I started working on that stuff, and that really wound up changing a lot of aspects of how I started seeing things. One thing I think you're probably fairly well known for is incidents. I want to be clear when I say that you are not the root cause as—“So, why are things broken?” “It's Amy again. What's she gotten into this time?” Great.Amy: [laugh]. But it does happen, but not all the time.Corey: Exa—it's a learning experience.Amy: Right.Corey: You've also been deeply involved with SREcon and a number of—a lot of aspects of what I will term—and please don't yell at me for this—SRE culture—Amy: Yeah.Corey: Which is sometimes a challenging thing to wind up describing or putting a definition around. The one that I've always been somewhat partial to is, “SRE is DevOps, except you worked at Google for a while.” I don't know how necessarily accurate that is, but it does rile people up.Amy: Yeah, it does. Dave Stanke actually did a really great talk at SREcon San Francisco just a couple weeks ago, about the DORA report. And the new DORA report, they split SRE out into its own function and kind of is pushing against that old model, which actually comes from Liz Fong-Jones—I think it's from her, or older—about, like, class SRE implements DevOps, which is kind of this idea that, like, SREs make DevOps happen. Things have evolved, right, since then. Things have evolved since Google released those books, and we're all just figured out what works and what doesn't a little bit.And so, it's not that we're implementing DevOps so much. In fact, it's that ops stuff that kind of holds us back from the really high impact work that SREs, I think, should be doing, that aren't just, like, fixing the problems, the symptoms down at the bottom layer, right? Like what we did as sysadmins 20 years ago. You know, we'd go and a lot of people are SREs that came out of the sysadmin world and still think in that mode, where it's like, “Well, I set up the systems, and when things break, I go and I fix them.” And, “Why did the developers keep writing crappy code? Why do I have to always getting up in the middle of the night because this thing crashed?”And it turns out that the work we need to do to make things more reliable, there's a ceiling to how far away the platform can take us, right? Like, we can have the best platform in the world with redundancy, and, you know, nine-way replicated data storage and all this crazy stuff, and still if we put crappy software on top, it's going to be unreliable. So, how do we make less crappy software? And for most of my career, people would be, like, “Well, you should test it.” And so, we started doing that, and we still have crappy software, so what's going on here? We still have incidents.So, we write more tests, and we still have incidents. We had a QA group, we still have incidents. We send the developers to training, and we still have incidents. So like, what is the thing we need to do to make things more reliable? And it turns out, most of it is culture work.Corey: My perspective on this stems from being a grumpy old sysadmin. And at some point, I started calling myself a systems engineer or DevOps or production engineer, or SRE. It was all from my point of view, the same job, but you know, if you call yourself a sysadmin, you're just asking for a 40% pay cut off the top.Amy: [laugh].Corey: But I still tended to view the world through that lens. I tended to be very good at Linux systems internals, for example, understanding system calls and the rest, but increasingly, as the DevOps wave or SRE wave, or Google-isation of the internet wound up being more and more of a thing, I found myself increasingly in job interviews, where, “Great, now, can you go wind up implementing a sorting algorithm on the whiteboard?” “What on earth? No.” Like, my lingua franca is shitty Bash, and no one tends to write that without a bunch of tab completions and quick checking with manpages—die.net or whatnot—on the fly as you go down that path.And it was awful, and I felt… like my skill set was increasingly eroding. And it wasn't honestly until I started this place where I really got into writing a fair bit of code to do different things because it felt like an orthogonal skill set, but the fullness of time, it seems like it's not. And it's a reskilling. And it made me wonder, does this mean that the areas of technology that I focused on early in my career, was that all a waste? And the answer is not really. Sometimes, sure, in that I don't spend nearly as much time worrying about inodes—for example—as I once did. But every once in a while, I'll run into something and I looked like a wizard from the future, but instead, I'm a wizard from the past.Amy: Yeah, I find that a lot in my work, now. Sometimes things I did 20 years ago, come back, and it's like, oh, yeah, I remember I did all that threading work in 2002 in Perl, and I learned everything the very, very, very hard way. And then, you know, this January, did some threading work to fix some stability issues, and all of it came flooding back, right? Just that the experiences really, more than the code or the learning or the text and stuff; more just the, like, this feels like threads [BLEEP]-ery. Is a diagnostic thing that sometimes we have to say.And then people are like, “Can you prove it?” And I'm like, “Not really,” because it's literally thread [BLEEP]-ery. Like, the definition of it is that there's weird stuff happening that we can't figure out why it's happening. There's something acting in the system that isn't synchronized, that isn't connected to other things, that's happening out of order from what we expect, and if we had a clear signal, we would just fix it, but we don't. We just have, like, weird stuff happening over here and then over there and over there and over there.And, like, that tells me there's just something happening at that layer and then have to go and dig into that right, and like, just basically charge through. My colleagues are like, “Well, maybe you should look at this, and go look at the database,” the things that they're used to looking at and that their experiences inform, whereas then I bring that ancient toiling through the threading mines experiences back and go, “Oh, yeah. So, let's go find where this is happening, where people are doing dangerous things with threads, and see if we can spot something.” But that came from that experience.Corey: And there's so much that just repeats itself. And history rhymes. The challenge is that, do you have 20 years of experience, or do you have one year of experience repeated 20 times? And as the tide rises, doing the same task by hand, it really is just a matter of time before your full-time job winds up being something a piece of software does. An easy example is, “Oh, what's your job?” “I manually place containers onto specific hosts.” “Well, I've got news for you, and you're not going to like it at all.”Amy: Yeah, yeah. I think that we share a little bit. I'm allergic to repeated work. I don't know if allergic is the right word, but you know, if I sit and I do something once, fine. Like, I'll just crank it out, you know, it's this form, or it's a datafile I got to write and I'll—fine I'll type it in and do the manual labor.The second time, the difficulty goes up by ten, right? Like, just mentally, just to do it, be like, I've already done this once. Doing it again is anathema to everything that I am. And then sometimes I'll get through it, but after that, like, writing a program is so much easier because it's like exponential, almost, growth in difficulty. You know, the third time I have to do the same thing that's like just typing the same stuff—like, look over here, read this thing and type it over here—I'm out; I can't do it. You know, I got to find a way to automate. And I don't know, maybe normal people aren't driven to live this way, but it's kept me from getting stuck in those spots, too.Corey: It was weird because I spent a lot of time as a consultant going from place to place and it led to some weird changes. For example, “Oh, thank God, I don't have to think about that whole messaging queue thing.” Sure enough, next engagement, it's message queue time. Fantastic. I found that repeating myself drove me nuts, but you also have to be very sensitive not to wind up, you know, stealing IP from the people that you're working with.Amy: Right.Corey: But what I loved about the sysadmin side of the world is that the vast majority of stuff that I've taken with me, lives in my shell config. And what I mean by that is I'm not—there's nothing in there is proprietary, but when you have a weird problem with trying to figure out the best way to figure out which Ruby process is stealing all the CPU, great, turns out that you can chain seven or eight different shell commands together through a bunch of pipes. I don't want to remember that forever. So, that's the sort of thing I would wind up committing as I learned it. I don't remember what company I picked that up at, but it was one of those things that was super helpful.I have a sarcastic—it's a one-liner, except no sane editor setting is going to show it in any less than three—of a whole bunch of Perl, piped into du, piped into the rest, that tells you one of the largest consumers of files in a given part of the system. And it rates them with stars and it winds up doing some neat stuff. I would never sit down and reinvent something like that today, but the fact that it's there means that I can do all kinds of neat tricks when I need to. It's making sure that as you move through your career, on some level, you're picking up skills that are repeatable and applicable beyond one company.Amy: Skills and tooling—Corey: Yeah.Amy: —right? Like, you just described the tool. Another SREcon talk was John Allspaw and Dr. Richard Cook talking about above the line; below the line. And they started with these metaphors about tools, right, showing all the different kinds of hammers.And if you're a blacksmith, a lot of times you craft specialized hammers for very specific jobs. And that's one of the properties of a tool that they were trying to get people to think about, right, is that tools get crafted to the job. And what you just described as a bespoke tool that you had created on the fly, that kind of floated under the radar of intellectual property. [laugh].So, let's not tell the security or IP people right? Like, because there's probably billions and billions of dollars of technically, like, made-up IP value—I'm doing air quotes with my fingers—you know, that's just basically people's shell profiles. And my God, the Emacs automation that people have done. If you've ever really seen somebody who's amazing at Emacs and is 10, 20, 30, maybe 40 years of experience encoded in their emacs settings, it's a wonder to behold. Like, I look at it and I go, “Man, I wish I could do that.”It's like listening to a really great guitar player and be like, “Wow, I wish I could play like them.” You see them just flying through stuff. But all that IP in there is both that person's collection of wisdom and experience and working with that code, but also encodes that stuff like you described, right? It's just all these little systems tricks and little fiddly commands and things we don't want to remember and so we encode them into our toolset.Corey: Oh, yeah. Anything I wound up taking, I always would share it with people internally, too. I'd mention, “Yeah, I'm keeping this in my shell files.” Because I disclosed it, which solves a lot of the problem. And also, none of it was even close to proprietary or anything like that. I'm sorry, but the way that you wind up figuring out how much of a disk is being eaten up and where in a more pleasing way, is not a competitive advantage. It just isn't.Amy: It isn't to you or me, but, you know, back in the beginning of our careers, people thought it was worth money and should be proprietary. You know, like, oh, that disk-checking script as a competitive advantage for our company because there are only a few of us doing this work. Like, it was actually being able to, like, manage your—[laugh] actually manage your servers was a competitive advantage. Now, it's kind of commodity.Corey: Let's also be clear that the world has moved on. I wound up buying a DaisyDisk a while back for Mac, which I love. It is a fantastic, pretty effective, “Where's all the stuff on your disk going?” And it does a scan and you can drive and collect things and delete them when trying to clean things out. I was using it the other day, so it's top of mind at the moment.But it's way more polished than that crappy Perl three-liner. And I see both sides, truly I do. The trick also, for those wondering [unintelligible 00:15:45], like, “Where is the line?” It's super easy. Disclose it, what you're doing, in those scenarios in the event someone is no because they believe that finding the right man page section for something is somehow proprietary.Great. When you go home that evening in a completely separate environment, build it yourself from scratch to solve the problem, reimplement it and save that. And you're done. There are lots of ways to do this. Don't steal from your employer, but your employer employs you; they don't own you and the way that you think about these problems.Every person I've met who has had a career that's longer than 20 minutes has a giant doc somewhere on some system of all of the scripts that they wound up putting together, all of the one-liners, the notes on, “Next time you see this, this is the thing to check.”Amy: Yeah, the cheat sheet or the notebook with all the little commands, or again the Emacs config, sometimes for some people, or shell profiles. Yeah.Corey: Here's the awk one-liner that I put that automatically spits out from an Apache log file what—the httpd log file that just tells me what are the most frequent talkers, and what are the—Amy: You should probably let go of that one. You know, like, I think that one's lifetime is kind of past, Corey. Maybe you—Corey: I just have to get it working with Nginx, and we're good to go.Amy: Oh, yeah, there you go. [laugh].Corey: Or S3 access logs. Perish the thought. But yeah, like, what are the five most high-volume talkers, and what are those relative to each other? Huh, that one thing seems super crappy and it's coming from Russia. But that's—hmm, one starts to wonder; maybe it's time to dig back in.So, one of the things that I have found is that a lot of the people talking about SRE seem to have descended from an ivory tower somewhere. And they're talking about how some of the best-in-class companies out there, renowned for their technical cultures—at least externally—are doing these things. But there's a lot more folks who are not there. And honestly, I consider myself one of those people who is not there. I was a competent engineer, but never a terrific one.And looking at the way this was described, I often came away thinking, “Okay, it was the purpose of this conference talk just to reinforce how smart people are, and how I'm not,” and/or, “There are the 18 cultural changes you need to make to your company, and then you can do something kind of like we were just talking about on stage.” It feels like there's a combination of problems here. One is making this stuff more accessible to folks who are not themselves in those environments, and two, how to drive cultural change as an individual contributor if that's even possible. And I'm going to go out on a limb and guess you have thoughts on both aspects of that, and probably some more hit me, please.Amy: So, the ivory tower, right. Let's just be straight up, like, the ivory tower is Google. I mean, that's where it started. And we get it from the other large companies that, you know, want to do conference talks about what this stuff means and what it does. What I've kind of come around to in the last couple of years is that those talks don't really reach the vast majority of engineers, they don't really apply to a large swath of the enterprise especially, which is, like, where a lot of the—the bulk of our industry sits, right? We spend a lot of time talking about the darlings out here on the West Coast in high tech culture and startups and so on.But, like, we were talking about before we started the show, right, like, the interior of even just America, is filled with all these, like, insurance and banks and all of these companies that are cranking out tons of code and servers and stuff, and they're trying to figure out the same problems. But they're structured in companies where their tech arm is still, in most cases, considered a cost center, often is bundled under finance, for—that's a whole show of itself about that historical blunder. And so, the tech culture is tend to be very, very different from what we experience in—what do we call it anymore? Like, I don't even want to say West Coast anymore because we've gone remote, but, like, high tech culture we'll say. And so, like, thinking about how to make SRE and all this stuff more accessible comes down to, like, thinking about who those engineers are that are sitting at the computers, writing all the code that runs our banks, all the code that makes sure that—I'm trying to think of examples that are more enterprise-y right?Or shoot buying clothes online. You go to Macy's for example. They have a whole bunch of servers that run their online store and stuff. They have internal IT-ish people who keep all this stuff running and write that code and probably integrating open-source stuff much like we all do. But when you go to try to put in a reliability program that's based on the current SRE models, like SLOs; you put in SLOs and you start doing, like, this incident management program that's, like, you know, you have a form you fill out after every incident, and then you [unintelligible 00:20:25] retros.And it turns out that those things are very high-level skills, skills and capabilities in an organization. And so, when you have this kind of IT mindset or the enterprise mindset, bringing the culture together to make those things work often doesn't happen. Because, you know, they'll go with the prescriptive model and say, like, okay, we're going to implement SLOs, we're going to start measuring SLIs on all of the services, and we're going to hold you accountable for meeting those targets. If you just do that, right, you're just doing more gatekeeping and policing of your tech environment. My bet is, reliability almost never improves in those cases.And that's been my experience, too, and why I get charged up about this is, if you just go slam in these practices, people end up miserable, the practices then become tarnished because people experienced the worst version of them. And then—Corey: And with the remote explosion as well, it turns out that changing jobs basically means their company sends you a different Mac, and the next Monday, you wind up signing into a different Slack team.Amy: Yeah, so the culture really matters, right? You can't cover it over with foosball tables and great lunch. You actually have to deliver tools that developers want to use and you have to deliver a software engineering culture that brings out the best in developers instead of demanding the best from developers. I think that's a fundamental business shift that's kind of happening. If I'm putting on my wizard hat and looking into the future and dreaming about what might change in the world, right, is that there's kind of a change in how we do leadership and how we do business that's shifting more towards that model where we look at what people are capable of and we trust in our people, and we get more out of them, the knowledge work model.If we want more knowledge work, we need people to be happy and to feel engaged in their community. And suddenly we start to see these kind of generational, bigger-pie kind of things start to happen. But how do we get there? It's not SLOs. It maybe it's a little bit starting with incidents. That's where I've had the most success, and you asked me about that. So, getting practical, incident management is probably—Corey: Right. Well, as I see it, the problem with SLOs across the board is it feels like it's a very insular community so far, and communicating it to engineers seems to be the focus of where the community has been, but from my understanding of it, you absolutely need buy-in at significantly high executive levels, to at the very least by you air cover while you're doing these things and making these changes, but also to help drive that cultural shift. None of this is something I have the slightest clue how to do, let's be very clear. If I knew how to change a company's culture, I'd have a different job.Amy: Yeah. [laugh]. The biggest omission in the Google SRE books was [Ers 00:22:58]. There was a guy at Google named Ers who owns availability for Google, and when anything is, like, in dispute and bubbles up the management team, it goes to Ers, and he says, “Thou shalt…” right? Makes the call. And that's why it works, right?Like, it's not just that one person, but that system of management where the whole leadership team—there's a large, very well-funded team with a lot of power in the organization that can drive availability, and they can say, this is how you're going to do metrics for your service, and this is the system that you're in. And it's kind of, yeah, sure it works for them because they have all the organizational support in place. What I was saying to my team just the other day—because we're in the middle of our SLO rollout—is that really, I think an SLO program isn't [clear throat] about the engineers at all until late in the game. At the beginning of the game, it's really about getting the leadership team on board to say, “Hey, we want to put in SLIs and SLOs to start to understand the functioning of our software system.” But if they don't have that curiosity in the first place, that desire to understand how well their teams are doing, how healthy their teams are, don't do it. It's not going to work. It's just going to make everyone miserable.Corey: It feels like it's one of those difficult to sell problems as well, in that it requires some tooling changes, absolutely. It requires cultural change and buy-in and whatnot, but in order for that to happen, there has to be a painful problem that a company recognizes and is willing to pay to make go away. The problem with stuff like this is that once you pay, there's a lot of extra work that goes on top of it as well, that does not have a perception—rightly or wrongly—of contributing to feature velocity, of hitting the next milestone. It's, “Really? So, we're going to be spending how much money to make engineers happier? They should get paid an awful lot and they're still complaining and never seem happy. Why do I care if they're happy other than the pure mercenary perspective of otherwise they'll quit?” I'm not saying that it's not worth pursuing; it's not a worthy goal. I am saying that it becomes a very difficult thing to wind up selling as a product.Amy: Well, as a product for sure, right? Because—[sigh] gosh, I have friends in the space who work on these tools. And I want to be careful.Corey: Of course. Nothing but love for all of those people, let's be very clear.Amy: But a lot of them, you know, they're pulling metrics from existing monitoring systems, they are doing some interesting math on them, but what you get at the end is a nice service catalog and dashboard, which are things we've been trying to land as products in this industry for as long as I can remember, and—Corey: “We've got it this time, though. This time we'll crack the nut.” Yeah. Get off the island, Gilligan.Amy: And then the other, like, risky thing, right, is the other part that makes me uncomfortable about SLOs, and why I will often tell folks that I talk to out in the industry that are asking me about this, like, one-on-one, “Should I do it here?” And it's like, you can bring the tool in, and if you have a management team that's just looking to have metrics to drive productivity, instead of you know, trying to drive better knowledge work, what you get is just a fancier version of more Taylorism, right, which is basically scientific management, this idea that we can, like, drive workers to maximum efficiency by measuring random things about them and driving those numbers. It turns out, that doesn't really work very well, even in industrial scale, it just happened to work because, you know, we have a bloody enough society that we pushed people into it. But the reality is, if you implement SLOs badly, you get more really bad Taylorism that's bad for you developers. And my suspicion is that you will get worse availability out of it than you would if you just didn't do it at all.Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn't limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming.Corey: That is part of the problem is, in some cases, to drive some of these improvements, you have to go backwards to move forwards. And it's one of those, “Great, so we spent all this effort and money in the rest of now things are worse?” No, not necessarily, but suddenly are aware of things that were slipping through the cracks previously.Amy: Yeah. Yeah.Corey: Like, the most realistic thing about first The Phoenix Project and then The Unicorn Project, both by Gene Kim, has been the fact that companies have these problems and actively cared enough to change it. In my experience, that feels a little on the rare side.Amy: Yeah, and I think that's actually the key, right? It's for the culture change, and for, like, if you really looking to be, like, do I want to work at this company? Am I investing my myself in here? Is look at the leadership team and be, like, do these people actually give a crap? Are they looking just to punt another number down the road?That's the real question, right? Like, the technology and stuff, at the point where I'm at in my career, I just don't care that much anymore. [laugh]. Just… fine, use Kubernetes, use Postgres, [unintelligible 00:27:30], I don't care. I just don't. Like, Oracle, I might have to ask, you know, go to finance and be like, “Hey, can we spend 20 million for a database?” But like, nobody really asks for that anymore, so. [laugh].Corey: As one does. I will say that I mostly agree with you, but a technology that I found myself getting excited about, given the time of the recording on this is… fun, I spent a bit of time yesterday—from when we're recording this—teaching myself just enough Go to wind up being together a binary that I needed to do something actively ridiculous for my camera here. And I found myself coming away deeply impressed by a lot of things about it, how prescriptive it was for one, how self-contained for another. And after spending far too many years of my life writing shitty Perl, and shitty Bash, and worse Python, et cetera, et cetera, the prescriptiveness was great. The fact that it wound up giving me something I could just run, I could cross-compile for anything I need to run it on, and it just worked. It's been a while since I found a technology that got me this interested in exploring further.Amy: Go is great for that. You mentioned one of my two favorite features of Go. One is usually when a program compiles—at least the way I code in Go—it usually works. I've been working with Go since about 0.9, like, just a little bit before it was released as 1.0, and that's what I've noticed over the years of working with it is that most of the time, if you have a pretty good data structure design and you get the code to compile, usually it's going to work, unless you're doing weird stuff.The other thing I really love about Go and that maybe you'll discover over time is the malleability of it. And the reason why I think about that more than probably most folks is that I work on other people's code most of the time. And maybe this is something that you probably run into with your business, too, right, where you're working on other people's infrastructure. And the way that we encode business rules and things in the languages, in our programming language or our config syntax and stuff has a huge impact on folks like us and how quickly we can come into a situation, assess, figure out what's going on, figure out where things are laid out, and start making changes with confidence.Corey: Forget other people for a minute they're looking at what I built out three or four years ago here, myself, like, I look at past me, it's like, “What was that rat bastard thinking? This is awful.” And it's—forget other people's code; hell is your own code, on some level, too, once it's slipped out of the mental stack and you have to re-explore it and, “Oh, well thank God I defensively wound up not including any comments whatsoever explaining what the living hell this thing was.” It's terrible. But you're right, the other people's shell scripts are finicky and odd.I started poking around for help when I got stuck on something, by looking at GitHub, and a few bit of searching here and there. Even these large, complex, well-used projects started making sense to me in a way that I very rarely find. It's, “What the hell is that thing?” is my most common refrain when I'm looking at other people's code, and Go for whatever reason avoids that, I think because it is so prescriptive about formatting, about how things should be done, about the vision that it has. Maybe I'm romanticizing it and I'll hate it and a week from now, and I want to go back and remove this recording, but.Amy: The size of the language helps a lot.Corey: Yeah.Amy: But probably my favorite. It's more of a convention, which actually funny the way I'm going to talk about this because the two languages I work on the most right now are Ruby and Go. And I don't feel like two languages could really be more different.Syntax-wise, they share some things, but really, like, the mental models are so very, very different. Ruby is all the way in on object-oriented programming, and, like, the actual real kind of object-oriented with messaging and stuff, and, like, the whole language kind of springs from that. And it kind of requires you to understand all of these concepts very deeply to be effective in large programs. So, what I find is, when I approach Ruby codebase, I have to load all this crap into my head and remember, “Okay, so yeah, there's this convention, when you do this kind of thing in Ruby”—or especially Ruby on Rails is even worse because they go deep into convention over configuration. But what that's code for is, this code is accessible to people who have a lot of free cognitive capacity to load all this convention into their heads and keep it in their heads so that the code looks pretty, right?And so, that's the trade-off as you said, okay, my developers have to be these people with all these spare brain cycles to understand, like, why I would put the code here in this place versus this place? And all these, like, things that are in the code, like, very compact, dense concepts. And then you go to something like Go, which is, like, “Nah, we're not going to do Lambdas. Nah”—[laugh]—“We're not doing all this fancy stuff.” So, everything is there on the page.This drives some people crazy, right, is that there's all this boilerplate, boilerplate, boilerplate. But the reality is, I can read most Go files from top to the bottom and understand what the hell it's doing, whereas I can go sometimes look at, like, a Ruby thing, or sometimes Python and e—Perl is just [unintelligible 00:32:19] all the time, right, it's there's so much indirection. And it just be, like, “What the [BLEEP] is going on? This is so dense. I'm going to have to sit down and write it out in longhand so I can understand what the developer was even doing here.” And—Corey: Well, that's why I got the Mac Studio; for when I'm not doing A/V stuff with it, that means that I'll have one core that I can use for, you know, front-end processing and the rest, and the other 19 cores can be put to work failing to build Nokogiri in Ruby yet again.Amy: [laugh].Corey: I remember the travails of working with Ruby, and the problem—I have similar problems with Python, specifically in that—I don't know if I'm special like this—it feels like it's a SRE DevOps style of working, but I am grabbing random crap off a GitHub constantly and running it, like, small scripts other people have built. And let's be clear, I run them on my test AWS account that has nothing important because I'm not a fool that I read most of it before I run it, but I also—it wants a different version of Python every single time. It wants a whole bunch of other things, too. And okay, so I use ASDF as my version manager for these things, which for whatever reason, does not work for the way that I think about this ergonomically. Okay, great.And I wind up with detritus scattered throughout my system. It's, “Hey, can you make this reproducible on my machine?” “Almost certainly not, but thank you for asking.” It's like ‘Step 17: Master the Wolf' level of instructions.Amy: And I think Docker generally… papers over the worst of it, right, is when we built all this stuff in the aughts, you know, [CPAN 00:33:45]—Corey: Dev containers and VS Code are very nice.Amy: Yeah, yeah. You know, like, we had CPAN back in the day, I was doing chroots, I think in, like, '04 or '05, you know, to solve this problem, right, which is basically I just—screw it; I will compile an entire distro into a directory with a Perl and all of its dependencies so that I can isolate it from the other things I want to run on this machine and not screw up and not have these interactions. And I think that's kind of what you're talking about is, like, the old model, when we deployed servers, there was one of us sitting there and then we'd log into the server and be like, I'm going to install the Perl. You know, I'll compile it into, like, [/app/perl 558 00:34:21] whatever, and then I'll CPAN all this stuff in, and I'll give it over to the developer, tell them to set their shebang to that and everything just works. And now we're in a mode where it's like, okay, you got to set up a thousand of those. “Okay, well, I'll make a tarball.” [laugh]. But it's still like we had to just—Corey: DevOps, but [unintelligible 00:34:37] dev closer to ops. You're interrelating all the time. Yeah, then Docker comes along, and add dev is, like, “Well, here's the container. Good luck, asshole.” And it feels like it's been cast into your yard to worry about.Amy: Yeah, well, I mean, that's just kind of business, or just—Corey: Yeah. Yeah.Amy: I'm not sure if it's business or capitalism or something like that, but just the idea that, you know, if I can hand off the shitty work to some other poor schlub, why wouldn't I? I mean, that's most folks, right? Like, just be like, “Well”—Corey: Which is fair.Amy: —“I got it working. Like, my part is done, I did what I was supposed to do.” And now there's a lot of folks out there, that's how they work, right? “I hit done. I'm done. I shipped it. Sure. It's an old [unintelligible 00:35:16] Ubuntu. Sure, there's a bunch of shell scripts that rip through things. Sure”—you know, like, I've worked on repos where there's hundreds of things that need to be addressed.Corey: And passing to someone else is fine. I'm thrilled to do it. Where I run into problems with it is where people assume that well, my part was the hard part and anything you schlubs do is easy. I don't—Amy: Well, that's the underclass. Yeah. That's—Corey: Forget engineering for a second; I throw things to the people over in the finance group here at The Duckbill Group because those people are wizards at solving for this thing. And it's—Amy: Well, that's how we want to do things.Corey: Yeah, specialization works.Amy: But we have this—it's probably more cultural. I don't want to pick, like, capitalism to beat on because this is really, like, human cultural thing, and it's not even really particularly Western. Is the idea that, like, “If I have an underclass, why would I give a shit what their experience is?” And this is why I say, like, ops teams, like, get out of here because most ops teams, the extant ops teams are still called ops, and a lot of them have been renamed SRE—but they still do the same job—are an underclass. And I don't mean that those people are below us. People are treated as an underclass, and they shouldn't be. Absolutely not.Corey: Yes.Amy: Because the idea is that, like, well, I'm a fancy person who writes code at my ivory tower, and then it all flows down, and those people, just faceless people, do the deployment stuff that's beneath me. That attitude is the most toxic thing, I think, in tech orgs to address. Like, if you're trying to be like, “Well, our liability is bad, we have security problems, people won't fix their code.” And go look around and you will find people that are treated as an underclass that are given codes thrown over the wall at them and then they just have to toil through and make it work. I've worked on that a number of times in my career.And I think just like saying, underclass, right, or caste system, is what I found is the most effective way to get people actually thinking about what the hell is going on here. Because most people are just, like, “Well, that's just the way things are. It's just how we've always done it. The developers write to code, then give it to the sysadmins. The sysadmins deploy the code. Isn't that how it always works?”Corey: You'd really like to hope, wouldn't you?Amy: [laugh]. Not me. [laugh].Corey: Again, the way I see it is, in theory—in theory—sysadmins, ops, or that should not exist. People should theoretically be able to write code as developers that just works, the end. And write it correct the first time and never have to change it again. Yeah. There's a reason that I always like to call staging environments in places I work ‘theory' because it works in theory, but not in production, and that is fundamentally the—like, that entire job role is the difference between theory and practice.Amy: Yeah, yeah. Well, I think that's the problem with it. We're already so disconnected from the physical world, right? Like, you and I right now are talking over multiple strands of glass and digital transcodings and things right now, right? Like, we are detached from the physical reality.You mentioned earlier working in data centers, right? The thing I miss about it is, like, the physicality of it. Like, actually, like, I held a server in my arms and put it in the rack and slid it into the rails. I plugged into power myself; I pushed the power button myself. There's a server there. I physically touched it.Developers who don't work in production, we talked about empathy and stuff, but really, I think the big problem is when they work out in their idea space and just writing code, they write the unit tests, if we're very lucky, they'll write a functional test, and then they hand that wad off to some poor ops group. They're detached from the reality of operations. It's not even about accountability; it's about experience. The ability to see all of the weird crap we deal with, right? You know, like, “Well, we pushed the code to that server, but there were three bit flips, so we had to do it again. And then the other server, the disk failed. And on the other server…” You know? [laugh].It's just, there's all this weird crap that happens, these systems are so complex that they're always doing something weird. And if you're a developer that just spends all day in your IDE, you don't get to see that. And I can't really be mad at those folks, as individuals, for not understanding our world. I figure out how to help them, and the best thing we've come up with so far is, like, well, we start giving this—some responsibility in a production environment so that they can learn that. People do that, again, is another one that can be done wrong, where it turns into kind of a forced empathy.I actually really hate that mode, where it's like, “We're forcing all the developers online whether they like it or not. On-call whether they like it or not because they have to learn this.” And it's like, you know, maybe slow your roll a little buddy because the stuff is actually hard to learn. Again, minimizing how hard ops work is. “Oh, we'll just put the developers on it. They'll figure it out, right? They're software engineers. They're probably smarter than you sysadmins.” Is the unstated thing when we do that, right? When we throw them in the pit and be like, “Yeah, they'll get it.” [laugh].Corey: And that was my problem [unintelligible 00:39:49] the interview stuff. It was in the write code on a whiteboard. It's, “Look, I understood how the system fundamentally worked under the hood.” Being able to power my way through to get to an outcome even in language I don't know, was sort of part and parcel of the job. But this idea of doing it in artificially constrained environment, in a language I'm not super familiar with, off the top of my head, it took me years to get to a point of being able to do it with a Bash script because who ever starts with an empty editor and starts getting to work in a lot of these scenarios? Especially in an ops role where we're not building something from scratch.Amy: That's the interesting thing, right? In the majority of tech work today—maybe 20 years ago, we did it more because we were literally building the internet we have today. But today, most of the engineers out there working—most of us working stiffs—are working on stuff that already exists. We're making small incremental changes, which is great that's what we're doing. And we're dealing with old code.Corey: We're gluing APIs together, and that's fine. Ugh. I really want to thank you for taking so much time to talk to me about how you see all these things. If people want to learn more about what you're up to, where's the best place to find you?Amy: I'm on Twitter every once in a while as @MissAmyTobey, M-I-S-S-A-M-Y-T-O-B-E-Y. I have a blog I don't write on enough. And there's a couple things on the Equinix Metal blog that I've written, so if you're looking for that. Otherwise, mainly Twitter.Corey: And those links will of course be in the [show notes 00:41:08]. Thank you so much for your time. I appreciate it.Amy: I had fun. Thank you.Corey: As did I. Amy Tobey, Senior Principal Engineer at Equinix. 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, or on the YouTubes, smash the like and subscribe buttons, as the kids say. Whereas if you've hated this episode, same thing, five-star review all the platforms, smash the buttons, but also include an angry comment telling me that you're about to wind up subpoenaing a copy of my shell script because you're convinced that your intellectual property and secrets are buried within.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.