Podcasts about codespaces

Myles is currently Product Lead for Developer Platform at Snowflake. Previously, he directed project management at GitHub, overseeing projects like GitHub Copilot Workspace for PRs, Codespaces, npm, and Packages. A key contributor to Ecma International and TC39, he has served for stretches as a Delegate, Co-Chair, and VP for the project. His contributions to TC39 coincided with his periods he worked for both Google and Microsoft, respectively. In addition to extensive experience driving security and standards improvement in open source initiatives and key development languages, Myles is an active and accomplished musician. Catch up with Myles and his work here: https://mylesborins.com/about.html. We are excited to have Myles as a guest on the show, so be sure to catch up with this episode and make a note that this episode is occurring one hour earlier than the typical livestream broadcast time.

GitHub Codespaces aims to simplify spinning up a developer environment in the cloud. Containerlab, which provides virtual lab environments for network engineers, is now integrated with Codespaces to make it easy to set up and share network labs. On today’s Network Automation Nerds show, we delve into this innovative use of GitHub Codespaces and containerlab... Read more »

GitHub Codespaces aims to simplify spinning up a developer environment in the cloud. Containerlab, which provides virtual lab environments for network engineers, is now integrated with Codespaces to make it easy to set up and share network labs. On today’s Network Automation Nerds show, we delve into this innovative use of GitHub Codespaces and containerlab... Read more »

Riaan Nolan is a HashiCorp Ambassador that has developed Hashiqube, a DevOps development lab that runs all HashiCorp products. Hashiqube has a Docker daemon inside meaning we can run containers inside Hashiqube using Kubernetes (Minikube) or Nomad or Docker run. It runs all Hashicorp products: Vault, Terraform, Nomad, Consul, Waypoint, Boundary, Vagrant, Packer and Sentinel. It also runs a host of other popular Open Source DevOps/DevSecOps applications (Minikube, Ansible AWX Tower, Traefik etc.) showcasing how simple integration with Hashicorp products can result in tangible learnings and benefits for all its users. In this episode, we'll explore HashiQube on GitHub CodeSpaces. 00:00 Introductions 02:00 Introducing HashiQube

Guest Brian Douglas Panelist Richard Littauer Show Notes In this episode of Sustain, host Richard Littauer talks with Brian “bdougie” Douglas, founder and CEO of Open Sauced. They discuss the multifaceted aspects of sustaining open source projects, Brian's journey in developer advocacy, and the unique goals of Open Sauced. Brian shares insights from his experiences at GitHub and Netlify, elaborates on concepts like lottery factor and the significance of unique issue authors, and tackles the challenges of maintaining open source sustainability. He also explores the balance of addressing enterprise needs while supporting smaller, less visible projects and emphasizes the importance of education and community engagement in open source. Press download now! [00:01:54] Brian discusses his background at GitHub and Netlify, his role in promoting GraphQL, GitHub Actions, Codespaces, and the inception of Open Sauced. [00:03:08] We hear about the features of Open Sauced's dashboard which enhances GitHub insights, OSSF scorecards, and workspace customizations for managing multiple projects. [00:04:31] Open Sauced's business model is currently founded by VC money and aims to serve large organizations with significant open source dependencies, and Brian talks about the team size and funding history. [00:06:08] Brian elaborates on Open Sauced's long-term sustainability plan, focusing on enterprise-level solutions for open source project observability and contributions. [00:09:31] There's a discussion on how Open Sauced interacts with open source communities and the importance of real-world testing and contributions to open source projects. [00:11:06] Richard highlights the FOSS Funders initiative, encouraging companies to support open source projects financially and through active participation. [00:12:44] Brian shares insights on effective metrics for evaluating open source projects, emphasizing the importance of engaging with unique issue authors rather than focusing solely on superficial metrics like pull requests, and discusses his approach to starting meaningful conversations in the open source community. [00:16:08] Brian explains why he renamed “Lottery Factor” to “Contributor Absence Factor,” and discusses the Pgvector project to illustrate the importance of understanding the “Contributor Absence Factor” and the sustainability concerns when a project relies heavily on a few contributors. [00:18:20] We learn more about how Open Sauced sources its data, including their use of GitHub's events feed and their development of the “Pizza Oven” tool to generate insights from Git repositories. [00:20:21] Richard and Brian discuss the challenges of maintaining an open source ethos when dealing with large companies' internal projects, avoiding becoming merely service providers for large corporate entities. [00:24:14] Brian discusses the long-term implications of open source projects that receive substantial funding or become integrated into larger corporate frameworks. [00:27:27] Richard brings up the difficulty many open source projects face in accessing significant funding and Brian shares his vision for supporting less prominent open source projects drawing analogies from his personal experiences. [00:32:42] Richard questions the “up the chain” analogy, comparing it to a pyramid scheme or academia's tenure track. Brian acknowledges the need to support contributors at all levels, not just those at the top, and he introduces the concept of a S Bomb to provide transparency about project dependencies. [00:39:36] Find out where you can follow Brian on the web. Spotlight [00:40:17] Richard's spotlight is Mr. Carreras, an awesome music teacher. [00:40:59] Brian's spotlight is Dawn Foster at the CHAOSS Project and the CHAOSS Practitioner Guides. Links SustainOSS (https://sustainoss.org/) podcast@sustainoss.org (email) (mailto:podcast@sustainoss.org) richard@theuserismymom.com (email) (mailto:richard@theuserismymom.com) SustainOSS Discourse (https://discourse.sustainoss.org/) SustainOSS Mastodon (https://mastodon.social/tags/sustainoss) Open Collective-SustainOSS (Contribute) (https://opencollective.com/sustainoss) Richard Littauer Socials (https://www.burntfen.com/2023-05-30/socials) Brian Douglas- Open Sauced (https://app.opensauced.pizza/u/bdougie) Brian Douglas Website (https://b.dougie.dev/) Brian Douglas GitHub (https://github.com/bdougie) Brian Douglas X/Twitter (https://github.com/bdougie) The Secret Sauce Open Sauced Podcast (https://podcasts.apple.com/us/podcast/the-secret-sauce/id1644263270) The Secret Sauce Podcast: ‘The Future of Cloud Native and AI with Brendan Burns' (https://podcasts.apple.com/fr/podcast/the-future-of-cloud-native-and-ai-with-brendan-burns/id1644263270?i=1000658092259) Open Sauced (https://opensauced.pizza/) Renaming Bus Factor #632 (CHAOSS community) (https://github.com/chaoss/community/issues/632#issuecomment-2152929617) FOSS Funders (https://fossfunders.com/) Andrew Kane GitHub (https://github.com/ankane) Chad Whitacre Website (https://chadwhitacre.com/) Fair Source (https://fair.io/) CHAOSS (https://chaoss.community/) Your Copilot for Git History (Open Sauced) (https://opensauced.pizza/docs/features/star-search/) Open Sauced GitHub (https://github.com/open-sauced/pizza) InnerSource Commons (https://innersourcecommons.org/) Sustain Podcast-Episode 148: Ali Nehzat of thanks.dev and OSS Funding (https://podcast.sustainoss.org/148) Learning in Public with Kelsey Hightower (Curiefense) (https://www.curiefense.io/blog/learning-in-public-with-kelsey-hightower/) Welcome to Wrexham (https://en.wikipedia.org/wiki/Welcome_to_Wrexham) Sustain Podcast-Episode 159: Dawn Foster & Andrew Nesbitt at State of Open Con 2023 (https://podcast.sustainoss.org/guests/foster) Dr. Dawn Foster Mastodon (https://hachyderm.io/@geekygirldawn) About the CHAOSS Practitioner Guides (https://chaoss.community/about-chaoss-practitioner-guides/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Brian Douglas.

Jason Warner is co-founder and CEO of poolside, a generative AI company building the world's most capable AI for software development & the applications to unlock the potential of developers. Prior to founding poolside, Jason was the Managing Director at Redpoint Ventures. He also served as the CTO at GitHub, where he was responsible for bringing products like GitHub Actions, Packages, Advanced Security, Connect, and Codespaces to market. In this episode, Jason discusses the business challenges and successes he experienced as GitHub's CTO and delves into the unique hurdles faced by a generative AI company. He also shares his philosophy on the future of AI and its potential impact on various aspects of our lives.

In this Summer Replay, we revisit our conversation with Jason Warner, where he explained to us how to “Git” on it. Since this episode's original airdate, Jason has since went on to become the CEO and co-founder at poolside, but his time at GitHub has given him the expertise to inform folks about all the exciting things GitHub has going on. Listen as Jason offers insight into GitHub's successes which have led to their acquisition by Microsoft. He breaks down his own history at GitHub and its vision to become the “worlds most important software company.” Jason dives into some of the details of GitHub acquisition and the possibilities for what they want to achieve, and where they expect to go within Microsoft. Jason and Corey discuss how to talk about the cloud for its current, and importantly, future clients. Jason talks about what GitHub will bring to Microsoft, and perhaps how it'll be for the better. Tune in, because the getting is about to “git” good.Show Highlights:(0:00) Intro(0:27) Duckbill Group sponsor read(1:01) The role of GitHub(4:46) How GitHub and Azure can coexist(7:08) When to adopt to the cloud(9:55) GitHub's impact on Microsoft(13:24) Experiencing acquisition(19:34) Misconceptions of GitHub(21:36) Duckbill Group sponsor read(22:20) Practicality of Codespaces(25:34) Designing software with a purpose(28:40) Dispelling nerd culture in software(30:55) Starting in a non-technical direction(33:52) Where you can find more about JasonAbout Jason Warner:Jason Warner is the co-founder and CEO of poolside. He serves on the operating board of Bridgewater Associates. He has previously worked at GitHub as their CTO.Links:GitHub: https://github.com/@jasoncwarner: https://twitter.com/jasoncwarnerGitHub: https://github.com/jasoncwarnerJasoncwarner/ama: https://github.com/jasoncwarner/amaOriginal Episode:https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/what-github-can-give-to-microsoft-with-jason-warner/Sponsor:The Duckbill Group: https://www.duckbillgroup.com/

¡Bienvenidos a un nuevo episodio de El Podcast de Dynamic Devs

Bret and Nirmal are joined by Ivan Burazin and Chad Metcalf to debut Daytona, an open source "codespaces equivalent."Daytona is a development environment manager designed to automate all the tedious steps a developer needs to perform to set up their development environment. "Essentially, it transforms any machine into a codespaces equivalent."Where Daytona is actually starting in the enterprise is focusing on large dev environment solutions and management of those, and then trickling down to individual developers. So there are two very similar solutions to a problem of many developers and their varying ways that they set up their environments for development, but they're coming at it from two ends of the spectrum. Be sure to check out the live recording of the complete show with demos from March 7, 2024 on YouTube (Ep. 257).★Topics★Daytona websiteDaytona on GitHubWhy Daytona OSS'dDIY GuideCreators & Guests Ivan Burazin - Guest Chad Metcalf - Guest Bret Fisher - Host Nirmal Mehta - Host Beth Fisher - Producer Cristi Cotovan - Editor (00:00) - Intro (06:33) - CodeAnywhere (07:50) - Introducing Daytona: Revolutionizing Dev Environments (13:54) - Demo (21:07) - Daytona's Automation Magic (22:49) - Comparing Daytona with DevPod (25:15) - Daytona's Roadmap and Beyond (27:01) - Dev Environments and IDEs (39:52) - AI with Daytona (44:05) - Getting Started with Daytona (44:35) - Getting Involved in Daytona (47:00) - Features About to Ship in Daytona You can also support my free material by subscribing to my YouTube channel and my weekly newsletter at bret.news!Grab the best coupons for my Docker and Kubernetes courses.Join my cloud native DevOps community on Discord.Grab some merch at Bret's Loot BoxHomepage bretfisher.com

In this episode of Ruby for All, Andrew and Julie chat about their recent experiences, including a ski trip with challenges due to a storm, and discuss burnout and returning to regular podcasting. Special guest, Ryan Caldwell, a software engineer at GitHub working on Copilot, joins the conversation to discuss his work, particularly on chat-related features of Copilot.  Ryan shares insights on programming languages, leaning into his transitions between Ruby, Java, and Go, and navigating the differences between dynamically and statically typed languages.  The conversation covers the benefits and challenges of implementing type checking in Ruby with Sorbet, especially in large projects like GitHub.  Ryan advocates for learning Ruby on Rails, praises its efficiency for staring profitable projects, and provides tips for using Copilot Chat effectively.  Press download now to hear more! [00:00:23] Julie fills us in on a recent skiing trip to went on in California, the huge storm they encountered and leaving early to avoid being stranded, the broken chain on their car, and a scary moment on a slope with her kids. Andrew shares he experienced burnout but sees improvement. [00:02:47] Ryan Caldwell introduces himself and tells us what he does. [00:03:53] Andrew asks Ryan about the programming languages used for Copilot, leading to a discussion about using Go for its REST API, the manageability of the project, and Ryan's transition from Codespaces to Copilot after paternity leave. [00:04:49] Andrew wonders why Go was chosen, and Ryan explains the team's familiarity with Go and the language's simplicity. [00:06:12] Ryan reflects his first programming language and journey through JavaScript, Python, Java, and Ruby, highlighting his appreciation for Ruby. He talks about learning Ruby on the job, and his fondness for Rails. [00:08:02] Ryan discusses the challenges of picking up new languages and his approach to learning through project involvement. [00:09:24] Andrew asks about the shift from dynamic to typed languages, and Ryan shares his experiences transitioning from Ruby to Go. [00:11:53] We hear about Ryan's work on type checking with Sorbet at GitHub, and he shares that Sorbet helped find edge cases and bugs, improving the code by requiring changes to the structure to prevent these issues. [00:15:09] Ryan feels the biggest benefit of Sorbet is enforcing developers to consider boundaries and contracts between classes, which encourages thoughtful coding and design. A downside he mentions is the time and confusion involved in the migration process, particularly for team members unfamiliar with the new syntax.[00:17:11] Julie inquires if Ryan would do anything differently regarding Sorbet implementation. He reflects on the challenge of estimating the time required for implementing Sorbet, dealing with complex code, and the difficulty of refactoring legacy code without comprehensive tests. [00:18:44] Would Ryan go back to Ruby/Rails without Sorbet? He states that he would for personal projects for speed but appreciates Sorbet in team settings for defining clear code boundaries. [00:19:31] Ryan suggests that small teams should consider Sorbet if it solves a specific problem, rather than adopting it without a clear purpose. [00:21:40] Ryan discusses his pride in streamlining the authentication process across different clients in Copilot, leading to a simplified codebase for the team. A tip he shares is to provide as much context as possible when using Copilot Chat to get better responses. [00:25:35] Andrew talks about custom instructions for ChatGPT, like ensuring all output is in bullet points, and wonders if such a feature exists for Copilot.[00:28:46] Ryan advises newer developers to be intentional about what they chose to learn in software development, emphasizing the importance of investing learning time wisely. And yes, Ruby on Rails is still worth learning in 2024. [00:31:03] Find out where you can follow Ryan on the interwebs.Panelists:Andrew MasonJulie J.Guest:Ryan CaldwellSponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteRyan Caldwell X/TwitterRyan Caldwell GitHubGitHub CopilotGoSorbetVisual Studio Code-GitHub Copilot Series (YouTube) (00:00) - Ski Trip and Snow Adventures (02:47) - Ryan Caldwell's Intro (03:53) - Copilot's Language Choice (06:12) - Journey Through Programming (09:24) - Dynamic to Typed Languages (11:53) - Sorbet's Impact at GitHub (17:11) - Reflecting on Sorbet (21:40) - Copilot's Authentication Success (25:35) - Customizing Copilot Chat (28:46) - Learning Paths in Software Dev (31:03) - Where to Follow Ryan

Puter puts an entire operating system in your web browser, the kapa.ai team write down how to structure your docs for LLMs, Daytona is an open source Codespaces alternative, Gleam v1.0 has been released & Rolldown is a JavaScript bundler written in Rust.

Puter puts an entire operating system in your web browser, the kapa.ai team write down how to structure your docs for LLMs, Daytona is an open source Codespaces alternative, Gleam v1.0 has been released & Rolldown is a JavaScript bundler written in Rust.

Puter puts an entire operating system in your web browser, the kapa.ai team write down how to structure your docs for LLMs, Daytona is an open source Codespaces alternative, Gleam v1.0 has been released & Rolldown is a JavaScript bundler written in Rust.

In 2014, software-as-a-service company Code Spaces disappeared overnight after a devastating cyber attack. Thousands of coders lost access to their work when insufficient cloud backups failed under pressure. The company was forced to go out of business.Learn the tragic tale of how Code Spaces ignored standard data protection rules, putting their business and clients at risk. We'll unpack what went wrong with their cloud architecture and backup systems, allowing a single hacker to destroy their SaaS company.Understand why you still need backup - even native cloud redundancy isn't enough. Our hosts explore the hard lessons from this cloud catastrophe and equip you with actionable advice around security, access controls, preparation, and backup policies. Safeguard your slice of the cloud and avoid the mistakes that ultimately shuttered Code Spaces.Articles covering this story:https://www.esecurityplanet.com/networks/code-spaces-destroyed-by-cyber-attack/https://www.itgovernance.co.uk/blog/the-attack-that-forced-code-spaces-out-of-business-what-went-wronghttps://www.breaches.cloud/incidents/codespaces/https://threatpost.com/hacker-puts-hosting-service-code-spaces-out-of-business/106761/https://thehackernews.com/2014/06/cyber-attack-on-code-spaces-puts.htmlhttps://www.csoonline.com/article/547518/disaster-recovery-code-spaces-forced-to-close-its-doors-after-security-incident.htmlhttps://blogs.manageengine.com/it-security/passwordmanagerpro/2014/08/20/code-spaces-aws-security-breach-a-sad-reminder-of-the-importance-of-cloud-environment-password-management.html

This is a recap of the top 10 posts on Hacker News on June 20th, 2023.This podcast was generated by Wondercraft: https://www.wondercraft.ai/?utm_source=hackernews_recap Please ping at team AT wondercraft.ai with feedback.(00:38): Codespaces but open-source, client-only, and unopinionatedOriginal post: https://news.ycombinator.com/item?id=36407477&utm_source=wondercraft_ai(02:07): Loneliness is stronger when not aloneOriginal post: https://news.ycombinator.com/item?id=36403280&utm_source=wondercraft_ai(03:44): Sub.Rehab – See where Reddit communities have relocatedOriginal post: https://news.ycombinator.com/item?id=36401999&utm_source=wondercraft_ai(05:23): “Exit traps” can make your Bash scripts more robust and reliable (2013)Original post: https://news.ycombinator.com/item?id=36400465&utm_source=wondercraft_ai(06:47): Style your RSS feedOriginal post: https://news.ycombinator.com/item?id=36401854&utm_source=wondercraft_ai(08:17): Rivian embraces Tesla's charging standard for EVsOriginal post: https://news.ycombinator.com/item?id=36403494&utm_source=wondercraft_ai(10:00): Former US SEC attorney: 'Get out of crypto platforms now'Original post: https://news.ycombinator.com/item?id=36408367&utm_source=wondercraft_ai(11:37): HashingOriginal post: https://news.ycombinator.com/item?id=36401747&utm_source=wondercraft_ai(12:59): Mullvad Leta: A search engine used in the Mullvad BrowserOriginal post: https://news.ycombinator.com/item?id=36402162&utm_source=wondercraft_ai(14:20): Minimal downtime major PostgreSQL version upgrades with pg_easy_replicateOriginal post: https://news.ycombinator.com/item?id=36405761&utm_source=wondercraft_aiThis is a third-party project, independent from HN and YC. Text and audio generated using AI, by wondercraft.ai. Create your own studio quality podcast with text as the only input in seconds at app.wondercraft.ai. Issues or feedback? We'd love to hear from you: team@wondercraft.ai

I'm trying to make my open source backend API project StaticBackend as easy as possible to contribute.Couple of things I've added lately was worth mentionning. GitHub Codespaces is helpful and nicely done. It goes 1-step further than Docker and make contributing to an open source project a simple task, especially for small and quick 1-time contribution.This couple with GitHub CLI, which I admit, have just starting using it. And linters to make sure the quality of the code is as high as it can be.StaticBackend website | GitHub repoIf you'd want to support this podcast, the best way is to talk about it, sponsor my open source project or purchase my course Build SaS apps in Go.

This week we're joined by Brigit Murtaugh, Product Manager on the Visual Studio Code team at Microsoft, and we're talking about Development Containers and the Dev Container spec. Ever since we talked with Cory Wilkerson about Coding in the cloud with Codespaces we've wanted to get the Changelog.com codebase setup with a dev environment in the cloud to more easily support contributions. After getting a drive-by contribution from Chris Eggert to add a Dev Container spec to our codebase, we got curious and reached out to Brigit and asked her to come on the show to give us all the details.

This week we're joined by Brigit Murtaugh, Product Manager on the Visual Studio Code team at Microsoft, and we're talking about Development Containers and the Dev Container spec. Ever since we talked with Cory Wilkerson about Coding in the cloud with Codespaces we've wanted to get the Changelog.com codebase setup with a dev environment in the cloud to more easily support contributions. After getting a drive-by contribution from Chris Eggert to add a Dev Container spec to our codebase, we got curious and reached out to Brigit and asked her to come on the show to give us all the details.

John Papa @John_PapaWard Bell @WardBellDan Wahlin @DanWahlinCraig Shoemaker @craigshoemakerChris Noring @chris_noringBrought to you byAG GridNarwhal Visit nx.dev to get the preeminent open-source toolkit for monorepo development, today. Resources:Codespaces OverviewCode Spaces .NET Core StarterDev containersIntroduction to GitHub Code SpacesManaging encrypted secrets for your codespacesConfiguring and customizing codespaces: deep diveVscode.devGithub.devJust One More Change - github.dev, vscode.dev, codespaces on YouTube by John PapaAzure for Students $100 creditCodespaces pricingWhat is Codespaces and how can Students access it for free?Simple example of configuring a codespaces environment for Angular + NodeHow to optimize your Codespaces using quotasIntroduction to Dev ContainersCreate a Dev Container https://code.visualstudio.com/docs/devcontainers/create-dev-containerTimejumps00:46 Guest introduction02:30 What is Code Spaces?03:21 What problem is Code Spaces solving?05:14 What's the debugging experience in Code Space?06:50 Sponsor: Ag Grid07:51 What about open source contributer and PRs?14:51 Using Code Spaces with a lower powered computer16:44 Is there a program for students?19:28 Sponsor: Narwhal20:09 What is the cost of Code Spaces?24:51 How do the dev container files work?28:45 How does Code Spaces compare to competitors?32:25 How else is Code Spaces used?39:12 Final thoughtsPodcast editing on this episode done by Chris Enns of Lemon Productions.

A hostile takeover of the Solaris contraband market. Ukraine warns that Russian cyberattacks continue. An overview of 2H 2022 ICS vulnerabilities. Codespaces accounts can act as malware servers. Blank-image attacks. Campaigns leveraging HR policy themes. Dinah Davis from Arctic Wolf has tips for pros for security at home. Our guest is Gerry Gebel from Strata Identity describes a new open source standard that aims to unify cloud identity platforms. And travel-themed phishing increases. For links to all of today's stories check out our CyberWire daily news briefing: https://thecyberwire.com/newsletters/daily-briefing/12/12 Selected reading. Friday the 13th on the Dark Web: $150 Million Russian Drug Market Solaris Hacked by Rival Market Kraken (Elliptic Connect)  Russia-linked drug marketplace Solaris hacked by its rival (The Record from Recorded Future News)  Cyber-attacks have tripled in past year, says Ukraine's cybersecurity agency (the Guardian) Ukraine: Russians Aim to Destroy Information Infrastructure (Gov Info Security)  Ukraine says Russia is coordinating missile strikes, cyberattacks and information operations (The Record by Recorded Future) ICS Vulnerabilities and CVEs: Second Half of 2022 (SynSaber) Abusing a GitHub Codespaces Feature For Malware Delivery (Trend Micro) The Blank Image Attack (Avanan) Phishing Attacks Pose as Updated 2023 HR Policy Announcements (Abnormal Security) Spammers phish eager vacationers with travel-themed lures, Bitdefender Antispam Lab warns (Bitdefender)

Timestamps[00:45] Andrew recaps pairing with Collin and some other folks over the weekend on an open source PR[2:40] Andrew launches a discussion around GitHub Codespace configs for open source projects and how that would have made his life easier. Julie also brings up Tuple as another great tool for pairing[5:15] Julie brings up trying to use Codespaces to pair on Rails, which does have a configuration file [6:00] Andrew gives a basic explanation of what Codespaces, why it's helpful, and some of the struggles he's had with it[10:45] Julie gives Andrew a recap of RubyConf Mini[11:40] Andrew and Julie talk about feeling down after conferences[14:00] Julie talks about why flying is stressful for her and how she got a lucky break on her flight home from the conference[17:00] Julie talks about the speaker dinner prior to the conference and some of the other events she attended[18:30] Julie talks about giving her talk. And don't worry! She had a nodder![20:00] Julie talks about being on the conference panel that you all heard last week[22:00] Andrew wants to hear about the food and Julie delivers![23:30] Julie gives her final thoughts on the conference and Andrew advocates for doing more local conferencesSponsorSpecial thanks to Andy Croll for personally sponsoring this episode. Be sure to check out firstrubyfriend.org and onerubything.com for nice, free community resources for newer devs!LinksTupleGitHub CodespacesUsing Codespaces with VS Code

We explore the world of GitHub Codespaces and all the joy that it can bring to development. Follow Us Frank: Twitter, Blog, GitHub James: Twitter, Blog, GitHub Merge Conflict: Twitter, Facebook, Website, Chat on Discord Music : Amethyst Seer - Citrine by Adventureface ⭐⭐ Review Us (https://itunes.apple.com/us/podcast/merge-conflict/id1133064277?mt=2&ls=1) ⭐⭐ Machine transcription available on http://mergeconflict.fm

What's new with Codespaces from GitHub Universe 2022 - https://github.blog/2022-11-10-whats-new-with-codespaces-from-github-universe-2022/ Remote Development in JetBrains IDEs Now Available to GitHub Codespaces Users - https://blog.jetbrains.com/blog/2022/11/09/remote-development-in-jetbrains-ides-now-available-to-github-codespaces-users/ Hey, GitHub! - https://githubnext.com/projects/hey-github/ ‘Hey, GitHub!' will let programmers code with just their voice - https://www.theverge.com/2022/11/9/23449175/hey-github-voice-copilot-code-programming-system #github #codespaces #ai #ia #heygithub #jetbrains --- Send in a voice message: https://podcasters.spotify.com/pod/show/edodusi/message

W dzisiejszym odcinku porównujemy Copilot i Codespaces. Które rozwiązanie działa lepiej? Jak przebiega setup? Czego do tego potrzebujemy? I wiele innych spraw związanych z tym zagadnieniem.

Steph is joined by a very special guest and fellow thoughtboter, Rob Whittaker. ngrok (https://ngrok.com/) Time Off Book (https://www.timeoffbook.com/) Rob's Codespace Setup (https://github.com/purinkle/codespace) Rob Whittaker on Twitter (https://twitter.com/purinkle) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. And today, I'm joined by a very special guest and fellow thoughtboter, Rob Whittaker. Rob has been in the software business for the past 15 years and spent the last five and a half years at thoughtbot. Rob is the Director of Software Development for our Europe, Middle East, and Africa team and, in his spare time, likes to hunt down delicious beers and coffee. Rob, welcome to The Bike Shed. It's so lovely to have you on the show today. ROB: Thank you for having me. It's a pleasure to be here. Yeah, thank you for that lovely introduction and my far too complicated job title. It sounds more serious than it actually is. STEPH: Well, you do have a fancy job title, yeah, Director of Software Development. [laughs] ROB: Yeah, it's the added on bit where it's Europe, Middle East, and Africa where I feel like there's about 20 of us maximum. But that sounds more grandiose than it actually is. STEPH: Yeah, that's something that Chris and I haven't dug into too much on previous episodes are all the different teams that we have at thoughtbot. So the shorter way of saying that is Launchpad II, but not everybody knows that. But I'm going to circle back to that because I would love to talk a bit more about that specific team and the dynamic. But before we do that, I'm realizing I'm not familiar with your origin story as to how you came to thoughtbot and then how you became this very fancy grand title of Director of Software Development for Europe, Middle East, and Africa team. ROB: Yeah, there's a bit of history about thoughtbot London as well that kind of ties into this. So before thoughtbot Launchpad II, it was thoughtbot London before we went remote. And initially, we had the plan of setting up a new studio in London to help expand thoughtbot outside of the Americas, but that plan fell through. But he knew some people from another agency called New Bamboo, and so we merged with or acquired that agency, and that agency then became the thoughtbot London team. I'm actually the first hire or...not the first hire, that's not true, the first development hire for the thoughtbot London team that would then become launchpad II. I was at the Bath Ruby Conference six years ago, I guess. And there was just an advert up on the hiring board that Nick Charlton, who's a Senior Developer and Development Team Lead at Launchpad II now, had put up. And I saw it, and I was talking to somebody who was my mentor at the time that I'd worked with at a previous job at onthebeach.co.uk, a guy called Matt Valentine-House who now works at Shopify who, actually, fun fact, his face appears at the top of Ruby Weekly this week. If you open up this week's Ruby Weekly, you can see Matt Valentine-House, who said to me, "Yeah, apply for it, why not? You see what happens." And I was like, "Okay," and just kind of took the leap. So I thought, thoughtbot, why would thoughtbot want me? Which is something I think a lot of people think when they want to join thoughtbot. They think, well, I can't do that. But I would implore people to apply. And so, from there, I never really wanted to move to London. I'd always lived in the North West of the UK. I made that leap to London because I wanted to work at thoughtbot. And then, gradually, over time, the London team expanded, and we needed to split out the management roles, and the development director role came up. And I've always enjoyed the coaching side of software development. It seems that you gain more experience as you help people with less experience, and I've always enjoyed coaching. And that was a big part of the role for me. So I was fortunate enough to be allowed to do it. And then, from there, things have grown. Yeah, so it's been a really interesting journey as a development director. The London studio went through a pretty tough time at one point where not long after I became development director that two-thirds of the team, in the space of two weeks, decided to hand their notice in and unbeknownst to each other. And so, all of a sudden, we didn't have a very big team. We didn't have very many prospects, and so it was a tough time. And so it's really nice to look back on the last three years and go, okay, we came through that. We're now one of the stronger teams at thoughtbot. And somebody actually asked me in an interview the other day, somebody we actually hired, not just based on this question, but he said, "What is your proudest moment of working at thoughtbot?" And I was like, that's one of the best questions I've heard from a candidate. And I said, "Hmm, that's interesting." It's not anything development-related, but it's that I can now look back on this team and say this is the team that I have grown in my image and all these people apart from Nick, who was the person who put the advert of it at Bath Ruby. I've hired all these people, and so the buck stops with me really because if anybody isn't able to perform, then it's kind of my fault because these are the people that I want to grow into being the team and see be a successful product design team or product development team, which brings us to modern-day I guess. So yeah, that was a long origin story. That's pretty much my whole thoughtbot biography. And I apologize. STEPH: That was perfect. I thoroughly enjoyed hearing it. And yeah, that's an awesome question. What's your proudest moment, like, part of a team? That can yield so many insights. I love that question. And I love your answer as well in terms of this is the team. We've pulled through a hard time. And then we've built everybody to the point that they are now, which kind of leads in perfectly to my next question. So being the software development director, could you walk us through a little bit of like, that's one of those titles I feel like a lot of companies have, but they can be very different from company to company. Would you mind walking us through a bit of the day-to-day in the life of being a development director? ROB: Yeah, sure. It's one of those things where I think this is something that I'm not sure if it's unique to thoughtbot, but you end up taking on a lot of hats at thoughtbot. So I know you're a team lead. So you have to balance your responsibilities as an individual contributor, which is a term I don't like, but I haven't got a better way to say it yet, and your development team lead roles. And I have similar sort of responsibilities where I have to do my individual contributor work. I have to do my director work. I'm also on our DEI Council. So I have to add that work in too, and make sure it's balanced out. So the start of my day is very much about prioritizing things. I know you and Chris, a few episodes ago, had quite lengthy discussions about productivity systems and what tools Chris wants to use. And I'm a big fan of Things, and I've been using it for maybe ten years, if not more, that I've now got my system down that I'm able to prioritize things in the way that I can pick up the right task at the right time. So a big part of my day-to-day is figuring out what is the most important thing to work on? So I have my client work, and then it's about supporting the team from that point. And the big part of my idea of what a manager is is that my job isn't to tell you what to do; my job is to find out what you want to do and direct you in a place where you can find the answer. Or I can give you some guidance about where to find the answer. And I feel like I'm doing a bad job as a manager where if I have to act as a middle person. Because if somebody comes to me and says, "Oh, I want to do this thing," And I say, "Well, I'll talk to that person for you," and then come back, I have failed. And my job is to say, "Oh, you should talk to that person about this." And to some extent, it's about being lazy. I don't want to be doing too much stuff because I have other things to do. But I want to make sure that those people have the right frameworks and guidelines in place so that I can point them in the right direction. STEPH: I think the fancy term for that is just delegating. [laughs] ROB: Yes, thank you. [laughs] STEPH: But I like lazy. [laughter] I like that one as well. I love that framing of a manager where you're not telling someone to do, but as your job, you are helping that person figure out what they want to do and then supporting them. I've been chatting with Chris recently and some others because I've been reading the book Resilient Management by Laura Hogan. And it's really helped me cement the difference between mentorship, coaching, and sponsorship. And I realized that I'm already falling a lot into the coaching and sponsorship because mentorship can be wonderful, but it is more directive of like, this is what I've done. And this is what has worked for me, and you should do this too. Versus the coaching and sponsorship, I think aligns far more perfectly with what you described as management, where it is my job to figure out what brings you joy, what brings you energy, and then how to help you progress to your next goals and your next steps in your career. ROB: Yeah, I think Laura Hogan is a great resource like her blog posts and books. I haven't read Resilient Management. But I know that the team leads on my team had been on her training courses, and they say how great it is. And there's also a blog post of hers that's about managing in tough times. It has a much better title than that. But it's about how do we be good managers in such uncertain times when there are a lot of things going on around the world right now that we all have to deal with? And helping people deal with those situations. Because at the end of the day, work isn't the most important thing; the most important thing is living. And it's something I say to my team, especially when people feel like...it's something that I say to my team when they're not feeling well. The most important thing is that you get better. And thoughtbot is still going to be here. The most important thing is how you live your life and how you look after yourself, and everything else is secondary. STEPH: Absolutely. Well, and everybody needs something different from work too. Some people may be in a state where they really need more stability and predictability from their work. And some people may be in a space where everything else outside of work is very stable and calm, and then they want work to bring the challenge and the volatility and the variety to life. So I remind myself very often that not everybody wants the same thing from work and to figure out what it is that someone wants from work. And then your seasons change. You may be in a season of where you want stability, or then you may be in a season of like, I'm ready to grow and push and take some risks. So helping someone identify which season of work they're in. ROB: Yeah, I 100% agree. What people can't see is me nodding vigorously on the other side of this call. It's very much about understanding because everybody is different. And that's what we want from a good team; it's understanding everybody's different approach to things. And so sometimes people want the distraction of work because they don't want the time off to think about other things. They want to be able to sit and concentrate on something. And it's understanding different people. STEPH: Yeah, that's a great point. I'm curious; you mentioned that as part of being development director, you are also, in addition to managing the team and being part of DEI then, there's also your day-to-day client work. I think you've started a new client recently. Could you tell me more about that? ROB: Yeah, I'd recently been working for a client for two and a half years, which is a very long time to be working with one client at thoughtbot. And it came to the time where I was ready for a new challenge, and it was stable enough for me to move on. So I've been working for a company in the UK. They allow customers to buy and sell cars, not between customers, the customers like companies like Auto Trader but customers to dealers and back and forth. And primarily, they worked with buying cars. And they've launched a product in the UK where people can sell their cars as well because they found that 70% of people who are buying cars also want to sell their cars. And from there, they're now looking to expand into Germany and Spain, so we are helping them to do that. And it's an interesting project, not necessarily from a technical point of view, but I might come back to that but definitely from a cultural point of view. The product at the moment allows you to put in a license plate or a registration plate for a car. And there's then a service in the UK that will allow you to pull up the maker model and the service history of that car. But you can't do that in Germany because it's against the privacy laws to find something from registration plates. And so it's interesting these different cultural aspects that you have to take into account when expanding into other countries that you aren't from and that you have less knowledge about. Because I'm also aware that credit cards aren't a big thing in Germany either. So you have to think about how they pay for things in different countries. And the previous company I was working for they're based in the Middle East. And so we had to take into account how we would do right to left design in a mobile app, which is really interesting from a western point of view that you get so used to swiping through an experience from left to right. But then it's not just the screen that's right to left. The journey moves from right to left. So you have to get used to the transitions of the screen going the other way and not thinking of that as going backwards. It's one of the best things about working in this region is that we get to deal with so many different cultures and how they expect to use applications. It's really satisfying. STEPH: That's fascinating. Yeah, I haven't gotten to work on a project like that that has those types of considerations. I think the most relatable experience I have is more working in healthcare because that's one of those areas that I'm certainly not proficient. I've become more proficient because of the type of projects that I've worked on. But I'm curious, for expanding into other regions and cultures, do those teams typically have an expert on their team that then helps guide the development process? Or, as you mentioned, the process of buying a car could be very different in some of the legal aspects that you're up against. Is there someone that you can turn to that's then helping mentor or be aware of that process? ROB: Yes, the current client they have a team based in Germany, people who are from Germany that are advising us on different cultural aspects or legislative things. They are doing a lot of data analysis for us because we need a new service that we can use for looking up car details. Because there is a service that you give different information to to get information about the car back from. So yeah, we do have that team there. But that's not always the case because every client is different. The company that we're working for in the Middle East didn't have a team. They had two developers who were helping us. But we have to figure things out just from their cultural background to ask them questions about things and allow them to advise us, but nobody who was really a specialist. But that's an interesting thing as well, not just the cultural aspects of the customers but the cultural aspects of the company that you work for. We definitely found that the company in the Middle East was more hierarchical. And so that's another challenge that you have to work with because we tend to work in quite a flat way where we tend to default as on thoughtbot projects, of not having a point person on a project. Everybody is there to answer the questions. But some teams or clients want that point person. And so, we adapt and change to allow for that to happen and work in that way. But it is interesting to work in different companies as well as working as an agency. STEPH: Yeah, you bring up a really good point of something that I don't reflect on very often, but it's something that I really appreciate about our thoughtbot culture is that we do try to strive for a very flat hierarchy. But also in working with clients, we purposely will avoid like, if there are two or more thoughtboters on a project, we don't want one person that is then the primary contact between the client and the thoughtbot team. The goal is that everybody shows up. Everybody is part of the process; everybody is part of meetings. And we do have an advisor for projects, but otherwise, we work very hard to make sure that there's not just one person that's then responsible for communication. We want everybody to have opportunities to be part of meetings, to lead meetings, to take on initiatives versus having that one person. That is something that I really appreciate that we do. ROB: Yeah. And it's more noticeable when you go to places where that isn't the norm, and you appreciate it more. And I think a big part of that is how much we are trusted. And we trust people to trust us, I guess. STEPH: Yeah. And I think it fits in nicely with circling back to the management conversation is that when people have access to those opportunities, that makes my job so much easier as a team lead where then there are more opportunities to sponsor someone or to coach someone as to how they can then be the person that then takes on a project or if they want to lead a particular meeting, or if they want to help a team introduce retrospectives into their process. So it gives more opportunities for me to then coach someone into expanding their skill set in those ways. ROB: Yeah, that's interesting to think about, allowing yourself to coach other people in that role. Because as we gain more experience and become senior developers, we naturally fall into that role of taking the lead on projects, even when we're not asked to. But then, when you gain other responsibilities in the management track, so you as a team lead and me as a team lead and a development director, it could be better for you to not take that role and allow somebody else to come into that role so you can coach them. That's been playing on my mind the last couple of days. Josh Clayton, who's the Managing Director for one of our teams in the Americas, raised it on our pull request in our handbook where we were talking about team leads having a dedicated day to concentrate on team lead things. It's one of those things where somebody says something, and it's like, oh yeah, that really clicks. Maybe that's why we have been having certain struggles on projects where we need to rearrange things and learn from that and so we can be better on projects in the future. So that's something that really resonated with me, and it's flying around in the back of my mind at the moment. STEPH: Yeah, that really resonates with me because while the predominant part of being a team lead at thoughtbot is having one-on-ones with folks, I find that when I have more time, a lot of the work also falls outside of that one-on-one where it's following up on conversations around hey, this person mentioned they're really interested in growing their skill. How can I help them? How can I help find opportunities? Or I know that they're currently stretching their skill set right now. If I have some extra time, then I can check in with them. I can pair with them. I can see how things are going. So I find that while the one-on-ones are the staple thing that happens every two weeks, there's a lot of other behind-the-scenes work that's going on as well to make sure that that person is growing and feeling really fulfilled by their work. ROB: I know we've spoken a lot about the product side and the client side of working on the new project that I'm working on. There are some interesting technical sides to it as well. The client has found that they have had some issues with Haskell and running on M1 Macs. And so, they've decided to take the leap and use GitHub Codespaces as their primary development environment, which has been interesting. I had heard about it but only in the background. I hadn't read anything about it or hadn't had any direct conversations. I just heard that there was a thing. So it's been quite interesting to play with that. It's interesting the way the client is using it as well because they're using a Dockerized environment effectively inside Docker by using Codespaces. So you start the Codespace, which very basically is a Docker instance somewhere on GitHub's infrastructure. It's built very much for Visual Studio Code, and so you can just directly attach your Visual Studio Code session to the Codespace and go from there, but I'm a Vim user. I've started to feel like a bit of an old guard or a curmudgeon recently where I've been like; maybe I need to use Visual Studio Code. Maybe I should just unlearn my Vim key bindings and learn the Visual Studio ones. And people say, "Oh, you could just use The Vim key bindings in VS Code." I'm like, that's cheating. I spent the time to learn the key bindings for Vim. I will take the time to learn the key bindings for Visual Studio Code and use it for the way it's intended. So it's been interesting to understand how Codespaces works, not necessarily in the way, it's intended. So you can still SSH into a Codespace session, but then you lose all the lovely setup stuff that you might have on your local machine. So I did spend half a day porting my dotfiles which are based off thoughtbot's dotfiles, into something that Codespaces can use and made it publicly available. So if you go to github.com/purinkle/codespace, you can see what I use to set up my Codespace environment. And once that's set up, it becomes a bit easier because then you have all the things that you're used to running locally. It is very much early days for how the client is using it. And so they're really open to saying like, okay, let's find out what's not working, and let's work and figure out how to get it up and running properly. So one of the things we do find is that Codespaces do timeout after a while. And then you might lose, like, even if I've created a tmux session, that tmux session disappears. And so I have to go in and create it again. I'm not sure what the timeouts are. I haven't had time to look into what those timeouts are yet. But that's definitely the main pain point at the moment of it being used as a development environment. It's been interesting. It's been kicking around in the back of my head like the difference between developing locally and deploying locally. And it's something that I wanted to talk to people at thoughtbot and outside of thoughtbot as well to understand that more. Because I don't think you need everything running to develop locally, but you might need it to deploy locally. It's interesting to me to understand how different companies work on their products from that point of view. STEPH: Yeah, I'm selfishly excited that you are using Codespaces for a client project because I have kept an eye on it, and I'm very intrigued by it. But I also haven't used it for a project. And it sounds really neat. I'm curious, have you found that it has helped them with onboarding or if you need to switch from working on one application to another? Have you found that it has helped them with some of those? I'm guessing that's the problem that they're optimizing to solve is how do we help people run everything quickly without having to set it up locally? ROB: It's an interesting question because I don't have the comparison of trying to set up the environment as it was before. It was smoother. The main thing with access tokens because once you can set up your SSH keys and your GitHub tokens, it's just a case of running a script and letting it run. So yes, from that point of view, I can imagine if I tried to set up their previous environment, that it'd be a lot more challenging because they were using Vagrant and running things that way, which I know from experience would not be fun. And I know that my Mac fans would just be spinning all the time. It would be like an aeroplane was trying to take off. So I'm thankful for that, that I don't have that experience anymore that my machine is going to slow down all the time. We've had on a previous client who had a Dockerized environment, but you have to have it all running on your machine. There are pros and cons to everything with these things. And it's like you said, what is the problem they're trying to solve with introducing this setup? STEPH: Yeah, I can't decide if this is a good thing or a bad thing. But I'm also intrigued by the idea that if a team is using Codespaces, then that means everybody else is using VS Code. And you can still customize it so you can still have your own preferences. But that does set a standard, so everybody is using the same editor. There's a lot of cross-collaboration in terms of if you do run into an issue, then you can help each other out. Versus when I join other teams, everybody's using their preferred editor, and then there you may have a day where someone's like, "Oh, I'm really stuck because my particular editor is suddenly having a problem and can't connect." And then you have less people that are able to help them if they're not using that same editor. And I can't decide if I like that or if I hate it [laughs] in terms of taking away people's ability to pick and choose their editor. But then the gains of everybody is using the same thing which is nice and would be really great for pairing too. ROB: Yeah, that's an interesting point. I was talking to...I have a management coach. He's a PHP developer, and I'm a Rails developer. And we were talking about the homogenization of things nowadays. And is that good, or is that bad to use with stuff like RuboCop that lints everything, so it's exactly the same? Does that stifle creativity? But then, at the same time, the thing I like about Codespaces is I think we're biased coming at it from the point of view of Rails developers. And if you look at how you can use Codespaces in the browser directly from GitHub, that's quite interesting because now you're lowering the barrier to entry to get started and saying you don't need to have an editor. You don't have to set up everything. You can just do it from your browser. A few years ago, I used to volunteer or coach at an organization called codebar. They help people who are less represented in the tech community get represented in the tech community. And we would see a lot of people coming for sessions using...I forgot what it's called. What was it called? Cloud 66 or something. There was some remote development environment that people would come and say, "Oh, I've been using this," because they didn't know how to set up the necessary infrastructure to just get a Rails server going or things like that or didn't know how to set up Sublime or Atom or editor of choice. And it's really interesting if you remove your bias of 15 years of professional software development and go okay, if I were starting today, what would the environment look like, and how would I get started? I'm lucky enough that I've grown up with the web and seen how web development has changed and been able to gain more knowledge as it's appeared. I don't envy anybody who has to come into the industry now and suddenly have to drink from this firehose of all these different frameworks, all these different technologies. Yeah, I started off by just right-clicking and viewing source on HTML files back in 1998 or something ridiculous like that. And CSS didn't even exist or wasn't used. And so it's a much different world than 24 years ago. STEPH: That is something that Chris and I have mentioned on previous episodes where people are coming into software development, and as much as we love Vim and it sounds like you love Vim, our advice is don't start with Vim. Don't start there. You've got so much to learn. Start with something like VS Code that's going to help you out. And you make such a great point in regards to this lowering the barrier to entry. Because I have been part of a number of classes where you have people coming in with Macs or with a Windows machine, and then you're trying to get everybody set up. You want them to use the same browser for testing. And we spend like a whole class just getting everybody on the same page and making sure their machines are working or then troubleshooting if something's not. But if they can just go to GitHub and then they can run things seamlessly there, that's a total game-changer in terms of how I would teach a class, and it would just be far easier. So I hadn't even considered the benefits that would have for teachers or just for onboarding teams as well. But yeah, specifically for leading a class, I think that is a huge benefit. GitHub did some pretty cool stuff around when they were launching that as well because I went back and watched some of their GitHub Universe sessions that they had where they were talking about Codespaces. And one of the things that they did that I really appreciated was how they went about launching Codespaces. So initially, it was how fast can this be? Or what's our proof of concept? And I think when they were building this, they found it took about 45 minutes if they wanted to spin up an application and then provide you a development environment. And they're like, okay, cool, like, we can do this, but it's 45 minutes, and that's not going to work. And so then their next iteration, they got it down to 25 minutes, and then they got it down to 5 minutes. And now they've got it to the point that it's instantaneous because they're building stuff in the background overnight. And so then that way, when you click on it, it's just all ready for you. But I loved that cycle, that process that they went through of can we even do this? And then let's see, slowly, incrementally, how fast can we get it? And then, to get feedback, instead of transitioning their own internal teams to it right away, they created this more public club. I think they called it The Computer Club, something like that. And they're like, hey, if you want to be part of Codespaces or try out this new feature that we have, delete all the source and the things that you need locally, and then just commit to using Codespaces. And then, if you are stuck or if you have trouble, then your job is to let us know so then we can iterate, and we can fix it. I really liked that approach that they took to launching this product and then getting feedback from everyone and then improving upon it. ROB: Yeah, that sounds like an Agile developer's dream where you just put something out there that's the bare bones, and you're given license to learn from that experience and how people are actually using that tool. That's something we've actually tried to do on the client project at the moment is adding all the...now that there's a different flow in Germany, there are different questions we need to ask. And so that could be quite a complex thing to put into place. So what we said is what we're going to do is just put in the different screens, and all you have is one option to click. So you click that option, you go to the next one, go to the next one, go to the next one. Then we have something that the customer can click on and play with and understand, and then we can iterate on top of that. But it also allows us to identify areas of risk because you can go; oh, where does this information come from? But now we need to get this from a third-party service. So that's the riskiest thing we've got to work on here, where this other thing is just a hard-coded list of three-door or five-door cars. And so that's an easier problem to solve. So allowing yourself to put something that could be quite complex like GitHub Codespaces and go okay, we're going to put something out there. It takes 45 minutes to run-up. But we're telling you it takes 45 minutes to run it. We're not happy with it, but we want to learn how you're using it so that we can then improve it but improve it in the right direction. Because it might be that we get it to 20 minutes to start up, but you need it in half a second. That's a ridiculous example. Or it might be that you need to be able to use RubyMine with it instead of VS Code, and that's where the market isn't. That's the thing that you can't learn in isolation that you have to put something out there for people to use and play with. STEPH: There's one other cool feature I want to highlight that I realized that they offer as well. So in the past, I've used a tool called ngrok, which then you can make your localhost public so other people can access. You can literally demo what you're working on locally, and someone else can access it. And I think that it's very cool. It's come in handy a number of times. And my understanding is that Codespaces has that feature where they can make your localhost accessible. So your work in progress you can then share with someone, and I love that. ROB: Oh, that's really interesting. I didn't know you could do that. I know you could forward ports from your local machine to that. But I didn't know you could share it externally. That'd be really cool. I can see how that can be really helpful in demos and pairing. And it makes sense because it's not running on your computer. It's running on some remote architecture somewhere. That's interesting. STEPH: Well, that's the dream I've been sold from what I've been reading about GitHub Codespaces. So if I'm telling lies, you let me know [laughs] as you're working further in it than I am. But yeah, that was one of the features that I read, and I was like, yeah, that's great because I love ngrok for that purpose. And it would be really cool if that's already built into Codespaces as well. ROB: ngrok is really interesting with things like trying to get third-party services to work. So from, the previous client, they wanted an Alexa Skill. And so, if you're trying to work with an Alexa Skill, you have to sign in from Amazon's architecture onto your local machine. You have to use ngrok as the tool there. So I wonder if that could potentially solve a problem where if there are three developers trying to develop on this if you could point to one Codespace that you're all working on rather than... Because the problem we had was if me or Fritz or Rakesh was working on this, we'd have to go and then change the settings on the Amazon Alexa Skill to point to a different machine. Whereas I wonder if Codespasces allows you to have this entry point, you could point to like thoughtbot.codespace.github.com or something like that that would then allow you to share that instance. That's something interesting that I think about now. I wonder if you could share Codespace instances amongst each other. I don't know. STEPH: Yeah, I'm intrigued too. That sounds like it'd be really helpful. So circling back just a bit to where we were talking about wearing different hats in terms of working on client work, and then also working on the team, and then also potentially some sales work as well, I'm curious, how do you balance that transition? How do you balance solving hard problems in a codebase and then also transition to solving hard problems in the management space? How do you make all of that fit cohesively in your day or your week? ROB: The main thing that somebody said to me recently is that you can only do so much in a day, and it's about the order that you approach those things. And just be content with the fact that you're not going to get everything done. But you have to make sure that you work on things in the right order and just take your time and then work through them. I read a really good book recently that was recommended to me by my coach called Time Off. And it's all about finding your rest ethic, which sounds a bit abstract and a bit weird. But all it is it's about understanding that you can't be working 100% all the time. It's not possible. As developers, sometimes we can forget that we're creative people, and creativity comes from a part of your brain that works subconsciously. So it's important for you to take breaks throughout the day and kind of go okay; I use the Pomodoro Technique. So I have an app that runs, and every 25 minutes, I just take a little break. I don't use it in the way that it's supposed to be used. I just use it to give me a trigger to have a break every 25 minutes. And so in that time, I'll just step away from my computer. I'll walk to the kitchen, grab a glass of water. I usually have a magazine or a book next to my table. So I have a magazine here at the moment. I'll just read a page of that just to kind of rest my eyes, so they focus at a different level but also just to get my brain thinking about something else. And it seems counterproductive that like, oh, you're stepping out of what you were doing. But then I find like, oh, I suddenly have a little refresher to like, oh, I need to get back into what I was doing. I know where I've got to go. That thing that I was thinking about now makes a little bit more sense. And even if it's a bigger break, give yourself the license to go for a walk and just kind of clear your head. And a big thing about going for a walk is not to concentrate on completing the task of walking but to concentrate on the walk itself and taking the things that are happening around you. And let your mind just kind of...you'll sometimes notice that oh, I can hear a bird. But that bird's been chirping for five minutes, and you didn't notice because your mind's kind of going. And if you concentrate on, I just want to complete this walk, that's what I'm out here to do, then you lose that ability to let your mind reset. That's a big thing that I'm working on personally to concentrate on the doing rather than the getting done. And it ties into the craft of being a software developer because if you concentrate on the actual writing of the code and the best practices that we all believe in, you end up with something better that you don't then have to revisit at a later time. Where if you just try and get something done, you're just going to end up having to come back to it or have to revisit in some other way. I've actually got a blog post coming out soon about notifications on phones. I'm a big believer that your phone belongs to you and that if your work wants you to have work notifications on your phone, then they could buy you a phone just for that purpose. The only thing where I kind of draw the line is I have notifications for meetings on my phone because I can't think of another way to get those things to ping up at me. And I understand that there are jobs where you do need to have those sorts of notifications, especially things like where you're on call; it's a big thing. But when it comes to things where a manager wants to get a hold of you straight away, from a trust point of view, that's where I think things fall down. And you're questioning, like, okay, why does this person need to get hold of me at 7:00, 8:00, 9:00, 10:00 o'clock at night? And should I be available? We build by the day at thoughtbot. And so when I find, not when I find but when I talk to people, and they say, "Oh, I was still working at 7:30, 8:00 o'clock," I will say, "Why? You're devaluing your own time at that point because we're not billing any extra for that time. So you're making your craft and your skill...you're cheapening it. And I want them to relish the skills and competencies that they have. That's a big thing for me. We're very lucky at thoughtbot that we can draw a boundary at the end of the day and go, okay, that's it. There's no expectation for me. It is much more difficult at product companies. But yeah, I think it's something that as an industry, and it's a bigger thing as a society, especially with younger people coming into the industry who have never worked in an office and may never work in an office, that idea of where is the cutoff? For so much of the pandemic, the people I would get concerned about the most are the people whose beds I could see behind them because I'm thinking to myself, you spend at least 16 hours a day in that same room. And that's going to become the norm for people. And if people don't have those rest periods and those breaks and aren't given the opportunities to do that by their managers, then it's not going to end well. And happy people and fulfilled people do the best jobs from a business point of view. But that's never the way I approach it, but that's what I say to people. STEPH: I think that's one of the biggest mistakes that I made early on in my career, and even now, I still have to coach myself through it. It's like you said, we are creative people and people in software and in general and not just developers, but it's a creative craft. And I wouldn't step away to take breaks. I just thought if I pushed hard enough, I would figure it out, and then I could get done with my work because I was so focused on getting it done versus the doing, as you'd highlighted earlier. I haven't really thought about it in that particular light of focusing on this is the thing that I'm working on. And yes, I do want to get it done, but let's also focus on the doing portion of it. And so I wouldn't step away for walks. I wouldn't step away for breaks. And that is something that I have learned the hard way that when I actually gave myself that time to breathe, if I gave myself a moment to relax, then I would come back refreshed and then ready to tackle whatever challenge was in front of me. And same for keeping a magazine that's near my desk; I have found that if I keep a book or something that I enjoy...because, at some point, my brain is going to look for some rest, like, it happens. That's when we flip open Twitter or Instagram or emails or something because our brain is looking for something easy and maybe a little bit of like brain candy, something to give us a little hit. And I have found that if I keep something else more intentional by my desk, something that I want to read or that I'm enjoying, then I find that when I am seeking for something that's short that I can look at, that I feel more relaxed and fulfilled from that versus then if I go to Twitter, and then I see a bunch of stuff, I don't like, and then I go back to work. [laughs] And it has the opposite effect of what I actually wanted to do with my downtime. I love the sound of this book. We'll be sure to include a link in the show notes because it sounds like a really good book to read. And I've also worked on improving the setup with my phone and notifications, where I have compartmentalized all the work-related apps into one folder, and then I keep it on the third screen of my phone. So if I want to see something that's work-related, it's very intentional of like, I have to scroll past all of the stuff that matters to me outside of work and then get to that work section and then click in that folder to then see like, okay, this is where I have Slack, and Gmail, and Basecamp, and all the other things that I might need for work. And I have found that has really helped me because I do still have the notifications on my phone, but at least putting it on its own screen further away from the home screen has been really helpful. ROB: Do you find that you still get distracted by that, though, when you're in the flow of doing something else? STEPH: I don't with my phone. I am a person who ignores my phone really well. I don't know if that's a good thing or a bad thing, [laughs] but it is a truth of who I am where I'm pretty good at ignoring my phone. ROB: That's a good skill to have. If there's any phone in the room and a notification goes off, my head swivels, and I pivot, and I'm like, oh, yeah, some dopamine hit over there that I can get from looking at somebody else's notification. STEPH: I have noticed that in the other people that I'm around. Yeah, it's that sound that just triggers people like, oh, I got to look. And even if you know it's not your phone like you heard someone else's phone ding, it still makes you check your phone even though probably there's a part of your brain that recognizes like, that wasn't mine, but I'm still going to check anyways. And I have worked hard to fight that where even if I hear my phone go off, I'm like, okay, cool, I'll get to it. I'll check it when I need to. And I'm that person that whenever apps always ask me, "Can we send you notifications?" I'm like, no, you may not send me notifications. [laughs] Something else you said that I haven't thought about until just now is the idea that there are some people who have never worked in an office or may never work in an office because we are leaning into more remote jobs. And that is fascinating to me to think about that someone won't have had that experience. But you make such a good point that we need to start thinking about these boundaries now and how we manage our remote work and our home life because this is, going forward, going to be the new norm for a number of people. So how do we go ahead and start putting good practices in place for those future workers? ROB: One of the things, as we've hired people from a remote point of view who've only worked with thoughtbot remotely, is the idea of visibility. And I don't mean the visibility of I want to see when somebody's working but maybe the invisibility of people. Because you can't see when people are taking breaks, you assume that everybody is working all the time, and so then you don't take those breaks. And so this is something we saw with people who we hired in the first six months of being remote. And they were burning out because they didn't realize that other people were taking breaks. Because they didn't know about the cultural norms of how we worked at thoughtbot. But people who had worked in the studio would know that people would get up and have breaks. People would get up and go get a coffee from a coffee shop and then have a walk around. They didn't know that that was the culture because they bring the culture from other places with them. But then it's much harder to get people to understand your way of working and how we think that we should approach things when you are sat in isolation in a room with a screen. And that's something that we've had to say to people to break that down. And even things that we took for granted when we worked in a studio where somebody would get up and ask somebody if they could pair with them even if they weren't on the same project. Somebody might have more Elm knowledge or React Native knowledge, or Elixir knowledge. And you'd get up and say, "Hey, can I borrow some of your time just to go over this thing, to pair?" And everybody would say, "Yeah, yeah, I can find some time. If not now, we can do it later." And recently, we've had people saying, "Oh, is it okay if we pair across projects? Is it okay if we pair with other people?" It's like, "Yeah, pair." One of the big things we say is that we have this vast amount of knowledge across thoughtbot, across the world that we can tap into and that you can use. And that's just one example of how do you get those core things that you take for granted and help people understand them? Because you don't know what people don't know. And it's all about that implied knowledge. So that's something that we learned. And we try and say to people and instill in them about yeah, take breaks. You can pair with people. There are people who bring in culture from other places with them. But then, to go back to where you started, how do you start with people who have no culture with them or have the culture of coming from maybe from school, or university, or from a different industry? How do you help those people add to your culture but also learn from your culture at the same time? Big people problems. STEPH: Have you found any helpful strategies to normalize that take a break culture? ROB: One thing we tried, but it doesn't last very long because people are lazy, is putting it in Slack saying, "I'm going for a break." And you can do that, but it's so artificial. After a week or two weeks, people just stopped doing it. It was through conversation. We have a regular retrospective as the Launchpad II team where we talk about what is working, what isn't working. And we have such a trusting environment where people will say things along the lines of this isn't working for me, or I feel like I'm burning out. Then we will talk to each other about it and figure out where it comes from. And it's a good point to raise that I don't think we have explicitly addressed it. But it is something that we will address. I'm not going to say could address; we will address it. I will talk to our latest hire, Dorian, who I have a one-on-one with next week, and to kind of talk to him about it. And we should maybe try and codify that in our handbook somewhere so everybody can learn from it, at least start a strategy and a conversation. Because I don't think it is something that we do talk about. It's the problem of being siloed and being remote and time zones as well. A lot of stuff that Launchpad I knows Launchpad II doesn't necessarily know because we only have three, maybe, hours if people are based on the East Coast where we overlap. I have meetings with Geronda, who's our DEI Program Manager, and she lives in Seattle. And so sometimes I'll talk to her at 5:00 o'clock, and it's 7:00 o'clock in the morning for her. And you have different energy levels. But yeah, so we spend time to try and figure out how we work together. STEPH: Yeah, I like that idea of highlighting that we take breaks somewhere that's part of your expectations as part of your role. Like, this is an expectation of your role; you're going to take breaks. You're going to step away for lunch. You're going to stick to a certain set of hours in terms of having like an eight-hour workday with a healthy lunch break in there. I think that's a really good idea. On the Boost team, I have found that people have adopted the habit of not always but typically sharing of, like, "Hey, I'm stepping away for a coffee break," or "I'm having lunch. Maybe like a late lunch, but I'm taking it," Or "I am stepping away for a walk." You often see later in the afternoon where there are a number of people that are then saying, "Hey, I'm going for a walk." And I feel that definitely helps me when I see it every day to reinforce like, yes; I should do this too because I already admitted I'm bad at this. So it helps reinforce it for me when I see other people saying that as well. But then I can see that that takes time to build that into a team's culture or to find easy ways to share that. So just putting it upfront in like a role expectation also feels like a really good place to then highlight and then to reinforce it as then people are setting that example. ROB: One thing that Nick Charlton tried to introduce was a Strava group. There's a thoughtbot Strava group. So you can see if people are members of it that they've been walking and things like that. It was quite an interesting way to automate it. I think it fell off a cliff. But it was something that we did try to how can we make the visibility of this a little bit easier? But yeah, the best thing I've seen is, like you say, having that notification in Slack or somewhere where you can see that other people are stepping away from their keyboards. STEPH: Well, as you mentioned, solving people problems is totally easy, you know. It's a totally trivial task although I'm sure we could spend too many hours talking about it. All right, so I do have one more very important question for you, Rob. And this goes back to a debate that Chris and I are having, and I'd love to get you to weigh in on it. So there are Pop-Tarts, these things called Pop-Tarts in the world. And I don't know if you're a fan, but if you were given the option to eat a Pop-Tart with frosting or a Pop-Tart without frosting, which one do you think you would choose? ROB: That's an interesting question. Is there a specific flavor? Because I think that the Strawberry Pop-Tart I would have with frosting but maybe the chocolate one I have without. I know there are all sorts of exotic flavors of Pop-Tarts. But I think I would edge towards with frosting as a default. That's my undiplomatic answer. STEPH: I like that nuanced answer. I also like how you refer to the flavors as exotic. I think that was very kind of you [laughs] other like melon crushed or wild flavors that they have. Awesome. All right. Well, I think that's a perfect note for us to wrap up. Rob, thank you so much for coming on the show and for bringing up all of these wonderful ideas and topics and sharing your experience with Codespaces. For folks that are interested in following your work or interested in getting in touch with you, where's the best place for them to do that? ROB: Yeah, thank you so much for having me. It's been fantastic to have a chat. If people do want to find me, the best place would be on Twitter. So my handle on Twitter is @purinkle which I understand is hard for people to maybe understand via a podcast, but we'll put a link in the show notes so people couldn't find me more easily. And that's probably also a good time to say that I am actually trying to find a development team lead to join our Launchpad II team. So we are looking for somebody who lives in Europe, Middle East, or Africa to join our team as a developer and manager of two to three people. There's more information on the thoughtbot website, and I do tweet about it very, very often. So feel free to reach out to me if that's of any interest to you. STEPH: Awesome. We'll be sure to include a link to that in the show notes as well. On that note, shall we wrap up? ROB: Yeah, let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Geriatric millennials unite.Learn more about GitHub's move to put prebuilt Codespaces into public beta, plus check out CodeSandbox, home of self-proclaimed lazy developers.Meanwhile, in blockchain: Polygon, a solution designed to expand transaction efficiency and output for Ethereum, raised $450 million “to consolidate its lead in the race to scale Ethereum.”Is Decentraland the most annoying blockchain project? The competition is fierce.The 2022 Java Developer Productivity Report found that microservices and CI/CD are decreasing developers' productivity, not increasing it. The team talks through what that means.This week, Ben recommends the book Appleseed by Matt Bell, Cassidy recommends the productivity app Centered, Adam points listeners to Unix-like operating system SerenityOS, and Ceora shouts out Tanya Reilly's talk-turned-blog-post Being Glue.Find Adam on LinkedIn here.

Geriatric millennials unite.Learn more about GitHub's move to put prebuilt Codespaces into public beta, plus check out CodeSandbox, home of self-proclaimed lazy developers.Meanwhile, in blockchain: Polygon, a solution designed to expand transaction efficiency and output for Ethereum, raised $450 million “to consolidate its lead in the race to scale Ethereum.”Is Decentraland the most annoying blockchain project? The competition is fierce.The 2022 Java Developer Productivity Report found that microservices and CI/CD are decreasing developers' productivity, not increasing it. The team talks through what that means.This week, Ben recommends the book Appleseed by Matt Bell, Cassidy recommends the productivity app Centered, Adam points listeners to Unix-like operating system SerenityOS, and Ceora shouts out Tanya Reilly's talk-turned-blog-post Being Glue.Find Adam on LinkedIn here.

North Korea Hacked, Wormhole Hacked, FBI & Pegasus & GitHub Outage   Cybersecurity News CyberHub Podcast February 3rd ,  2022   Today's Headlines and the latest #cybernews from the desk of the #CISO: North Korea Hacked Him. So He Took Down Its Internet Cryptocurrency platform Wormhole hacked for an estimated $322 million GitHub outage impacts Actions, Codespaces, Issues, Pull Requests FBI Confirms It Bought Spyware From Israel's NSO Group Cisco Patches Critical Vulnerabilities in Small Business RV Routers Trend Micro Patches Vulnerabilities in Hybrid Cloud Security Products   Story Links: https://www.wired.com/story/north-korea-hacker-internet-outage/#intcid=_wired-verso-hp-trending_cfd2d0a8-4f07-4725-b1f5-753910b85029_popular4-1 https://therecord.media/cryptocurrency-platform-wormhole-hacked-for-an-estimated-322-million/ https://www.bleepingcomputer.com/news/technology/github-outage-impacts-actions-codespaces-issues-pull-requests/ https://www.securityweek.com/cisco-patches-critical-vulnerabilities-small-business-rv-routers https://www.securityweek.com/trend-micro-patches-vulnerabilities-hybrid-cloud-security-products https://www.securityweek.com/fbi-confirms-it-bought-spyware-israels-nso-group   “The Microsoft Doctrine” by James Azar now on Substack https://jamesazar.substack.com/p/the-microsoft-doctrine   The Practitioner Brief is sponsored by: KnowBe4: https://info.knowbe4.com/phishing-security-test-cyberhub  ****** Find James Azar Host of CyberHub Podcast, CISO Talk, Goodbye Privacy, Digital Debate, and Other Side of Cyber James on Linkedin: https://www.linkedin.com/in/james-azar-a1655316/ Telegram: CyberHub Podcast ****** Sign up for our newsletter with the best of CyberHub Podcast delivered to your inbox once a month: http://bit.ly/cyberhubengage-newsletter ****** Website: https://www.cyberhubpodcast.com Youtube: https://www.youtube.com/c/TheCyberHubPodcast Rumble:  https://rumble.com/c/c-1353861 Facebook: https://www.facebook.com/CyberHubpodcast/ Linkedin: https://www.linkedin.com/company/cyberhubpodcast/ Twitter: https://twitter.com/cyberhubpodcast Instagram: https://www.instagram.com/cyberhubpodcast Listen here: https://linktr.ee/cyberhubpodcast   The Hub of the Infosec Community. Our mission is to provide substantive and quality content that's more than headlines or sales pitches. We want to be a valuable source to assist those cybersecurity practitioners in their mission to keep their organizations secure.   #cybernews #infosec #cybersecurity #cyberhubpodcast #practitionerbrief   #cisotalk #ciso #infosecnews #infosec #infosecurity #cybersecuritytips #podcast #technews #tinkertribe #givingback #securitytribe #securitygang #informationsecurity

Recording date: Dec 30, 2021John Papa @John_PapaWard Bell @WardBellDan Wahlin @DanWahlinCraig Shoemaker @craigshoemakerSantosh Yadav @SantoshYadavDevBrought to you byAG GridIonicResources:GitHub Stars programInDepthDevNgRxOpen Learning InitiativeRxJs CourseNgRx CourseYouTube ChannelThis Is Tech TalksHow to make your first pull request on GitHubCreate your first pull requestGitHub docs - creating a pull requestGoogle Summer of Code (GSoC) programAngularGoogle GDE'sMinesweeperGit version control systemGitHubVisual Studio CodeGit cheat sheetDesktop for githubBreeze repo on GitHubFork a repoSetup Git (GitHub docs)Clone a repositoryEasiest way to edit a repo in github.com with github.devGitHub CodespacesSetting guidelines for contributorsAdding a contributing fileBreeze JSVikram Subramanian from GoogleTimejumps00:53 Wards M1 purchase03:46 Guest introduction04:30 What's GitHub star?06:49 Advice for getting started on open source?08:24 Why should someone get involved in contributing to open source?10:38 Sponsor: Ionic11:18 What's Google Summer of Code?15:22 Git vs GitHub?19:47 What's cloning, pulling, pushing?21:38 Marker 1021:59 How do I make my first contribution to a repo?23:23 What's a fork?24:56 What's a clone?25:34 Sponsor: Ag Grid26:39 How do I fix the code?28:23 Editing on GitHub31:03 What are Codespaces?35:43 Using GitHub dev online38:20 What's a pull request?40:36 What got you excited about coding?46:36 What is a Push?Podcast editing on this episode done by Chris Enns of Lemon Productions.

This is our third Kaizen episode in which Adam, Jerod & Gerhard talk about GitOps the wrong way, ask questions with Honeycomb and realise that they must be holding the CDN wrong, and the effort that has been going into moving all changelog.com static files from regular volumes to an S3-like object store. If you like a good yak shake, listening to this one is a lot more fun than doing it. Gerhard is most excited about the Ship It Christmas gifts that we have been preparing for you. While GitHub Codespaces is not going to be part of the upcoming Christmas special episode, today's talk covers why investing in a Codespaces integration is worth it. Changelog #459 and Backstage #20 are related to this topic.

This is our third Kaizen episode in which Adam, Jerod & Gerhard talk about GitOps the wrong way, ask questions with Honeycomb and realise that they must be holding the CDN wrong, and the effort that has been going into moving all changelog.com static files from regular volumes to an S3-like object store. If you like a good yak shake, listening to this one is a lot more fun than doing it. Gerhard is most excited about the Ship It Christmas gifts that we have been preparing for you. While GitHub Codespaces is not going to be part of the upcoming Christmas special episode, today's talk covers why investing in a Codespaces integration is worth it. Changelog #459 and Backstage #20 are related to this topic.

Listen to the Changelog: https://changelog.com/podcast/459 (15mins in)TranscriptYou said something interesting about the preciousness of our development environments… And I'm with you that we've commoditized the servers, but we definitely have not commoditized dev, because it's so intricate, it's so set up… Sometimes it's like “There be dragons. Please don't touch my laptop, because it works right now, but I'm not sure if it's gonna work tomorrow.” I do hate that. I think it's almost a different skillset, of maintaining that. There's overlap between development and the maintenance of a development environment in terms of things that you need to learn… But it's almost a different task altogether. So I don't like that about it, but it's still very true that our development environments are precious to us, and they're tweaked, and configured, and customized, and all the things. So I'm sure there's probably lots of resistance to this…[00:11:59.29] We talk about our setup - we have probably tens of thousands of lines of code, and very few dependencies in our stack, but GitHub is 14 years old, and there's a million plus commits, and I'm sure the dependency list is very long… What kind of effort was this? Tell us the story of bringing it along.CORY WILKERSONIt is. These are all very, very true points. You know, the last thing I wanted to do was kind of be the vessel that went out to GitHub and said “I wanna change your development environment”, because these things are so precious. Like, I'm an engineer, too. I think my environment is very much precious. And here I was, kind of the face in GitHub of saying “Well, we think we have a better way. Come join us over here.”And I started off on this journey as a skeptic. I think I shared some of this, too… I didn't think this would be a fruitful journey necessarily. I was just gonna go do my level best as an employee, see if I could make it happen, build moment etc. and see if I could find something out there. Now, on the other side of this journey, I feel like I'm completely on the other end now, where I'm just like “This is the future. This is the way that we will absolutely build software…”But going back to the core of the story, it was literally just me out there, calling on my friends to begin with, inside of GitHub. I'd been there for five years, and the first few years were just me tapping into relationships, saying “Hey, can you give this thing a shot? Can you try this out? I wanna get your feedback and feelings about where this is at.” And no one could yet use it on our core repository. We call it github/github - the organization is GitHub, the repository is GitHub. We didn't have this thing standing up in a Codespace yet, but we had other repositories that were compatible with Codespaces.So I'd go out and ask favors of friends, and just be like “Can you try this out and give me some feedback?” And generally, the feedback I would get back was – first it was resistance, like “Why would I do this? It's productivity lost; tax on productivity. I don't trust HTTP. There's gonna be lag”, that kind of feedback. But then people would try it and they'd come back and be like “Huh. That was maybe better than I thought.”At the same time, as I hacked in this space too, I was starting to get some of that “Well, there's something here.” The big a-ha moment for me was connecting VS Code into my Codespace out in the cloud and still retaining that local development experience. So it felt to me like it was still very local. The magic is the synchronization that's happening between the local environment and the cloud. It feels totally transparent.But that aside, it started with just a very small number of users. So we would go back to leadership in GitHub and talk about progress we were making… And the early days, the story was “I have five people that have responded positively to Codespaces.” So not much of a story, but starting to kind of make a little bit of progress. And then maybe it was ten people.Then, the next iteration on this was like “Well, let's go find a team. Let's get a full team on Codespaces. How can we get a single team - 6 to 8 people - committed to using Codespaces, and stick in this thing?” At this point we'd had this other effort running on the side to get github/github, the core github.com repository, compatible with Codespaces. And we'd gotten it to a point – we detail how we did this in the blog post - where performance was mostly acceptable. So now we could go shop this with a team that worked primarily on GitHub.com and see what their experience was. And we're making progress there. So we're ramping in – I think y'all have talked to Kyle Daigle in the past. Kyle was the leader of that effort that got this team spun up inside of Codespaces on GitHub core. And again, it was somewhat retentive. People were sticking, and going like “Wow, this is not what I thought. It's better than maybe what I thought.”[00:15:59.11] But I think the real breakthrough moment came when we stopped calling this dogfooding. You hear this term all the time, dogfood… I think it actually originated – I looked up on Wikipedia; I think the term originated inside of Microsoft a number of years ago.ADAM STACOVIAKIs that right?CORY WILKERSONBut GitHubbers, my colleagues don't respond well to that term. Dogfooding doesn't inspire anyone to go do anything. Just like “Eat the dogfood? Who feels good about that?” And so what we did was we launched what we called the GitHub Computer Club, and I would love to dedicate a full episode on this. It's a really interesting concept, and something I hope to bring out to the industry. But we asked people to join the GitHub Computer Club. And in doing so, they took this commitment or oath. I wrote up this script, “I do solemnly swear to never – no shadow compute, not desktop compute. I'll join this thing and forever be member of the elite, exclusive GitHub Computer Club.”ADAM STACOVIAKI love that.CORY WILKERSONWe made a bunch of noise about it… Yeah, people loved it.ADAM STACOVIAKThat's so cool.CORY WILKERSONPeople straight up were just like, “This is great. Let me in. I want a membership card.” And in doing so – we had to give them something in return. So they would join the computer club, but we offered to our “exclusive” members what we call the concierge team. And this team was built to kind of support their productivity and success inside of Codespaces.So the second these people had friction - you know, one of the requirements of entering the computer club was that you had to kind of raise your hand. You couldn't disappear and go back to local desktop. You had to virtually raise your hand and say “I'm about to opt out of this, because Codespaces can't keep my business right now.” And the concierge team that we had built could swoop in, respond to “What's going on here? Let's dig into it. Why can't we keep your business in Codespaces?”We continued to play that model back and forth between Computer Club and concierge team, until we had built the product and built enough momentum inside of GitHub that one day we kind of looked around and we were like “Wow, we have hundreds of people developing GitHub.com and GitHub Codespaces.” And I think the real story there is just commitment to make it happen. We want it to be successful with this, and not just go talk about it in the market, but actually show that this is a better tool for us. The computer club is still going strong. People are demanding that I give them satin and denim jackets; I'll get around to that at some point.JEROD SANTOWell, I hate to break it to you, Cory, but GCC is already taken as an acronym, so… You've got a namespace conflict on that one.CORY WILKERSONYeah… Well, maybe the Codespaces Computer Club, so we can go with GCCC.JEROD SANTOThere you go.ADAM STACOVIAKAll the C's. I like this aspect because you treat this like a customer scenario. You built a product, and you have to retain customers. And you're actually exercising a great principle for anybody building a product, which is “Talk to your users.” And when they have trouble - swoop in, as you had said, understand those problems and be committed to fixing them. I think that's a great way, a great story for how Codespaces became powerful inside of GitHub, because that's exactly how you build a product. Not just “Let's just try this thing and hopefully our internal team adopts it by force.”As you had said, you wanted to go along with your employee card and be able to see if Codespaces could work, and out the other end you became a believer. But you're not forcing GitHub engineers to use it, you're asking them to try it. In this case, the Computer Club, with the oath… And then as you said, you look up and you see hundreds now.CORY WILKERSONI think that's right. The position was – no Fiat. We didn't wanna lead with “You have to do this.” That's the absolute wrong way to get adoption in your product. We wanted to literally win the business of our colleagues. We wanted to build such a fantastic experience in Codespaces that people would choose it. And yeah, I think the Computer Club probably boosted adoption a little bit, do doubt about it… But what made that work –ADAM STACOVIAKYou've gotta use some emotion in there. You've gotta put some emotion in there.CORY WILKERSONYeah, exactly.ADAM STACOVIAK[00:19:59.04] You have to get them excited.CORY WILKERSONIt had to have a soul. It needed some soul behind it, that was the idea. And the fact that we did respond to this – we actually did win business. When things didn't go well and when people wanted to opt out, they could, and they would, for a week, or whatever… But the goal was “How do we get them back in here, kind of remove whatever that impediment is, and get them productive in Codespaces again?”JEROD SANTOSo what happens if you take the oath and you go back? Do you chop off a finger, or what's the penalty? [laughs]CORY WILKERSONWell, you know, we leave that intentionally vague, so people can assume the worst. No, I don't know that we've had any real regression there just yet, which is good. Codespaces is super-retentive. I think we have people from time to time use local desktop. We have a colleague – this is actually in the blog post maybe… A colleague of mine reported the other day, she said “I was using local development. My environment broke, so I switched over to Codespaces.” And she was like “I actually shipped my task in my Codespaces before my local development environment rebuilt.” I think everyone was like “Wow, that is such a good story.” And it's so true. It's kind of the experience we're all having right now with Codespaces.We talked about it, again, in the blog post - you click a button and the environment is live. So for every new engineers that joins GitHub, I think they all are probably fairly spoiled at this point, because day one they click a button and they're able to run that entire GitHub.com environment. It's just been really incredible to watch.ADAM STACOVIAKSo Cory, the way you've explained the flow of this GitHub Computer Club seems a little smooth. I've gotta imagine you hit some friction. Can you share some of the struggle that you hit? Some opposing forces in the process of rolling this out.CORY WILKERSONYeah. Basically, it started with a bunch of “No” throughout GitHub. I think people had seen previous iterations of Codespaces… We announced it, I think, in May of 2020, at GitHub Satellite.ADAM STACOVIAKYeah. The first tweet I saw about it was Kelsey Hightower's, actually.CORY WILKERSONOkay, yeah.ADAM STACOVIAKSo that's May 2020.CORY WILKERSONIt's been out there for a while… And I think when people first try to use it inside of GitHub, there was a bit of friction. It didn't work for them, and I think first impressions can sometimes be lasting impressions. So when I went out there, I'm just like “Use this thing. It's great. It's really evolved. We feel pretty proud of it”, and it was just a bunch of “No” left and right. So then it became “How are we gonna build this business?” And yes, the Computer Club was a big boost, and the concierge team certainly was a huge, probably the most high leverage practice we discovered along the way… But a lot of this was just like startup style practices. We're building a business inside of GitHub, and I think that's maybe a useful context for anyone that's trying to build adoption of their own products in-house; you've gotta think of this sometimes as like “This is your own business. How are you gonna build it inside of GitHub, in what is a kind of very stubborn audience?” And I'm a developer, I can say that; we're somewhat stubborn and we find the tools that work well for us, and if someone comes and says “I wanna change those”, your response is gonna be “Don't.”ADAM STACOVIAK“Don't touch my local dev environment, Cory.”CORY WILKERSONYeah. And we'll get to this in a second - one of the great parts about Codespaces is that we just commoditized the compute part of this. The environment is now running somewhere else. But dotfiles, VS Code setting sync, VS Code extensions - we bring those all to the environment. So you don't lose your curated workbench. If you've got a dotfiles repo set up on GitHub right now, we bring that into the compute environment; we bring your environment and your personality, your expression of yourself captured in code into that environment. We bring your W out to your compute, which I think is a really nice touch. So you get the unburdened computer running in the cloud so you freed up your local machine, but you can still bring your preferences into that environment.[00:23:54.17] I digress… Going back to building the business a little bit - it felt like startup tactics. So we had the concierge team, we had the Computer Club… We had effectively guerilla marketing. We were out on Slack every day, looking for opportunities to say “Have you tried Codespaces?” People were receiving M1 architecture Macs, and the github/github build just would not yet work. We had not put in the investment to make the github/github run on the M1 Mac, so we'd say “Hey, have you tried with Codespaces yet?” And people would be like “Well, I guess I'll try. That feels like my only path right now.” And they'd click a button, they'd come back an hour later, or a day later, and just be like “What in the heck? This is incredible. How was this even possible?” And those people you just win for life. That's their full mode of operating. So that was the guerilla marketing angle…We did pairing sessions… So we were up in front of everyone all the time, saying “If you wanna get started, here we are. We're gonna hold your hand through this and show you the ropes, show you how we're doing.” Kind of social proof, I think, which is really valuable there. All hands – we'd get in front of the entire company and demo the thing, and be like “Look at this, it's incredible” and just try to build hype.We connected with the right people… I maybe loathe to call them influencers, but the people inside of GitHub that every engineer look up to. They look up to them and say like “This is the person that I aspire to be at some point.” We converted them. We want their business. They're kind of like trendsetters and tastemakers internally. And then really it boiled down to ruthless prioritization. So we listened to our users, “What do you need?” and we demonstrated that we could follow through on those things. For some reasons, someone was trying to run some arcane karma test somewhere that wasn't executing for them. It's just like “Alright, great. Let's figure out how to make sure that works in this environment.” That kind of thing. Even small tasks like that were important in building momentum.And then I'll say it again - one day we just looked up and we'd gone from a bunch of “No” to a bunch of super-fans inside of GitHub. We have cheerleaders. If you go out and look on Twitter right now, the day after we kind of announced Codespaces to the world, they were just like – GitHubbers were out there very enthusiastic about the thing, and it was a very genuine response. We didn't ask anyone to go do that. People were just that enthused about what we built.ADAM STACOVIAKYeah. I saw a tweet from Kelsey Hightower - again, I'll mention Kelsey… I don't know if this tweet was actually towards Codespaces or the announcement, but the timing - it was the same day, I believe, so I think it was a subtweet around it, but he said “Back in the day we wrote code on our own computers.” So I'd assume that he was reflecting on Codespaces and the announcement, but I wasn't sure of that.CORY WILKERSONI saw that, too. I mean, you used to run your server in a grey tower, beige tower underneath your desk too, right? Those days are gone, it kind of feels like. This is this next wave - we're now moving development environments out into the cloud. It just feels to me like two years from now we're gonna see some incredible adoption in this space.ADAM STACOVIAKYou mentioned a bunch of No's in the adoption flow… At what point was Nat a believer in Codespaces?CORY WILKERSONYou know, Nat holds a very high bar. I remember, as we were trying to get GitHub running inside of Codespaces, I'd go back to Nat and we'd show him “Hey, now instead of 45 minutes it's 20 minutes. We've made these changes.” And he was like “That's super-cool. Not good enough.” And we totally agreed, we're like “Yup, it's not good enough, but I just wanted to show you progress.” We'd get that feedback, and then we'd come back again and say “We're down at ten minutes.” “That's great. It's not good enough”, and everyone's like “Yeah, you're right, it's not good enough. It's gotta be seconds for it to be the experience we want.” That was kind of the iterative experience.I think Nat has been a believer in where this thing could go, from kind of the outset of the journey. It's just been a bit of a slug as we worked from the very early days of like “Look, we have all this tech orchestrated that can produce this effect of a Codespace”, maybe the early prototype, down to now the ten second story inside of GitHub. That didn't happen overnight.[00:28:08.25] But the good news is most of that - almost all of that now - has made it into the product itself. So the changes that we've discovered along the way didn't just benefit github/github and the GitHub.com repository, it benefitted the entire product. I think Nat's a super-fan now. I've got some screenshots from Nat that I look at from time to time, that keep me pretty enthused about the progress we've made.

Rfr012 - Logopäden lieben diese Folge

About JasonJason is now the Managing Director at Redpoint Ventures.Links: GitHub: https://github.com/ @jasoncwarner: https://twitter.com/jasoncwarner GitHub: https://github.com/jasoncwarner Jasoncwarner/ama: https://github.com/jasoncwarner/ama 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 Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring.Corey: This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We've mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Jason Warner, the Chief Technology Officer at GifHub, although he pronounces it differently. Jason, welcome to the show.Jason: Thanks, Corey. Good to be here.Corey: So, GitHub—as you insist on pronouncing it—is one of those companies that's been around for a long time. In fact, I went to a training conducted by one of your early folks, Scott Chacon, who taught how Git works over the course of a couple of days, and honestly, I left more confused than I did when I entered. It's like, “Oh, this is super awful. Good thing I'll never need to know this because I'm not really a developer.” And I'm still not really a developer and I still don't really know how Git works, but here we are.And it's now over a decade later; you folks have been acquired by Microsoft, and you are sort of the one-stop-shop, from the de facto perspective of, “I'm going to go share some code with people on the internet. I'll use GitHub to do it.” Because, you know, copying and pasting and emailing Microsoft Word documents around isn't ideal.Jason: That is right. And I think that a bunch of things that you mentioned there, played into, you know, GitHub's early and sustained success. But my God, do you remember the old days when people had to email tar files around or drop them in weird spots?Corey: What the hell do you mean, by, “Old days?” It still blows my mind that the Linux kernel is managed by—they use Git, obviously. Linus Torvalds did write Git once upon a time—and it has the user interface you would expect for that. And the way that they collaborate is not through GitHub or anything like that. No, they use Git to generate patches, which they then email to the mailing list. Which sounds like I'm making it up, like, “Oh, well, yeah, tell another one, but maybe involve a fax machine this time.” But no, that is actually what they do.Jason: It blew my mind when I saw that, too, by the way. And you realize, too, that workflows are workflows, and people will build interesting workflows to solve their use case. Now, obviously, anyone that you would be talking to in 2021, if you walked in and said, “Yeah, install Git. Let's set up an email server and start mailing patches to each other and we're going to do it this way.” They would just kind of politely—or maybe impolitely—show you out of the room, and rightfully [laugh] so. But it works for one of the most important software projects in history: Linux.Corey: Yeah, and it works almost in spite of itself to some extent. You've come a long way as a company because initially, it was, “Oh, there's this amazing, decentralized version control system. How do we make it better? I know, we're going to take off the decentralized part of it and give it a central point that everything can go through.” And collaboratively, it works well, but I think that viewing GitHub as a system that is used to sell free Git repositories to people is rather dramatically missing the point. It feels like it's grown significantly beyond just code repository hosting. Tell me more about that.Jason: Absolutely. I remember talking to a bunch of folks right around when I was joining GitHub, and you know, there was still talk about GitHub as, you know, GitHub for lawyers, or GitHub for doctors, or what could you do in a different way? And you know, social coding as an aspect, and maybe turning into a social network with a resume. And all those things are true to a percentage standpoint. But what GitHub should be in the world is the world's most important software development platform, end-to-end software development platform.We obviously have grown a bunch since me joining in that way which we launched dependency management packages, Actions with built-in CI, we've got some deployment mechanisms, we got advanced security underneath it, we've Codespaces in beta and alpha on top of it now. But if you think about GitHub as, join, share, and see other people's code, that's evolution one. If you see it as world's largest, maybe most developed software development platform, that's evolution two, and in my mind, its natural place where it should be, given what it has done already in the world, is become the world's most important software company. I don't mean the most profitable. I just mean the most important.Corey: I would agree. I had a blog post that went up somewhat recently about the future of cloud being Microsoft's to lose. And it's not because Azure is the best cloud platform out there, with respect, and I don't need you to argue the point. It is very clearly not. It is not like other clouds, but I can see a path to where it could become far better than it is.But if I'm out there and I'm just learning how to write code—because I make terrible life choices—and I go to a boot camp or I follow a tutorial online or I take a course somewhere, I'm going to be writing code probably using VS Code, the open-source editor that you folks launched after the acquisition. And it was pretty clear that Atom wasn't quite where the world was going. Great. Then I'm going to host it on GitHub, which is a natural evolution. Then you take a look at things like GitHub Actions that build in CI/CD pipelines natively.All that's missing is a ‘Deploy to Azure' button that is the next logical step, and you're mostly there for an awful lot of use cases. But you can't add that button until Azure itself gets better. Done right, this has the potential to leave, effectively, every other cloud provider in the dust because no one can touch this.Jason: One hundred percent. I mean, the obvious thing that any other cloud should be looking at with us—or should have been before the acquisition, looking at us was, “Oh, no, they could jump over us. They could stop our funnel.” And I used internal metrics when I was talking to them about partnership that led to the sale, which was I showed them more about their running business than they knew about themselves. I can tell them where they were stacked-ranked against each other, based on the ingress and egress of all the data on GitHub, you know, and various reactions to that in those meetings was pretty astounding.And just with that data alone, it should tell you what GitHub would be capable of and what Azure would be capable of in the combination of those two things. I mean, you did mention the ‘Deploy to Azure' button; this has been a topic, obviously, pre and post-acquisition, which is, “When is that coming?” And it was the one hard rule I set during the acquisition was, there will be no ‘Deploy to Azure' button. Azure has to earn the right to get things deployed to, in my opinion. And I think that goes to what you're saying is, if we put a ‘Deploy to Azure' button on top of this and Azure is not ready for that, or is going to fail, ultimately, that looks bad for all of us. But if it earned the right and it gets better, and it becomes one of those, then, you know, people will choose it, and that is, to me, what we're after.Corey: You have to choose the moment because if you do it too soon, you'll set the entire initiative back five years. Do it too late, and you get leapfrogged. There's a golden window somewhere and finding it is going to be hard. And I think it's pretty clear that the other hyperscalers in this space are learning, or have learned, that the next 10 years of cloud or 15 years of cloud or whatever they want to call it, and the new customers that are going to come are not the same as the customers that have built the first half of the business. And they're trying to wrap their heads around that because a lot of where the growth is going to come from is established blue chips that are used to thinking in very enterprise terms.And people think I'm making fun of them when I say this, but Microsoft has 40 years' experience apologizing to enterprises for computer failures. And that is fundamentally what cloud is. It's about talking computers to business executives because as much as we talk about builders, that is not the person at an established company with an existing IT estate, who gets to determine where $50 million a year in cloud-spend is going to go.Jason: It's [laugh] very, [laugh] very true. I mean, we've entered a different spot with cloud computing in the bell curve of adoption, and if you think that they will choose the best technology every time, well, history of computing is littered with better technologies that have failed because the distribution was better on one side. As you mentioned, Microsoft has 40 years, and I wager that Microsoft has the best sales organizations and the best enterprise accounts and, you know, all that sort of stuff, blah, blah, blah, on that side of the world than anyone in the industry. They can sell to enterprises better than almost anyone in the industry. And the other hyperscalers—there's a reason why [TK 00:08:34] is running Google Cloud right now. And Amazon, classically, has been very, very bad assigned to the enterprises. They just happened to be the first mover.Corey: In the early days, it was easy. You'd have an Amazon salesperson roll up to a company, and the exec would say, “Great, why should we consider running things on AWS?” And the answer was, “Oh, I'm sorry, wrong conversation. Right now you have 80 different accounts scattered throughout your org. I'm just here to help you unify them, get some visibility into it, and possibly give you a discount along the way.” And it was a different conversation. Shadow IT was the sole driver of cloud adoption for a long time. That is no longer true. It has to go in the front door, and that is a fundamental shift in how you go to market.Jason: One hundred percent true, and it's why I think that Microsoft has been so successful with Azure, in the last, let's call it five years in that, is that the early adopters in the second wave are doing that; they're all enterprise IT, enterprise dev shops who are buying from the top down. Now, there is still the bottoms-up adoption that going to be happening, and obviously, bottom-up adoption will happen still going forward, but we've entered the phase where that's not the primary or sole mechanism I should say. The sole mechanism of buying in. We have tops-down selling still—or now.Corey: When Microsoft announced it was acquiring GitHub, there was a universal reaction of, “Oh, shit.” Because it's Microsoft; of course they're going to ruin GitHub. Is there a second option? No, unless they find a way to ruin it twice. And none of it came to pass.It is uniformly excellent, and there's a strong argument that could be made by folks who are unaware of what happened—I'm one of them, so maybe I'm right, maybe I'm wrong—that GitHub had a positive effect on Microsoft more than Microsoft had an effect on GitHub. I don't know if that's true or not, but I could believe it based upon what I've seen.Jason: Obviously, the skepticism was well deserved at the time of acquisition, let's just be honest with it, particularly given what Microsoft's history had been for about 15—well, 20 years before, previous to Satya joining. And I was one of those people in the late '90s who would write ‘M$' in various forums. I was 18 or 19 years old, and just got into—Corey: Oh, hating Microsoft was my entire personality.Jason: [laugh]. And it was, honestly, well-deserved, right? Like, they had anti-competitive practices and they did some nefarious things. And you know, I talked about Bill Gates as an example. Bill Gates is, I mean, I don't actually know how old he is, but I'm going to guess he's late '50s, early '60s, but he's basically in the redemption phase of his life for his early years.And Microsoft is making up for Ballmer years, and later Gates years, and things of that nature. So, it was well-deserved skepticism, and particularly for a mid-career to older-career crowd who have really grown to hate Microsoft over that time. But what I would say is, obviously, it's different under Satya, and Scott, and Amy Hood, and people like that. And all we really telling people is give us a chance on this one. And I mean, all of us. The people who were running GitHub at the time, including myself and, you know, let Scott and Satya prove that they are who they say they are.Corey: It's one of those things where there's nothing you could have said that would have changed the opinion of the world. It was, just wait and see. And I think we have. It's now, I daresay, gotten to a point where Microsoft announces that they're acquiring some other beloved company, then people, I think, would extend a lot more credit than they did back then.Jason: I have to give Microsoft a ton of credit, too, on this one for the way in which they handled acquisitions, like us and others. And the reason why I think it's been so successful is also the reason why I think so many others die post-acquisition, which is that Microsoft has basically—I'll say this, and I know I won't get fired because it feels like it's true. Microsoft is essentially a PE holding company at this point. It is acquired a whole bunch of companies and lets them run independent. You know, we got LinkedIn, you got Minecraft, Xbox is its own division, but it's effectively its own company inside of it.Azure is run that way. GitHub's got a CEO still. I call it the archipelago model. Microsoft's the landmass underneath the water that binds them all, and finance, and HR, and a couple of other things, but for the most part, we manifest our own product roadmap still. We're not told what to go do. And I think that's why it's successful. If we're going to functionally integrate GitHub into Microsoft, it would have died very quickly.Corey: You clearly don't mix the streams. I mean, your gaming division writes a lot of interesting games and a lot of interesting gaming platforms. And, like, one of the most popularly played puzzle games in the world is a Microsoft property, and that is, of course, logging into a Microsoft account correctly. And I keep waiting for that to bleed into GitHub, but it doesn't. GitHub is a terrific SAML provider, it is stupidly easy to log in, it's great.And at some level, I wish that would bleed into other aspects, but you can't have everything. Tell me what it's like to go through an acquisition from a C-level position. Because having been through an acquisition before, the process looks a lot like a surprise all-hands meeting one day after the markets close and, “Listen up, idiots.” And [laugh] there we go. I have to imagine with someone in your position, it's a slightly different experience.Jason: It's definitely very different for all C-levels. And then myself in particular, as the primary driver of the acquisition, obviously, I had very privy inside knowledge. And so, from my position, I knew what was happening the entire time as the primary driver from the inside. But even so, it's still disconcerting to a degree because, in many ways, you don't think you're going to be able to pull it off. Like, you know, I remember the months, and the nights, and the weekends, and the weekend nights, and all the weeks I spent on the road trying to get all the puzzle pieces lined up for the Googles, or the Microsofts, or the eventually AWSs, the VMwares, the IBMs of the world to take seriously, just from a product perspective, which I knew would lead to, obviously, acquisition conversations.And then, once you get the call from the board that says, “It's done. We signed the letter of intent,” you basically are like, “Oh. Oh, crap. Okay, hang on a second. I actually didn't—I don't actually believe in my heart of hearts that I was going to actually be able to pull that off.” And so now, you probably didn't plan out—or at least I didn't. I was like, “Shit if we actually pulled this off what comes next?” And I didn't have that what comes next, which is odd for me. I usually have some sort of a loose plan in place. I just didn't. I wasn't really ready for that.Corey: It's got to be a weird discussion, too, when you start looking at shopping a company around to be sold, especially one at the scale of GitHub because you're at such a high level of visibility in the entire environment, where—it's the idea of would anyone even want to buy us? And then, duh, of course they would. And you look the hyperscalers, for example. You have, well, you could sell it to Amazon and they could pull another Cloud9, where they shove it behind the IAM login process, fail to update the thing meaningfully over a period of years, to a point where even now, a significant portion of the audience listening to this is going to wonder if it's a service I just made up; it sounds like something they might have done, but Cloud9 sounds way too inspired for an AWS service name, so maybe not. And—which it is real. You could go sell to Google, which is going to be awesome until some executive changes roles, and then it's going to be deprecated in short order.Or then there's Microsoft, which is the wild card. It's, well, it's Microsoft. I mean, people aren't really excited about it, but okay. And I don't think that's true anymore at all. And maybe I'm not being fair to all the hyperscalers there. I mean, I'm basically insulting everyone, which is kind of my shtick, but it really does seem that Microsoft was far and away the best acquirer possible because it has been transformative. My question—if you can answer it—is, how the hell did you see that beforehand? It's only obvious—even knowing what I know now—in hindsight.Jason: So, Microsoft was a target for me going into it, and the reason why was I thought that they were in the best overall position. There was enough humility on one side, enough hubris on another, enough market awareness, probably, organizational awareness to, kind of, pull it off. There's too much hubris on one side of the fence with some of the other acquirers, and they would try to hug us too deeply, or integrate us too quickly, or things of that nature. And I think it just takes a deep understanding of who the players are and who the egos involved are. And I think egos has actually played more into acquisitions than people will ever admit.What I saw was, based on the initial partnership conversations, we were developing something that we never launched before GitHub Actions called GitHub Launch. The primary reason we were building that was GitHub launches a five, six-year journey, and it's got many, many different phases, which will keep launching over the next couple of years. The first one we never brought to market was a partnership between all of the clouds. And it served a specific purpose. One, it allowed me to get into the room with the highest level executive at every one of those companies.Two allow me to have a deep economic conversation with them at a partnership level. And three, it allowed me to show those executives that we knew what GitHub's value was in the world, and really flip the tables around and say, “We know what we're worth. We know what our value is in the world. We know where we sit from a product influence perspective. If you want to be part of this, we'll allow it.” Not, “Please come work with us.” It was more of a, “We'll allow you to be part of this conversation.”And I wanted to see how people reacted to that. You know how Amazon reacted that told me a lot about how they view the world, and how Google reacted to that showed me exactly where they viewed it. And I remember walking out of the Google conversation, feeling a very specific way based upon the reaction. And you know, when I talked to Microsoft, got a very different feel and it, kind of, confirmed a couple of things. And then when I had my very first conversation with Nat, who have known for a while before that, I realized, like, yep, okay, this is the one. Drive hard at this.Corey: If you could do it all again, would you change anything meaningful about how you approached it?Jason: You know, I think I got very lucky doing a couple of things. I was very intentional aspects of—you know, I tried to serendipitously show up, where Diane Greene was at one point, or a serendipitously show up where Satya or Scott Guthrie was, and obviously, that was all intentional. But I never sold a company like this before. The partnership and the product that we were building was obviously very intentional. I think if I were to go through the sale, again, I would probably have tried to orchestrate at least one more year independent.And it's not—for no other reason alone than what we were building was very special. And the world sees it now, but I wish that the people who built it inside GitHub got full credit for it. And I think that part of that credit gets diffused to saying, “Microsoft fixed GitHub,” and I want the people inside GitHub to have gotten a lot more of that credit. Microsoft obviously made us much better, but that was not specific to Microsoft because we're run independent; it was bringing Nat in and helping us that got a lot of that stuff done. Nat did a great job at those things. But a lot of that was already in play with some incredible engineers, product people, and in particular our sales team and finance team inside of GitHub already.Corey: When you take a look across the landscape of the fact that GitHub has become for a certain subset of relatively sad types of which I'm definitely one a household name, what do you think the biggest misconception about the company is?Jason: I still think the biggest misconception of us is that we're a code host. Every time I talk to the RedMonk folks, they get what we're building and what we're trying to be in the world, but people still think of us as SourceForge-plus-plus in many ways. And obviously, that may have been our past, but that's definitely not where we are now and, for certain, obviously, not our future. So, I think that's one. I do think that people still, to this day, think of GitLab as one of our main competitors, and I never have ever saw GitLab as a competitor.I think it just has an unfortunate naming convention, as well as, you know, PRs, and MRs, and Git and all that sort of stuff. But we take very different views of the world in how we're approaching things. And then maybe the last thing would be that what we're doing at the scale that we're doing it as is kind of easy. When I think that—you know, when you're serving almost every developer in the world at this point at the scale at which we're doing it, we've got some scale issues that people just probably will never thankfully encounter for themselves.Corey: Well, everyone on Hacker News believes that they will, as soon as they put up their hello world blog, so Kubernetes is the only way to do anything now. So, I'm told.Jason: It's quite interesting because I think that everything breaks at scale, as we all know about from the [hyperclouds 00:20:54]. As we've learned, things are breaking every day. And I think that when you get advice, either operational, technical, or managerial advice from people who are running 10 person, 50 person companies, or X-size sophisticated systems, it doesn't apply. But for whatever reason, I don't know why, but people feel inclined to give that feedback to engineers at GitHub directly, saying, “If you just…” and in many [laugh] ways, you're just like, “Well, I think that we'll have that conversation at some point, you know, but we got a 100-plus-million repos and 65 million developers using us on a daily basis.” It's a very different world.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: One of the things that I really appreciate personally because, you know, when you see something that company does, it's nice to just thank people from time to time, so I'm inviting the entire company on the podcast one by one, at some point, to wind up thanking them all individually for it, but Codespaces is one of those things that I think is transformative for me. Back in the before times, and ideally the after times, whenever I travel the only computer I brought with me for a few years now has been an iPad or an iPad Pro. And trying to get an editor on that thing that works reasonably well has been like pulling teeth, my default answer has just been to remote into an EC2 instance and use vim like I have for the last 20 years. But Code is really winning me over. Having to play with code-server and other things like that for a while was obnoxious, fraught, and difficult.And finally, we got to a point where Codespaces was launched, and oh, it works on an iPad. This is actually really slick. I like this. And it was the thing that I was looking for but was trying to have to monkey patch together myself from components. And that's transformative.It feels like we're going back in many ways—at least in my model—to the days of thin clients where all the heavy lifting was done centrally on big computers, and the things that sat on people's desks were mostly just, effectively, relatively simple keyboard, mouse, screen. Things go back and forth and I'm sure we'll have super powerful things in our pockets again soon, but I like the interaction model; it solves for an awful lot of problems and that's one of the things that, at least from my perspective, that the world may not have fully wrapped it head around yet.Jason: Great observation. Before the acquisition, we were experimenting with a couple of different editors, that we wanted to do online editors. And same thing; we were experimenting with some Action CI stuff, and it just didn't make sense for us to build it; it would have been too hard, there have been too many moving parts, and then post-acquisition, we really love what the VS Code team was building over there, and you could see it; it was just going to work. And we had this one person, well, not one person. There was a bunch of people inside of GitHub that do this, but this one person at the highest level who's just obsessed with make this work on my iPad.He's the head of product design, his name's Max, he's an ex-Heroku person as well, and he was just obsessed with it. And he said, “If it works on my iPad, it's got a chance to succeed. If it doesn't work on my iPad, I'm never going to use this thing.” And the first time we booted up Codespaces—or he booted it up on the weekend, working on it. Came back and just, “Yep. This is going to be the one. Now, we got to work on those, the sanding the stones and those fine edges and stuff.”But it really does unlock a lot for us because, you know, again, we want to become the software developer platform for everyone in the world, you got to go end-to-end, and you got to have an opinion on certain things, and you got to enable certain functionality. You mentioned Cloud9 before with Amazon. It was one of the most confounding acquisitions I've ever seen. When they bought it I was at Heroku and I thought, I thought at that moment that Amazon was going to own the next 50 years of development because I thought they saw the same thing a lot of us at Heroku saw, and with the Cloud9 acquisition, what they were going to do was just going to stomp on all of us in the space. And then when it didn't happen, we just thought maybe, you know, okay, maybe something else changed. Maybe we were wrong about that assumption, too. But I think that we're on to it still. I think that it just has to do with the way you approach it and, you know, how you design it.Corey: Sorry, you just said something that took me aback for a second. Wait, you mean software can be designed? It's not this emergent property of people building thing on top of thing? There's actually a grand plan behind all these things? I've only half kidding, on some level, where if you take a look at any modern software product that is deployed into the world, it seems impossible for even small aspects of it to have been part of the initial founding design. But as a counterargument, it would almost have to be for a lot of these things. How do you square that circle?Jason: I think you have to, just like anything on spectrums and timelines, you have to flex at various times for various things. So, if you think about it from a very, very simple construct of time, you just have to think of time horizons. So, I have an opinion about what GitHub should look like in 10 years—vaguely—in five years much more firmly, and then very, very concretely, for the next year, as an example. So, a lot of the features you might see might be more emergent, but a lot of long-term work togetherness has to be loosely tied together with some string. Now, that string will be tightened over time, but it loosely has to see its way through.And the way I describe this to folks is that you don't wake up one day and say, “I'm going on vacation,” and literally just throw a finger on the map. You have to have some sort of vague idea, like, “Hey, I want to have a beach vacation,” or, “I want to have an adventure vacation.” And then you can kind of pick a destination and say, “I'm going to Hawaii,” or, “I'm going to San Diego.” And if you're standing on the East Coast knowing you're going to San Diego, you basically know that you have to just start marching west, or driving west, or whatever. And now, you don't have to have the route mapped out just yet, but you know that hey, if I'm going due southeast, I'm off course, so how do I reorient to make sure I'm still going in the right direction?That's basically what I think about as high-level, as scale design. And it's not unfair to say that a lot of the stuff is not designed today. Amazon is very famous for not designing anything; they design a singular service. But there's no cohesiveness to what Amazon—or AWS specifically, I should say, in this case—has put out there. And maybe that's not what their strategy is. I don't know the internal workings of them, but it's very clear.Corey: Well, oh, yeah. When I first started working in the AWS space and looking through the console, it like, “What is this? It feels like every service's interface was designed by a different team, but that would—oh…” and then the light bulb went on. Yeah. You ship your culture.Jason: It's exactly it. It works for them, but I think if you're going to try to do something very, very, very different, you know, it's going to look a certain way. So, intentional design, I think, is part of what makes GitHub and other products like it special. And if you think about it, you have to have an end-to-end view, and then you can build verticals up and down inside of that. But it has to work on the horizontal, still.And then if you hire really smart people to build the verticals, you get those done. So, a good example of this is that I have a very strong opinion about the horizontal workflow nature of GitHub should look like in five years. I have a very loose opinion about what the matrix build system of Actions looks like. Because we have very, very smart people who are working on that specific problem, so long as that maps back and snaps into the horizontal workflows. And that's how it can work together.Corey: So, when you look at someone who is, I don't know, the CTO of a wildly renowned company that is basically still catering primarily to developers slash engineers, but let's be honest, geeks, it's natural to think that, oh, they must be the alpha geek. That doesn't really apply to you from everything I've been able to uncover. Am I just not digging deeply enough, or are you in fact, a terrible nerd?Jason: [laugh]. I am. I'm a terrible nerd. I am a very terrible nerd. I feel very lucky, obviously, to be in the position I'm in right now, in many ways, and people call me up and exactly that.It's like, “Hey, you must be king of the geeks.” And I'm like, “[laugh], ah, funny story here.” But um, you know, I joke that I'm not actually supposed to be in tech in first place, the way I grew up, and where I did, and how, I wasn't supposed to be here. And so, it's serendipitous that I am in tech. And then turns out I had an aptitude for distributed systems, and complex, you know, human systems as well. But when people dig in and they start talking about topics, I'm confounded. I never liked Star Wars, I never like Star Trek. Never got an anime, board games, I don't play video games—Corey: You are going to get letters.Jason: [laugh]. When I was at Canonical, oh, my goodness, the stuff I tried to hide about myself, and, like, learn, like, so who's this Boba Fett dude. And, you know, at some point, obviously, you don't have to pretend anymore, but you know, people still assume a bunch stuff because, quote, “Nerd” quote, “Geek” culture type of stuff. But you know, some interesting facts that people end up being surprised by with me is that, you know, I was very short in high school and I grew in college, so I decided that I wanted to take advantage of my newfound height and athleticism as you grow into your body. So, I started playing basketball, but I obsessed over it.I love getting good at something. So, I'd wake up at four o'clock in the morning, and go shoot baskets, and do drills for hours. Well, I got really good at it one point, and I end up playing in a Pro-Am basketball game with ex-NBA Harlem Globetrotter legends. And that's just not something you hear about in most engineering circles. You might expect that out of a salesperson or a marketing person who played pro ball—or amateur ball somewhere, or college ball or something like that. But not someone who ends up running the most important software company—from a technical perspective—in the world.Corey: It's weird. People counterintuitively think that, on some level, that code is the answer to all things. And that, oh, all this human interaction stuff, all the discussions, all the systems thinking, you have to fit a certain profile to do that, and anyone outside of that is, eh, they're not as valuable. They can get ignored. And we see that manifesting itself in different ways.And even if we take a look at people whose profess otherwise, we take a look at folks who are fresh out of a boot camp and don't understand much about the business world yet; they have transformed their lives—maybe they're fresh out of college, maybe didn't even go to college—and 18 weeks later, they are signing up for six-figure jobs. Meanwhile, you take a look at virtually any other business function, in order to have a relatively comparable degree of earning potential, it takes years of experience and being very focused on a whole bunch of other things. There's a massive distortion around technical roles, and that's a strange and difficult thing to wrap my head around. But as you're talking about it, it goes both ways, too. It's the idea of, “Oh, I'll become technical than branch into other things.” It sounded like you started off instead with a non-technical direction and then sort of adopted that from other sides. Is that right, or am I misremembering exactly how the story unfolds?Jason: No, that's about right. People say, “Hey, when did I start programming?” And it's very in vogue, I think, for a lot of people to say, “I started programming at three years old,” or five years old, or whatever, and got my first computer. I literally didn't get my first computer until I was 18-years-old. And I started programming when I got to a high school co-op with IBM at 17.It was Lotus Notes programming at the time. Had no exposure to it before. What I did, though, in college was IBM told me at the time, they said, “If you get a computer science degree will guarantee you a job.” Which for a kid who grew up the way I grew up, that is manna from heaven type of deal. Like, “You'll guarantee me a job inside where don't have to dig ditches all day or lay asphalt? Oh, my goodness. What's computer science? I'll go figure it out.”And when I got to school, what I realized was I was really far behind. Everyone was that ubergeek type of thing. So, what I did is I tried to hack the system, and what I said was, “What is a topic that nobody else has an advantage on from me?” And so I basically picked the internet because the internet was so new in the mid-'90s that most people were still not fully up to speed on it. And then the underpinnings in the internet, which basically become distributed systems, that's where I started to focus.And because no one had a real advantage, I just, you know, could catch up pretty quickly. But once I got into computers, it turned out that I was probably a very average developer, maybe even below average, but it was the system's thinking that I stood out on. And you know, large-scale distributed systems or architectures were very good for me. And then, you know, that applies not, like, directly, but it applies decently well to human systems. It's just, you know, different types of inputs and outputs. But if you think about organizations at scale, they're barely just really, really, really complex and kind of irrational distributed systems.Corey: Jason, thank you so much for taking the time to speak with me today. If people want to learn more about who you are, what you're up to, how you think about the world, where can they find you?Jason: Twitter's probably the best place at this point. Just @jasoncwarner on Twitter. I'm very unimaginative. My name is my GitHub handle. It's my Twitter username. And that's the best place that I, kind of, interact with folks these days. I do an AMA on GitHub. So, if you ever want to ask me anything, just kind of go to jasoncwarner/ama on GitHub and drop a question in one of the issues and I'll get to answering that. Yeah, those are the best spots.Corey: And we will, of course, include links to those things in the [show notes 00:33:52]. Thank you so much for taking the time to speak with me today. I really appreciate it.Jason: Thanks, Corey. It's been fun.Corey: Jason Warner, Chief Technology Officer at GitHub. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review in your podcast platform of choice anyway, along with a comment that includes a patch.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.

In der heutigen Folge 99 reden wir mal wieder über GitHub. Die machen aber auch wieder Sachen. Zum einen sind endlich die von uns schon viel früher erwarteten Codespaces, also GitHubs Online IDE für (fast) alle verfügbar. Zum anderen ist da GitHub Copilot. Ein AI-befeuerter Coding-Assistent. Klingt erstmal hammermäßig! Die ersten Einblicke sehen gut aus? Oder doch nicht? Und steckt der Teufel da im Detail? Ist das das nächste große Ding? Was denkt ihr? Wir freuen uns auf eure Kommentare!

Steph talks about a new GitHub feature and Twitter account (@RubyCards (https://twitter.com/RubyCards)) she's really excited about and Chris talks about his new job as a CTO of a startup and shifting away from writing code regularly. GitHub (https://docs.github.com/en/codespaces/developing-in-codespaces/web-based-editor) RubyCards (https://twitter.com/RubyCards) Resilient Management (https://resilient-management.com/) The Manager's Path (https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897) Transcript: CHRIS: Oh God, my computer is so stupid slow. I need a new computer. STEPH: Come on, little computer, you can do it. You know you could just buy a new one. You don't have to wait for the fancy-schmancy M1. CHRIS: I want to wait for the fancy. I want it so bad. STEPH: [laughs] CHRIS: Do you know how long I've had this computer? And if I can hold out one more month, I want the fancy stuff. I've waited this long. Why would I give in now when I'm right on the cusp of victory? STEPH: One more month. I'm going to send you...as a kid, did you ever make those construction… CHRIS: Oh yeah. STEPH: They look like chain links bow construction paper. So we would make those for a countdown to special days. I'm going to send you one that's all crumpled and folded in the mail. It would be delightful. And you'll be able to snip off a little chain each day as your countdown to your new fancy-schmancy. [laughs] CHRIS: I love it. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey. Well, I just got back from vacation. So getting back to work is what's new in my world. And vacation is nice. I miss it already. But it's also nice to be back, and see everybody, and see what they've been up to. CHRIS: I've heard wonderful things about vacation. STEPH: Yeah. Have you had one recently? I know you've been quite busy. CHRIS: I have. I think it's hard to tell, especially because everything just kind of blends together these days. But I think I took off a few days recently. I haven't had an extended vacation since much earlier on in the summer, I think. And so I think I'm due for one of those sometime in the not too distant future. But it's one of those things where you got to plan it. And you got to think ahead, and I haven't been doing that of late really with anything. So kind of living for the moment, but that's not how you take a vacation. So I got to rethink some strategies here. [chuckles] STEPH: Yeah, I've been trying to schedule more vacation time just further out. Because then if I don't want to take it, like if I decide that I don't want the staycation or I don't need the day off, then I can just change my mind, and that's pretty easy to do. But I'm like you; if I don't plan it, then I don't feel like I have the energy to plan a vacation, and then it just doesn't happen. So I know that's one thing that I've been doing. I've also been mentoring or coaching others, just checking in with them to say, "Hey, when's your next vacation? Have you scheduled any days off? Do you want to schedule a day off next month?" And saying that to other people has also been a very helpful reminder to me to do so. CHRIS: Oh, I like that a lot as a recurring one-on-one question of, so what can you tell me about vacation? What do you got in the works there? Because that's the most important thing, [chuckles] which it kind of is. It's the way that we keep doing the work that we do. STEPH: And I think so many people just haven't been taking a vacation. I mean, in 2020, we were all locked in and going through a pandemic, so then a lot of people weren't taking those breaks. And so part of it is just reminding people that even if you can't go somewhere, still please take some downtime and just know that you can step away from work and should step away from work. But for us, we did go somewhere. So we went out to Seattle, which I've never...I've been out to the West Coast, but it's more like I've been out to L.A., Santa Monica. But this time, we went to the Northwest region. We went to Seattle, and we explored and did a lot of hiking and camping around the Northern Cascades and then Mount Rainier. And both of those are amazing. And I've never flown with camping gear, but that went really well. It worked out nice. We had an Airbnb every so often just for showers and having a roof over your head. That's really nice. But for most of the trip, we did a lot of camping and hiking. CHRIS: That sounds like an awesome trip. STEPH: Yeah, it was really cool. I'd love to go back to the Olympic National Park because there are just so many national parks that are around Seattle and in Washington that we couldn't begin to do it all. But Olympic National Park is still on my list. And I'm really grateful to have also seen the Northern Cascades and Mount Rainier. But switching gears a bit, I have something that I'm really excited to share with you because I don't think you've seen it yet. I'm excited to find out if you have. But it's a new GitHub feature that came out, I think about a month ago, but there doesn't seem to have been much fanfare from GitHub about announcing this new feature. And I happened to find out through Twitter because someone else found it, and then they were really excited. And so now I think it's really gaining some more traction. But it still seems like one of those sneaky feature releases, but it's really cool. So GitHub has added the ability to open up a web-based editor that allows you to view the source code for a repo, view it in syntax, highlighting, make a code change, and commit the change. And it's free for everybody. And there's a couple of ways to get there, but I'll pause there. Have you seen this yet? Have you interacted with it? CHRIS: I think I've seen it and poked around ever so gently with it. I want to say this is GitHub Codespaces. Is that the name of this feature? STEPH: Yep. That's it? CHRIS: Yes. I poked around with it just a tiny bit, and I'm very excited about it. But it's very much in the like, huh, okay, cool; I'll look at that someday down the road and figure out what I want to do with it. But have you actually dug into it particularly deeply? STEPH: I used it to make a change for a personal project, just because I wanted to see the whole flow. So I went to a personal project, and there are two ways that you can open it up for anyone that hasn't seen this yet. So you can either press the period button that's on your keyboard, and that will open it up, or you can just alter the URL. So instead of github.com, replace that .com with .dev, and then that will also open up the browser. And so I made a change to a personal project, and it worked really well, and it commits the change to main. And it was nice. It was easy. In my case, I was just making a change to make a change. I think I actually went to an older project where I was still using the underscore target to force users that when they clicked on a link that it opened a new tab, and I was like, perfect. This is a good thing to just change. And I could do it from my iPad. I didn't have to be at my computer. And it was really nifty. I was very impressed with it. And they also mentioned that it's very easy to integrate your own VS Code settings and environment. I'm not a heavy VS Code user, so I haven't tried that. But I've heard really positive things about how easy it is to sync your settings between your local VS Code and then GitHub's editor. But overall, it was really easy to use. CHRIS: That's super cool. My very limited understanding of it is like GitHub has had the ability to edit files and things like that for a while. But it was very much like a simple web editor where it's a big text box that happens to contain the code. And they've added some stuff for like browsing with syntax highlighting and even some context-aware show usage and things like that. But as far as I understand it, this is like a whole VS Code instance in the cloud that is running it. And then I think what you're saying about you can have your VS Code settings in there, but even your project settings and the ability to run the tests, I'm not sure where the edges of it are. But my understanding with Codespaces it's like this is how your team can develop. Everyone gets one of these Codespaces. You're developing in the cloud. But it does VS Code remote sync type stuff. I'm very intrigued to see where it goes and that idea of...obviously, I like Vim. That's the thing that's probably known and true about me. So I will probably be one of the later adopters of this. But the idea of being able to bottle up the development environment for your projects and have those settings, and the ability to run the test and all of that packaged up as part of the repository, and then allow people to run with that, especially in the cloud, and be able to carry that with them as they move around, that's really intriguing. And the idea of having this very easy on-ramp, especially for open-source projects and things like that. If you want people to be able to contribute easily but with the linting, and the configuration, and the settings, and all the stuff, well, now you can have that packaged up. And that is very interesting to me. So I'm super intrigued to see where it goes. Again, I will probably be one of the later adopters of this platform for reasons. But I am super interested, and I continue to like...the work with VS Code is so interesting in the way it keeps expanding out and the language server stuff and now the Codespaces stuff. And it's super interesting developments across the board. STEPH: Yeah, I'm with you. I don't actually see this replacing my current development that I do day-to-day, but it's more generally nice to have access. So if I needed to make a change and I don't have my laptop or if it's just something small and I don't want to have to go through…I guess essentially, if I don't have my laptop, but I wanted to make a change, then I could do this realistically from something that doesn't have my full local dev setup. I don't know if you have the ability to run tests. I didn't explore that far as to whether you can actually have access to run those types of commands or processes. I did see some additional notes while reading through GitHub's documentation about this new editor. And they included some notes that talk about how the editor runs entirely in your browser's sandbox. So it doesn't actually clone the repo, but instead, it loads your code by invoking the services API directly from the browser. So then your work is saved in the browser's local storage until you commit it, and then you can persist your changes by then committing it back to the repo. And because there's no associated compute, you won't be able to build and run your code or use the integrated terminal. Ah, I think that actually answers the question about running tests. So only a subset of extensions can run in the web will appear in the extensions panel and can be installed. So this does impose certain limitations for particular programming languages and full functionality, things that we may need like running tests. CHRIS: Interesting. That now puts it back more on the uncanny valley for me where it's like, oh, it's just VS Code, except it can't do a bunch of the stuff. So yeah, I'll probably be hanging out in Vim for a while. But again, I'm super interested to see where they can push this and what the browser platform allows, and then how they're able to leverage that and so on and so forth. STEPH: There is one flow that I was testing out because I was reading someone else mentioned that not only can you use this for looking at source code and then changing that source code but also for a pull request. And so I went to a pull request and changed the URL to dev. And I do have the ability to make changes, but I'm not quite sure if I could commit my changes and if that would go to the branch or how that would work. It wasn't obvious to me how I could save my changes. But it was obvious to me that I could make changes. [laughs] So that part feels weird to me, and I will have to test that out. But I'm going to wait until I have my own PR before I start fooling around [laughs] so I don't ruin somebody else's PR. CHRIS: Ideally, the worst case is you just push commit to a branch, and commits are reversible. You can throw them away. You can reset, and you can do all sorts of stuff. But I agree with you that maybe I'll do this on my home turf first before I start messing around with somebody's PR. STEPH: That way, someone doesn't reach out to me and say, "Steph, what is this commit that I have on my PR?" And I'm like, "Oh, I'm just testing." [laughs] But that's something that I was excited to talk about and share with you. What's new in your world? CHRIS: Well, what's new in my world? I think we've talked about this a little bit, but to give a little bit of context on what's new in my world, I joined a startup. I am now engineer number one. I'm also CTO, a very fancy title, but again, I'm the team of one, so count it as you will. But we do have some consultants working with us. So there is a small team that I am managing, and very quickly, I found myself shifting away from the code or having to balance that trade-off of maker versus manager time. Like, how much of the time am I actually coding and shipping features versus managing and communicating, and trying to figure out the work to be done and triaging the backlog? And all of those sorts of things. I've also just been coding less, and I think that's a trend that will almost certainly continue, and I'm intrigued by that. And that's a thing that I want to poke at just a little bit. And then I've also noticed that my work has become much more reactive than it used to be, where there are lots of things in Slack. And there's stuff that I'm kind of the only person that can do certain things because I have certain access levels and yadda yadda. And I want to make sure other folks aren't blocked. So I'm trying to be as responsive as possible in those moments. But I'm also struggling with that that trade-off between reactive versus proactive. My ideal version I think of the work is gather all of the information, all of the different permutations, and what are all the features we want? And then I think about them holistically, and then I respond once solidly as opposed to little one-off interactions and things like that. So there are just a lot of subtle differences. And I think there are trends that will continue. And so I'm trying to just take a step back, observe them from a distance and say, "How do I feel about these?" But probably most interesting to me is the moving away from code. Have you noticed that at all in your work? Or is that something you've thought about, something you'd be interested in, opposed to? How do you feel about that space in the coding world? STEPH: That is a wonderful question. It's one that I have wrestled with for a while because I really love my current position. I love being a team lead because I feel like there's this wonderful balance between where I get to code a lot of the time, but then I also get to learn how to be a manager, and help those around me, and provide some coaching or mentoring or just help people find the resources that they need essentially. And I really like that balance. That feels like the right balance to me, where I still get to grow in both areas. But then, as you'd mentioned, it still feels like one tries to take over the other with time. Like you find that more responsibilities are growing as CTO of the company. And so you feel more responsible to do more of the managerial task or unblocking others and taking on that role, and then that reduces your time for coding. And I often find myself in that space where I think it's just how I'm wired. I'm very interested and empathetic towards how people are doing and how they're feeling. So I'm always looking for ways to support others and to help unblock them and make sure that they're having a very positive experience with our project. And so then that may mean I'm coding less because then I'm more focused on that. But then, it's still also a very valid part of my job to code. So finding the right balance between those is frankly hard. To answer your other question, I don't think I want to give that up. I've considered for myself if I'm going to head towards more of a manager path, and I'm going to reserve the right to change my mind. But currently, I still like maintaining most of my individual contributor status with a dash of management sprinkled in there and then some responsibilities for making sure that the team is doing well and that people are enjoying their work. Along that line, as I've been having conversations with others around, tell me more about your job as a manager, and what does that look like? What responsibilities do you have? How much coding do you still get to do? There have been a couple of books that have been recommended to me that really help someone define are you interested in management? Is that a place that you see yourself going? This is really an honest look at what it means to be a manager. The fact that a lot of your fulfilling work isn't necessarily work that you get to produce, but it's actually helping someone else produce that work and then getting to see them succeed. That is your new fulfillment or a big part of it. So you are losing that closeness of being a maker,, but instead, you are empowering someone else to be the maker, and then that becomes your win. And that becomes an indication of your success. Versus as an individual contributor, it's really easy to see our wins in a different light: how many tickets have we addressed? How many PRs have we reviewed? That type of work. So there is an interesting dichotomy there, and I can't remember the books off the top of my head, but I will find them and I'll add a link to them in the show notes. CHRIS: Yeah, definitely interested to see the book recommendations. And generally, yeah, everything you're saying makes sense to me. I think I'm somewhat on the adventure right now. I very much intentionally chose this, and I want to lean into it and explore this facet of the work and doing more of the management and leading a team. But I have to accept that that comes with letting go of some of the individual contributor parts. And I was coding a bit over the weekend. I was just rediscovering the flow of that. And I was like, oh yeah, I really like this. Huh, that's interesting. What am I going to do with that? But I think, again, it's an exploration. And there are facets of both sides that I really like. And I've spent a lot of time deeper in the individual contributor side. And I've explored the manager side somewhat but not quite as much. And so this is very much about that I want to push on those edges and try and find what feels true to me. So the moving away from code and then moving more into management, I think I like that overall. Although I know there's the small amount in the back of my head that I'm like, I know there's a cost there. That is a trade-off. And so do I find more time in my evenings and weekends to do personal coding projects and things like that just to have that enjoyable work for myself? The maker versus manager stuff is interesting, though, where my day is now split up into smaller pieces. And even if I'm not coding, there's still writing up docs, or there are things that still require structured blocks of time. And my day is now just sprinkled with other things. And so trying to find that heads down of I want to just do the work right now, and I want to think hard about something is just fundamentally harder to do with more meetings and things speckled throughout the day. So that's one that I think I just don't like overall. But it's sort of a trade-off inherent to the situation. So I think there's also a version of trying to be intentional about that and saying, you know what? I need some heads-down time. And so Tuesday and Thursday afternoons those are going to be mine. I'm going to wall those off on my calendar and try and protect that time so that whatever necessary heads-down work that I need to do this week fits into those blocks of time and then fit the rest of things around that. But I think I have to make that intentional choice to do that. Mid-roll Ad And now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. STEPH: Your mention of having more meetings really resonates with me. And it also made me think of a recent episode of a new TV show I just started watching. Have you seen the TV show called Schmigadoon!? CHRIS: I have indeed. STEPH: Okay. We need to have a whole conversation about Schmigadoon! in an upcoming episode. I'm very excited about this show. It's delightful. [laughs] There's a particular line that Keegan-Michael Key says that I just love so much where he says that he became a surgeon because he wanted to help people without talking to people. And I was like, oh, that's a developer. [laughs] I'm the same way. And I really enjoyed that. Although I do like talking to people but still, it just made me think about when you're talking about more meetings and then increasing the amount of talking that needs to be done as you progress into more of a management role. Also, circling back, I really like what you said earlier about you're noticing the changes that are happening. You're letting those changes happen, and then you're reflecting on how you feel about it. I really like that approach. Do you think that's working well for you? Does it feel too loose because then you don't feel in control enough of those changes? Or do you actually feel like that's a really good way to explore a new role and then find out if you like those changes? CHRIS: Now that you are restating it back to me, I'm like, oh yeah, I guess that is a good way to do things. But to clarify, I'm not doing nothing with it. I am trying to proactively, where I can, structure my days and do things like that or recognize that right now, I'm probably not the right person to be moving code along. And so I'm saying okay, that is true. And I'm actively choosing to not pick up the bigger pieces of work or to pair with someone else so that they can then run with it but not having me being the person that owns it. So it's not completely letting it happen, but it is almost like meditation to invoke that idea of I'm observing that I'm having these thoughts, and I'm just going to let them go. And it's more about the thinking and the response to it. So I'm trying to name the thing and be like, oh, this is interesting that this is happening. And I'm noticing an immediate visceral reaction to it where it's like, you're taking away my coding? And I'm like, well, hey, it's not them, it's you; you chose to do this. But let's just spend a minute there. That's okay. How do we feel about this? And so it's trying to not have it be a purely reactive response to it but have it be a more intentional, more thoughtful, and more observing, and then giving it a little bit of time to ruminate and then see a little bit more what I think. And also, some of it is purposefully pushing myself out of my comfort zone. I think I'm happy, and I do a reasonable job when I'm the person moving the code along. But I also have really enjoyed being at the edge of an engineering team and working with sales or working with other groups and facilitating the work that's happening. And so, if I explore that a little bit more, what's that going to look like for me? So this period of my career, I'm very intentionally trying to do stuff that I'm like, well, this is a little bit different for me, or this is stretching a little bit, but that is the goal. And I hope good things will come out of it across the board. But it may be that I find like, you know what? Actually, I really miss coding, and I need to find a way to restructure that. And I have seen examples of individuals who are even in CEO positions that are like, no, no, no, I still make some time to code. Like Amir, the founder of Todoist talks regularly about the fact that he is a CEO who still codes. And that organization has a very particular approach to work. And they're very much about async remote, et cetera. So having these blocks of times and being intentional about how they work. So it's not surprising that he's been able to do that and a purposeful thing that he's structured. I don't think that will make sense for me immediately. But I could see a version down the road where I'm like, this is who I am. I need to get this thing back. But for now, I'm purposefully letting it happen and seeing how I feel from there. Also, as I'm saying all of this, it sounds like I'm totally on top of this and really thinking it through. I'm like, no, no, no, this is in the moment. I'm noticing some stuff and being like, oh, okay, well, that's interesting. And some of it I intentionally chose. Again, intentionally chose to get out of my comfort zone. So I think I'm just actively out of my comfort zone right now and saying things about it. And then I think I'm telling the story of how I want to respond to it moving forward but not necessarily perfectly achieving that goal immediately. STEPH: I think that's a nice representation of essentially how you and I have processed things. We've highlighted before that you and I...it's funny, I just made the joke about not talking to people, but it's how I actually process stuff. And the best is when I'm talking out loud to somebody else. And so it totally makes sense that as you were noticing this and reflecting on it, that then this is another way that you are then processing those changes and reflecting on it and thinking through is this a good change? Is it something that I'm going to enjoy? Or am I really going to miss my street coding creds? I need to get back to the editor. CHRIS: I just need that precious flow state that comes from drinking some Mountain Dew and coding for hours. STEPH: Do you drink Mountain Dew? CHRIS: No, I gave it up years ago. STEPH: [laughs] CHRIS: I don't drink soda broadly. But if I'm going to drink soda, it's going to be Mountain Dew because if we're going to do it, let's do this thing. I'm pretty sure that stuff is like thermonuclear, but that's fine. STEPH: [laughs] That's funny. I know we've had this conversation before also around Pop-Tarts where you're like, hey, if I'm going to have a Pop-Tart, I'm going to have the sugariest (Is that a word - sugariest?) Pop-Tart possible. CHRIS: To be clear, that means it has icing on it because some people in the world, namely you, would prefer the ones without icing. Although we recently learned that the ones without icing have a higher fat and calorie content, so I don't know. The world's murky. I wish it were all just clear, and we could just work with it. But it turns out even Pop-Tarts icing versus not is not a simple question. STEPH: It's a very simple question. You just need to be on the right side, which is the non-frosted side. [laughs] I can simplify this for you because fat is delicious. Fat trumps sugar; that's my stance. That's my hot take. CHRIS: I'm saying both, a little from column A, a little from column B. You got yourself a stew. STEPH: [laughs] You got a fat sugar stew. CHRIS: Yeah. That was in Arrested Development. All right, we're veering way off course now. [laughter] To bring it back, what you were highlighting of I'm definitely someone who thinks through stuff by talking out loud, and so it's been wonderful. I've learned so much about myself while talking to you on this podcast. I'll say something, and I'll be like, wait, I actually believe that thing I just said. This is fantastic. Now I can move forward with the knowledge that I've just gained for myself by talking about it on a podcast. So highly recommended: everybody should get a podcast. STEPH: Plus one. I also have a very real, maybe silly, follow-up question for you as we are, like you just said, exploring the things that we believe or not. My question for you is part of the transition to management and moving away from coding. Isere some fear in the back of your mind where you're like, if I stopped coding, I'm going to lose this skill? CHRIS: Honestly, no. And I feel kind of bad saying that because I feel like I should say, "Yeah, I feel like it'll fade away and whatnot." But I think I have an aptitude and an interest towards this work. And if I were to ignore it for two years, then frankly, I also know myself. And I'm still going to keep an eye on everything for a while. So I think I'll be aware of what's going on and maybe just haven't spent as much time with it. But I think if I need to two years from now, I'm like, all right, I got to rebuild my coding muscle. I'll skip a couple of JavaScript frameworks, which will be nice, and I'll be on to the 15th iteration that's new now. But I hope that I could revisit that not trivially, not with no effort. It's the wonderful nature of coding. It's one of the things that I love about it so much is that there are blog posts and YouTube tutorials. And it's so individually discoverable that I'm not really worried about that aspect. My concern, if anything, isn't so much that I'm going to lose my skills or not be able to code anymore; it's that I really enjoy coding. It's a practice that I find very enjoyable. A workweek is enjoyable when it contains big blocks of me putting on my headphones, listening to music, and digging into a problem, and then coding and producing a solution. And those tiny little feedback loops of test-driven development or running something and then going to the browser and clicking around like that, there's a directness there that has always really worked well for me. And so the more I'm abstracted away from that sort of thing, and the more of my work is I'm helping a team, and I'm directing strategy, or whatever it is, that just feels so indirect. And so I'm very interested to find out how I respond to that sort of thing. I've definitely enjoyed it in the past, and so that's why I'm intentionally leaning into it. But I know that I'm giving up a part of the work that I really love, and giving up is too strong of a word as well. I'm going to find what shape makes sense moving forward. And I expect I'll still be pairing with the other developers on the team and helping to define architecture and things like that. So it's not like it's 100% gone. But for now, I think the world where most of my week was spent coding is no longer the case. And so just naming that and being intentional about it. And yeah, that's the game. STEPH: Cool. Yeah, that makes a lot of sense. I was mainly interested in that question because that is a question that I've asked myself from time to time that I think I do have that worry that if I step away from coding for too long, then it won't be easy to jump back into. And I've talked myself out of that many times because I don't think it's true for all the reasons that you just said. But it is something that I have considered as like, well, if I take this leap of faith into this other direction, how easy is it for me to get back if I decide to change my mind and go back to being more of an individual contributor? And one other thing that weighs on me as I'm splitting my time between two areas that I really want to grow…So I'm constantly trying to grow as a developer. I'm also trying to grow as a manager, and I don't want to do a bad job at either. I want to do a great job at both, and that's frankly not always possible. And at times, I have to make trade-offs with myself around okay, I'm going to focus a little heavier this day or this week on being a really great manager or focus a little bit more on being a developer and to pick and choose those topics. And then that sometimes means doing like B+ work in one area, and that's really hard for me. I'm an A-work person. So even downgrading to a B+ level of effort is challenging. But I have found that that's a really great space to be because then I'm doing well in both areas, not perfect, but doing well enough. And often, that's really what counts is that we're doing well enough and still pursuing growth in the areas that are important to us. CHRIS: Yeah, I think that intentional switching back and forth between them is the space that I'm in. I expect my work will remain very technical, and I hope that that's true. And I think to a certain extent; I get to shape it and determine that. And so how much of it is strategy and planning and things like that? Versus how much of it is helping the team with architecture and defining processes as to how we code, and what are our standards, and what are our languages and frameworks and all of that? I expect I'm still going to be involved in the latter. And again, I think to a certain extent; I get to choose that. So I am actually interested to see the shape that both naturally the organization needs out of the role that I'm in. But also, what sort of back pressure I can apply and be like, but this is how I want it to be. Is there room for that, or is there not? And it's all an experiment, and we're going to find out. But personally, for me, I'm going to keep reading Twitter and blog posts every day, and I'm probably going to code on the weekends and things. So the idea of my coding muscle atrophying, I don't know, that one doesn't feel true. But we'll see what I have to say a year from now or after what that looks like. But I expect...this has been true of me for so long, even when I had an entirely different career that I was just reading blogs and other things all the time because this is a thing that deeply interests me. So we will see. STEPH: Yeah, I'm excited to hear how it goes. And I think there's something to be said for the fact that you are also a CTO that's very close to the work that's being done. So being someone that is very involved in the technical decisions and the code that's being written but then also taking on more of the management responsibilities. And that feels more of a shift where you still have a lot of your coding skills. And you are writing code day-to-day at least based on what you're saying, but then you are also acquiring a lot of these management skills to go along with it. Versus if someone were going into management and maybe they're at a really large company and then they are very far away from the development team. And they're focused on higher-level themes and discussions, at least that's my guess. But I'm very excited to hear more about your updates and how this experiment is going and to find out who is the true Chris? CHRIS: Who's the true Chris? That feels complicated. I feel like I contain multitudes. But yeah, you know what? I'm excited to find out as well. Let's see what's going on there. But yeah, so that's a grand summary of the things that are going on in my head. And I expect these are topics that will be continuing to evolve for me. So I think we'll probably have more conversations like this in the future but also some tech stuff. Because like I said, I don't know, I can't stop. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: Yeah, that's actually the perfect segue as we were talking earlier about just ways that we're looking to grow as developers. And I saw something that I really enjoyed, and it's published by another thoughtboter. Their name is Matheus Richard. And Matheus runs a Twitter account that's called @RubyCards. And I don't recall the exact cadence, but every so often, Matheus will share a new snippet of either Ruby or Rails code and then will often present the information as a question. So I'll give you an example, but the highlight is that it teaches you something, either about Ruby or Rails. Maybe you already knew it, maybe you didn't. But it's a really nice exercise to think through okay, I'm reading this code. What do I think it's going to return? And then respond to this poll and then see how other people did as well. Because once the poll closes, then Matheus shares the actual answer for the question. So one example that I saw recently highlights Ruby's endless method definition, which was introduced in Ruby 3. So that would be something like def, and then let's say the method name is message. And then you have closing, but empty parenthes equals a string of "Hello, World." And so then the question is if you call that method message, what would that return? And then the poll often has options around; it would return "Hello World," or it's going to return a syntax error. It's going to return nil. And then it highlights, well, because of Ruby's endless method definition, this would return "Hello, World." And then I also saw a new method that I hadn't used before that's defined in Ruby's Hash class that's called store. And so you can use it calling it on a Hash. So if you have your hash equals and then curly brackets, let's say foo is equal to an integer of zero, then you can call hash.store and then pass in two arguments. The first argument's going to be the key. The second argument is the value. And then, that would essentially be the same syntax that we use for assigning a value to a hash. But I just hadn't actually seen the method store before. So there are fun snippets of Ruby or Rails code. A little bit of a brain teaser helps you think through how that code works, what it's going to execute, what it's going to return. And I really enjoy it. I'll be sure to include a link to it in the show notes so other people can check it out. CHRIS: Oh, that sounds fun. I hadn't seen that, but I will definitely be following. That's the word on Twitter, right? You have subscribing, subscribe and follow, smash that like button, all of the things. I will do all of the things that we do here on the internet. But I do like that model of the question and answer, and it's slightly more engaging than just sharing the information. So yeah, super interested to see that. STEPH: Yeah, I like the format of here's some code, and then we're going to ask you what does it return? So that way, you get a moment to think it through. Because if I read something and it just shows me the answer, my brain just doesn't absorb it. And I'm like, okay, that makes sense, and my brain quickly moves on. But if I actually have to think about it and then respond with my answer, then it'll likely stick with me a lot longer. At least we'll find out; that's the dream. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes,; maybe as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

On this special edition of The Changelog, we're talking with Cory Wilkerson, Senior Director of Engineering at GitHub, about GitHub Codespaces. For years now, the possibility of coding in the cloud seemed so close, yet so far away for a number of reasons. According to Cory, the raw ingredients to make coding in the cloud a reality have been there for years. The challenge has really been how the industry thinks, and we are now at a place where the skepticism in cloud based workflows is “non-existent.” After 15 months in preview, GitHub not only announced the availability of Codespaces for Teams and Enterprise — they also showcased their internal adoption, with 600 of their 1,000 engineers using it daily to develop GitHub.com. On this episode, Cory shares the full backstory of that journey and a peek into the future where we're all coding in the cloud.

On this special edition of The Changelog, we're talking with Cory Wilkerson, Senior Director of Engineering at GitHub, about GitHub Codespaces. For years now, the possibility of coding in the cloud seemed so close, yet so far away for a number of reasons. According to Cory, the raw ingredients to make coding in the cloud a reality have been there for years. The challenge has really been how the industry thinks, and we are now at a place where the skepticism in cloud based workflows is “non-existent.” After 15 months in preview, GitHub not only announced the availability of Codespaces for Teams and Enterprise — they also showcased their internal adoption, with 600 of their 1,000 engineers using it daily to develop GitHub.com. On this episode, Cory shares the full backstory of that journey and a peek into the future where we're all coding in the cloud.

Imagine working on projects that last for two weeks or less. This is what today's guest, Jason Etcovich, gets to do all the time! Jason is a Senior Software Engineer at GitHub, where he is part of the Special Projects team. He is also involved in the Paper Cuts project, which works directly with the community to fix small to medium workflow problems. In this episode, Jason sheds light on how he became a software engineer having come from a design background. While this may sound like a drastic shift, it was gradual, which made the transition smoother. We talk about some of the exciting happenings at GitHub, like GitHub Pilot, Paper Cut, and Codespaces, and what these projects will offer the community. Our conversation also touches on automation and where it goes right and wrong, how to use software to make our lives better, and as usual, we get into some classic developer debates. Tune in to hear it all. Key Points From This Episode: Get to know today's guest, Jason Etcovitch, and want he does.  How Jason went from graphic design to working at GitHub.  Hear more about the work that Jason does through Paper Cuts.  Insights into Paper Cuts' research and how they decide which projects to take on.  The importance of having a design thinking mindset when you problem solve.  A high-level view of GitHub Pilot, GitHub's new machine learning feature.  What it is like working on projects that do not last longer than two weeks.  The open graph image generator project Jason is excited about.  How to justify projects without necessarily having the data to back up projects.  Some of the ways we can make our lives better with software, according to Jason.  Common pitfalls Jason sees when trying to set up automations.  Everyone's take on Prettier and Standard JS.  Getting into the semicolon debate: everyone weighs in.  What everyone thinks about the age-old tabs versus spaces fight.  A look at one of GitHub's latest releases, Codespaces.  Hear what the picks for the week are. Tweetables: “Part of learning that design mindset is understanding like, how does a person approach this thing? What are the various touch points that they have to consider?” — @JasonEtco (https://twitter.com/jasonetco?lang=en) [0:10:03] “How do you say like, ‘Oh, yes. This is important,” If you don't have the data to back it up.” How do you get the data to back it up, if you don't prioritize that project? Where in that loop does it fit to get all of that data?” — @JasonEtco (https://twitter.com/jasonetco?lang=en) [0:19:57] “If you build your automation tool in an inflexible way, you'll really regret it later.” — @JasonEtco (https://twitter.com/jasonetco?lang=en) [0:27:13] Links Mentioned in Today's Episode: * ProBot (https://probot.io) * Github Feedback (https://github.com/github/feedback) * Alex Tweets at Nat (https://twitter.com/fimion/status/1425886335391473664) * StandardJS (https://standardjs.com/) * Jason on Twitter (https://twitter.com/JasonEtco) * Jason's Website (https://jasonet.co) * Wyze Camera (https://wyze.com/wyze-cam.html) * She-Ra and the Princesses of Power (Netflix (https://www.netflix.com/title/80179762)) * Marple (puzzle game) (https://apps.apple.com/us/app/marple/id288689440) * VSCode in the browser (https://twitter.com/notdetails/status/1425506229401657353), Joel Califa * The Matrix (https://www.imdb.com/title/tt0133093) * @EnjoyTheVueCats (https://twitter.com/EnjoyTheVueCats) Special Guest: Jason Etcovitch.

Show Notes:Links:MicromortNoblesse obligeJosh's dotfilesGitHub Code SpacesFull Transcript:Ben:Yeah. I've been holding out for the new MacBook Pros. The M1 is pretty tempting, but I want whatever comes next. I want the 16-inch new hotness that's apparently supposed to be launching in November, but I've been waiting for it so patiently for so long now.Josh:Will they have the M2?Ben:Yeah, either or that or M1X. People are kind of unsure what the odds are.Starr:Why do they do that? Why did they make an M1 if they can't make an M2? Why do they have to keep... You just started, people. You can just have a normal naming scheme that just increments. Why not?Josh:M1.1?Ben:That would be awesome.Starr:Oh, Lord.Josh:Yeah, it would.Ben:M1A, Beachfront Avenue.Starr:So last week we did an Ask Me Anything on Indie Hackers, and that was a lot of fun.Josh:It was a lot of fun.Starr:I don't know. One of the most interesting questions on there was some guy was just like, "Are you rich?" I started thinking about it. I was like, "I literally have no idea." It reminded me of when I used to live in New York briefly in the '90s or, no, the early '00s. There was a Village Voice article in which they found... They started out with somebody not making very much money, and they're like, "Hey, what is rich to you?" Then that person described that. Then they went and found a person who had that level of income and stuff and they asked them, and it just kept going up long past the point where... Basically, nobody ever was like, "Yeah, I'm rich."Josh:Yeah. At the end, they're like, "Jeff Bezos, what is rich? What is rich to you?"Starr:Yeah.Josh:He's like, "Own your own star system."Starr:So, yeah, I don't know. I feel like I'm doing pretty good for myself because I went to fill up my car with gas the other day and I just didn't even look at the price. The other day, I wanted to snack, so I just got a whole bag of cashews, and I was just chowing down on those. I didn't need to save that. I could always get another bag of cashews.Ben:Cashews are my arch nemesis, man. I can't pass up the cashews. As far as the nut kingdom, man, they are my weakness.Starr:I know. It's the subtle sweetness.Ben:It's so good. The buttery goodness.Starr:Yeah, the smoothness of the texture, the subtle sweetness, it's all there.Ben:That and pistachios. I could die eating cashews and pistachios.Josh:There you go. I like pistachios.Ben:Speaking of being rich, did you see Patrick McKenzie's tweet about noblesse oblige?Josh:No. Tell me.Ben:Yeah, we'll have to link it up in the show notes. But, basically, the idea is when you reach a certain level of richness, I guess, when you feel kind of rich, you should be super generous, right? So noblesse oblige is the notion that nobility should act nobly. If you have been entrusted with this respect of the community and you're a noble, then you ought to act a certain way. You got to act like a noble, right? You should be respectful and et cetera. So Patio was applying this to modern day, and he's like, "Well, we should bring this back," like if you're a well-paid software developer living in the United States of America, you go and you purchase something, let's say a coffee, that has basically zero impact on your budget, right? You don't notice that $10 or whatever that you're spending. Then just normalize giving a 100% tip because you will hardly feel it, but the person you're giving it to, that'll just make their day, right? So doing things like that. I was like, "Oh, that's"-Josh:Being generous.Ben:Yeah, it's being generous. Yeah. So I like that idea.Josh:That's cool.Ben:So-Starr:So it's okay to be rich as long as you're not a rich asshole.Ben:Exactly. Exactly. That's a good way to bring it forward there, Starr.Starr:There you go. I don't know. Yeah. I think there's some historical... I don't know. The phrase noblesse oblige kind of grates at me a little bit in a way that I can't quite articulate in this moment, but I'll think about that, and I will get back with you.Josh:Wait. Are you saying you don't identify as part of the nobility?Starr:No.Ben:I mean, I think there's a lot of things from the regency period that we should bring back, like governesses, because who wants to send your child to school in the middle of a COVID pandemic? So just bring the teacher home, right?Starr:Yeah. That's pretty sexist. Why does it have to be gendered? Anyway.Ben:Okay, it could be a governor, but you might get a little misunderstanding. All of a sudden, you've got Jay Inslee showing up on your doorstep, "I heard you wanted me to come teach your kids."Josh:I don't know. I'll just take an algorithm in the home to teach my kids, just entrust them to it.Starr:Yeah. Oh, speaking of bringing things back, I told y'all, but I'll tell our podcast listeners. On Sunday, I'm driving to Tacoma to go to somebody's basement and look at a 100-year old printing press to possibly transport to Seattle and put in my office for no good reason that I can think of. It just seems to be something that I'm doing.Josh:Do you like that none of us actually asked you what you were intending to do with it? I was like, "Yeah, just let me know when you need to move it. I'm there." I just assumed you were going to do something cool with it, but ... Yeah.Starr:I appreciate that. I appreciate the support. I'm going to make little zines or something. I don't know.Josh:Yeah. If I get a lifetime subscription to your zine-Starr:Okay, awesome.Josh:... that would be payment.Starr:Done. Done.Josh:Cool.Ben:Yeah, sign me up, too. I'll be there.Starr:Well, I appreciate that.Ben:I mean, who could resist that invitation, right, because you get to... If you get to help with moving that thing, you get to see it, you get to touch it and play with it, but you don't have to keep it. It's somebody else's problem when you're done with the day, so sounds great to me.Starr:There you go. Well, I mean, if you read the forums about these things, this is one of the smaller ones, so people are just like, "Ah, no big deal. No big deal. It's okay." But I was happy to hear that there's no stairs involved.Ben:That is the deal-breaker. Yeah.Josh:Yeah. But it-Ben:If you ever get the friend helping you to move their piano, you always ask, "Okay, how many flights of steps," right?Starr:Yeah. Oh, I just thought of something I could do with it. I could make us all nice business card to hand out to nobody.Ben:Because we're not going anywhere.Josh:I just think of my last six attempts at having business cards. They're all still sitting in my closet, all six boxes of-Starr:I know. People look at you like, "What, really, a business card? What?"Josh:Yeah, like all six generations.Starr:Yeah.Ben:I hand out one or two per year. Yeah, just random people and like, "Hey, here's my phone number." It's an easy way to give it to somebody.Josh:Just people on the street?Ben:Exactly. Like a decent fellow, "Here you go." Thank you.Josh:Yeah.Starr:It's like, "I've got 1000 of these. I got to justify the cost somehow."Josh:We got to move these.Starr:We could start invoicing our customers by snail mail. I could print a really nice letterhead.Ben:I think we have a few customers who would be delighted to receive a paper invoice from us because then they would have an excuse to not pay us for 90 days.Starr:Yeah.Josh:Isn't owning a printing press like owning a truck, though? Once people know you have it, everyone wants to borrow it.Starr:It's going to be pretty hard to borrow for a 1000-pound piece of iron.Josh:Well, they're going to want to come over and hang out in your basement and do their printing. This is the Pacific Northwest, like-Starr:It's their manifestos.Josh:Yeah. They got to print their manifestos, lists of demands.Starr:They don't want the establishment at Kinko's to be able to see.Josh:Right.Ben:I don't know. It's got to put you on a special kind of watch list, though, if you have a printing press in your home, right? All of a sudden, some people are really interested in what you're up to.Josh:It's like a legacy watch list.Ben:I'm just flashing back to, yeah, in the 1800s when cities, towns would get all-Starr:There you go.Josh:Well, yeah, because they're like-Ben:The mob would come out and burn down the printing press building and stuff.Josh:If you wanted to be a propagandist back then, you had to buy a printing press and then you get put on a watch list. That just never went away. They're still looking for those people. They just don't find as many of them these days.Starr:Yeah. It's so inefficient. It's not the super efficient way of getting the word out, though, I hear, unless you want to be one of those people handing out leaflets on the side of the road.Josh:Well, you could paper windshields in parking lots.Starr:Oh, there you go. Yeah.Josh:Yeah, that's how they used to do it.Starr:No, look at my beautifully hand-crafted leaflet that you're going to throw in the gutter.Josh:Mm-hmm (affirmative).Ben:I think you just settled on what your next adventure's going to be after Honeybadger. You're ready to put this business aside and focus on printing up flyers for your local missing cat.Starr:There you go. There you go. Band flyers, that's big business.Josh:But you could get into fancy paper. That's a whole thing up here. It's pretty cool, actually.Starr:Yeah. I don't know. Really, I was like, "Oh, it'd be cool to have a big thing to tinker with." I'm learning about myself that I like having just a big physical project going on, and I'm pretty... Like, I built this backyard office, and that took up two years of my time. Ever since then, I don't have a big physical thing to work on, so I'm thinking this might fill that niche, that niche, sorry. I read a thing that's like don't say niche, Americans. Niche.Ben:I don't know, Starr. Maybe you should think of the children and then think about 50 years from now when you're dead and Ida's cleaning out the house and she's all like, "Why is there this printing press?"Starr:Oh, there you go.Josh:Have to move it.Starr:They'll just sell it with the house.Ben:There you go.Starr:Yeah. I mean, the funny thing is, is that it is wider than the doorway, so I would either have to dissemble it partially or take out the door. I put the door in, so I know how to take it out, so there is a good chance the door's coming out because I have less chance of messing something up if I do that one. But we'll see.Ben:Echo that.Starr:Well, thank you.Josh:You should've put one of those roll-up doors in there.Starr:I should've, yeah.Josh:Those are cool.Starr:What was I thinking?Josh:You really did not plan ahead for this.Starr:Yeah. I mean, walls are really only a couple of thin pieces of plywood, and you can just saw through it.Josh:Just a small refactor.Starr:Yeah.Josh:Yeah.Starr:And that would-Josh:Did y'all see that someone listened to every episode of this podcast in a row?Starr:I know. I feel so bad. I feel so bad for them.Josh:Speaking of-Starr:We're sorry. We're so sorry.Ben:I was feeling admiration. I'm like, "Wow, that's impressive," like the endurance of it.Starr:I just think we would've made different decisions.Ben:I don't know. But not-Josh:Maybe it's pretty good. I haven't gone back and gone through it all and never will, but-Ben:Well, I mean, not only did they say they listened to every episode, but then they were eager for more. They were like, "When are you getting done with your break?" So I guess-Starr:There you go.Ben:... that net it was positive, but-Josh:We must not be too repetitive.Ben:Must not.Starr:Stockholm syndrome.Josh:We're sorry.Ben:Well...Starr:I'm sorry. I don't have anything informative to add, so I'm just going to be shit-posting this whole episode.Ben:Well, I've had an amazing week since we last chatted. I kept reflecting on how I couldn't remember anything that I did over the past whatever months. Well, this past week, I can remember a whole bunch of things that I did. I've been crazy busy and getting a bunch of little things knocked out. But today, today was the capstone of the week because I rolled over our main Redis cluster that we use for all of our jobs, all of the incoming notices and whatevers. Yeah, rolled over to a new Redis cluster with zero downtime, no dropped data, nobody even noticed. It was just smooth as-Starr:Oh my God.Josh:I saw that.Starr:Awesome.Ben:It's going pretty good.Starr:Just like butter?Ben:Just like butter.Starr:They slid right out of that old Redis instance and just into this new... Is it an AWS-managed type thing?Ben:Yeah, both of them were. They all went on the new one, but... Yeah.Josh:It's, what, ElastiCache?Ben:Yep. Smooth like a new jar of Skippy.Josh:I saw that you put that in our ops channel or something.Ben:Yeah. Yeah, that's the topic in our ops channel.Josh:So it's the subject or the topic, yeah. We're making ops run, yeah, like a jar of Skippy.Starr:Why isn't that our tagline for our whole business?Ben:I mean, we can change it.Starr:I don't know why that's making me crack up so much, but it is.Josh:Skippy's good stuff.Starr:Oh my gosh.Josh:Although we-Ben:Actually-Josh:... usually go for the Costco natural brand these days.Ben:Well, we go for the Trader Joe's all-natural brand that you have to actually mix every time you use it. I prefer crunchy over creamy, so, actually, my peanut butter's not that smooth, but... You know.Josh:Yeah.Ben:It's okay. But, yeah, I love our natural peanut butter, except for the whole churning thing, but you can live with that.Starr:We're more of a Nutella family.Ben:Ooh, I do love a Nutella.Josh:Ooh, Nutella.Ben:Mm-hmm (affirmative), that's good stuff.Josh:We made pancakes the other day, and I was putting Nutella on pancakes. I did this thing, like I made this... We have one of those griddles, like an electric griddle, and so I made this super long rectangular pancake, and then I spread Nutella on the entire thing, and then I rolled it so that you have this-Starr:You know what it's called, Josh.Josh:What is it called?Starr:That's called a crepe.Josh:So it's a crepe, but it's made out of a pancake.Starr:It's a Texas crepe.Ben:Texas crepe.Josh:Yeah, a Texas-Starr:A Texas crepe.Ben:Yes.Josh:Is it really a Texas crepe because that's... Yeah, so, I-Starr:Oh, no, I just made that up.Ben:That sounds perfect, yeah.Josh:Well, it is now.Ben:Yeah, it is now.Josh:It is now, and I highly recommend it. It's pretty amazing.Ben:Throw some Skippy on there and, man, now it's a... That's awesome.Josh:Peanut butter's also good on pancakes.Starr:That's why people listen to us, for our insights about business.Ben:Yeah, there was this one time, speaking of pancakes and peanut butter...Josh:How did we get on pancakes? Like, oh, yeah, ops.Ben:This one time, I went over to dinner at some person's house, and I didn't know what dinner was going to be, but we got there and it was breakfast for dinner, which I personally love. That's one of my favorites.Starr:I knew that about you.Ben:So they're like, "Oh, I'm sorry. Hope you don't think it's weird, but we're having breakfast for dinner." I'm like, "No, no, I love it." So eggs and bacon and waffles, and so I'm getting my waffle and I'm like, "Do you have some peanut butter," and they're like, "Oh my goodness, we thought you would think that was way too weird, and so we didn't have the peanut butter." They whipped it out from in the counter. It's like, "Oh, shew, now we can have our peanut butter, too." I'm like, "Oh, yeah, peanut butter on waffles, yeah."Josh:Everyone had their hidden peanut butter.Ben:Mm-hmm (affirmative).Josh:Yeah.Starr:And that's how you level up a friendship.Ben:There you go. So, yeah, the week was good. The week was good. Bugs got fixed, things got deployed, and, yeah, just a whole-Josh:Yeah, you had a bunch of PRs and stuff for little things, too, which-Ben:Yeah. And got some practice with the whole delegating thing, got Shava doing some stuff, too. So, yeah, just all-around super productive week.Josh:Nice. I got Java to run in a Docker container, so my week's going pretty good.Ben:And that took you all week?Starr:What do those words mean? I don't...Josh:Yeah.Starr:Was your audio cutting out? I don't know. I just heard a bunch of things I don't understand.Josh:Well, for your own sake, don't ask me to explain it.Starr:Yeah, it's like better not looked at.Josh:Yeah.Ben:Why would you subject yourself to that sort of torture, Josh?Josh:Oh, well, because running Java on an M1 Mac is even worse.Starr:Oh my Lord.Josh:Well, actually, running it, period. But, yeah, like just our Java package. I mean, I've spent half this podcast ranting about our packaging, so I don't need to get too deep into it. But every time I release this thing, it's like it just doesn't work because I've forgotten my... I've changed my system, and Java and Maven package repository are just like that. So I figure if I can make some sort of reproduceable development environment using Docker, then in two years everything will just be smooth as a jar of Skippy.Ben:Skippy. Yeah, yeah.Starr:Well, I had a chance to-Josh:I reckon.Starr:I had a chance to dig into some numbers, which is one of my favorite things to do, and so... I don't know. There was this question that was just bothering me, which was... Well, let me just back up. So we've had some success, as you guys know, in the past year. We've almost doubled our rate of new user sign-ups, not new user sign-ups, like conversion to paid users. We've doubled our paid user conversion numbers, rate, whatever you call it. And so, obviously, revenue from users has gone up as well, but since we are a... Our plans are basically broken down by error rates, right? So what happens when people upgrade is they get too many errors for their plan. It says, "Hey, you should upgrade if you want to keep sending us errors," and they do.Starr:I had this weird situation where it's like I wasn't sure... In our system, revenue from users was coming just from whatever plan they picked when they signed up, and so I was wondering, "Well, what if they sign up, and then a week later they upgrade? That's going to be counted under upgrade revenue instead of new user revenue," which, really, it really kind of should be. So I got to digging, and I found that it doesn't really make that big of a difference. Some people do upgrade pretty quickly after converting, but they don't... It's not really enough to really change things.Josh:Yeah.Starr:Then, also, just sort of offhand, I took a little sneak peek. I've been running this experiment to see if lowering our error quota for our basic, our free plan, it would increase conversions. So I took a little sneak peek at the data. It's too soon to know for sure, but so far the conversion rate, I think, is going to end up being higher, which is what I would expect, so that's good, and-Josh:Nice.Starr:Yeah. And when we're done, I'm going to look at sign-ups just to make sure that they are still in line.Ben:Yeah. Anecdotally, I've seen a smaller window from trial to paid conversion. Well, not trial, but freemium to paid conversion. I've seen people who are signing up, getting on the basic plan, and then within some short time period they're actually going to a team plan.Josh:Oh, that's good to know.Ben:That's happening more often than it was, so... Yeah. So that's-Josh:Cool.Ben:I'm just saying the same thing Starr said but without real data.Josh:Yeah.Starr:Yeah, it's awesome. Yeah, we need a little bit more time to see how things pan out, too, because it's... One thing I figured out that I will share with our readers, our readers, I'm used to doing the blog posts, I'll share with our listeners that I figured out that you really have to pay attention to, on free plans especially, is comparing conversion rates between time periods. So if you make a change and then you wait for a month of data to come in and you're like, "Okay, let's look at the conversion rate for the past month after the change with the conversion rate for the time period before the change," that is really an apples to oranges comparison because on the one hand you've had people who have maybe had a year to upgrade versus people who've had a month to upgrade. So you have to be really careful to make it apples to apples, right, where you only compare... If you have a month worth of users on one side, you compare it to a month worth of users on the other side, and you only count the conversions that happened in that time period.Josh:Makes sense.Starr:Yeah. So, anyway, that's just my little freebie data analysis thing for our listeners.Josh:We should have Starr's weekly data science tip.Starr:Starr's data corner.Josh:Yeah.Ben:Love it.Josh:Yeah. We could move the podcast to segments. We've never done segments. We could introduce segments if we need to spice things up on FounderQuest.Ben:Yeah. Totally. Well, speaking of spicing things up, I had a brilliant idea this morning.Starr:Oh, I want to hear it.Ben:Yeah. So one of the things that I keep an eye on is how much we spend on hosting because that's a good chunk of our expenses. We always want to make more money, and one way to make more money is to have fewer expenses. So I had this brilliant idea on how to cut expenses. We can chop our AWS bill in half by just not running everything redundant.Starr:There you go.Josh:Brilliant.Starr:Would you say the AWS is the sixth Honeybadger employee?Ben:Yeah, pretty much.Josh:Yes. That's a good way to put it, actually.Starr:Yeah.Josh:Yeah.Ben:Well, in the early days, before we were paying ourselves a full salary, I remember we budgeted 25% for Starr, 25% for Ben, 25% for Josh, and 25% for hosting.Josh:Yeah.Ben:Yeah, I don't think we ever exceeded the 25%, which is good. That would be a bit high. So, yeah, AWS is like our sixth employee.Starr:Yeah, it's funny because do we even have other expenses?Josh:No.Ben:I mean, salaries is definitely the biggest one, and our health insurance is not cheap either.Starr:Yeah.Ben:Advertising.Starr:I was thinking like marketing, advertising. Yeah.Ben:Yeah. Advertising and marketing, that's the next one.Starr:That's the next 25%.Josh:Can we make AWS our seventh and eighth employee, too?Ben:Eventually may. Yeah, I did some... Oh. Oh. So I told you my great success that I had this morning. Well, your comment just now about AWS made me think about the one failure, just amazingly huge failure that I had also this week, migrating a bunch of data from Redis to DynomoDB. So we have this situation where it's one of those seemed like a good idea at the time kind of thing where we're doing a bunch of counting of people and individuals that hit errors, and we're counting that in Redis. I'm like, "Okay, great," because Redis has this INCRBY and it's easy and it's atomic and, boom, you're done, and I just never paid much attention to it until a few weeks ago, and I was like, "Yo, you know what? That's actually a lot of data in there, and we're keeping that forever, and so it's probably better to put it someplace that's not Redis." So I'm like, "Ah, I know. I'll do DynamoDB because it has an increment thing and...Josh:Yeah.Ben:So I put a table together, and I wrote a migration script, and I migrated a bunch of data. It took two days. It's great. Everything is beautiful. Had buckets of data inside DynomiteDB, and then I went to go query it, and I'm like, "Oh, I can't query it that way because I don't have the right index." Well, that sucks. All right. So you can't create a local index on DynomiteDB without recreating the table. I'm like, "Okay, well, that sucks. I just lost two days worth of data migration but oh well." So dump the table, recreated it with the index, and started redoing the data migration, and I'm like, "Yeah, it might take two days, no problem." So I check on it every half-day or so, and it's not going to be getting done after two days. Three days go by, and I'm checking the work backlog, and I was like, "It's just flat."Ben:Turns out because of that local index, now Dynamo can't really write fast enough because the way they do the partition throttling and stuff because we have some customers who have huge chunks of data. So their partitions are too big for Dynamo to write very quickly. Hot partition keys is the problem. So I just gave up. I'm like, "All right, fine." Drop the table again, recreated it, and now we're just double writing so that, eventually, given six months from now or so, it'll be there and I can replace that thing in Redis.Josh:Nice.Ben:So this is my life, the ups and the downs. So, yeah.Josh:And just waiting six months.Ben:And just waiting six months.Josh:Yeah. That's funny, but that is kind of a pattern in the business. In some cases, we need to just wait for the data to populate itself, and we just have to basically wait our retention period because data tends to turnover and then we can drop the old database or whatever.Ben:Yeah. Yep. But, luckily, nobody noticed my big fail, so it's all good. It didn't impact the customers.Josh:I didn't notice.Ben:So, yeah, busy weekend.Starr:I noticed, but I didn't say anything because I wanted to be nice.Ben:Thank you, Starr. Appreciate that.Starr:Yeah, I [inaudible].Josh:Starr was over there just quietly shaking her head.Ben:Just judging. Just judge-Starr:No, sorry.Ben:So, Josh, I'm going to get back to this Java thing because I'm curious. I remember, I don't know, a year ago or something, we're kind of like, "Maybe we should just not when it comes to Java anymore." So I'm curious what prompted this renewed activity to do a new release.Josh:Well, I don't know. I figured... I don't know. Didn't we say we were just not going to do any releases?Ben:Yeah, it just-Josh:It's not high on my list of development. We're not spending a bunch adding stuff to it, but there are dependency updates that have been getting merged in. I merged the Dependabot PRs and stuff. There's something else. There might be some small PR or something that someone submitted that was sitting there on release, and I just can't handle just unreleased code sitting on the pane. So it's just one of those things that's been sitting on my backlog halfway down the list just gnawing at me every week, so I figured I'd dive in and at least get some sort of quick release, relatively quick release process down so we can just continue to release dependency updates and stuff, like if there's a security update or something, so...Ben:Yeah.Josh:Some people still do use it, so I want to make sure they're secure.Ben:Make sure they're happy. Yeah.Josh:Yeah. But, yeah, that's a good point. We are not treating all platforms as equal because we just don't have the resource, so we need to focus on the stuff that actually is making us money.Ben:Yeah. Yeah, it's tough when very few of our customers are actually using that for it to get a whole lot of priority.Josh:That said, we have already put a lot into it, so as far as I know, it works well for the people that have used it.Starr:So are y'all encouraging our customers to do more Java?Josh:Yes, switch to Java. Then switch to SentryBen:Ride a wave.Josh:... or something.Ben:So I've been contemplating this new laptop showing up, right, whenever Apple finally releases it and I get to get my hot little hands on it. I've been thinking, well, the one big downside to getting a new laptop is getting back to a place where you can actually work again, right, getting all your things set up. Some people are smart, like Josh, that have this DOT file, this repo, on GitHub, and they can just clone that, and they're off to the races. I'm not that smart. I always have to hand-craft my config every time I get a new machine. But I'm thinking-Josh:Oh. Take the time.Ben:So, yeah, I'm not looking forward to that part, but GitHub has released Codespaces, and so now I'm thinking, "Ooh, I wonder if I could get all our repos updated so that I could just work totally in the cloud and just not even have a development set-up on my machine." Probably not, but it's a fun little fantasy.Josh:Well, then you could have any little... You could work on your iPad.Ben:Yeah.Josh:Yeah.Ben:Yeah, I don't even need a laptop. Then I could save the company money. That's brilliant, Josh.Josh:Yeah. You could work at the library.Starr:Yeah. It's like, "So your main ops guy, I see he's primarily working from a five-year-old iPad."Ben:At a library.Starr:In a library.Josh:An iMac.Starr:When he gets paged, he has to run to the nearest Starbucks and get that wifi.Josh:Yeah. I got to say, having your DOT files all ready to go and all that is pretty good. Also, I've got my Brewfile, too, so all of my Homebrew stuff is automated in that.Ben:Well, that's clever. I never even thought of that.Josh:It does make it very quick to bootstrap a new machine.Ben:Yeah. Maybe I should take this as initiative to actually put my stuff into DOT files repo and get to that point.Josh:Careful, though, because you might... I've had four computers between your current one and now, so you might end up switching more often because it's easier to do it.Ben:Appreciate that warning. That's good.Josh:Yeah. Speaking of the M1s, I love the M1 MacBook Air that I have. But the battery has been... I don't know what happened, but the battery was fantastic, I don't know, first few months. Ever since then, it's been kind of like it hasn't been lasting. I've been surprised at how fast it's draining, and I go and look at, whatever, the battery health stuff, and it says that health is down to 86% and the condition says it's fair, which does not make me feel warm and fuzzy.Josh:It has 50 cycles, so I think it might be defective, and that sucks because otherwise this machine is maybe one of the best Macs I've had. I guess... Yeah. I've had a few compatibility issues with the architecture, but it's not too bad. I mean, I'm not a Java developer at least, so...Ben:Yeah, I think you need to take that in for a service because that is way soon for that kind of degradation.Josh:Yeah. I might need to do something.Ben:That's a bummer.Josh:Yeah. I don't know. I might have to ship it in because I think our local Portland Apple Store is shuttered currently.Ben:All those protests?Josh:Yeah. It's got eight fences around it and stuff. Downtown Portland's a little rough these days.Starr:Yeah.Ben:Well, I mean, you can always take the trip out to Seattle.Josh:Yeah. Oh, yeah. Or there's other... I forget. There's an Apple Store that's not too far outside of Portland. It's where I bought this, so I could take it down there.Starr:Yeah. I'm sad now because I bought my second MacBook from that store in Portland.Josh:Yeah? It's a good store.Ben:Speaking of you coming out to Seattle, I was thinking the other day that maybe we should do a company-wide get-together sometime soon. Be fun to see everybody again in-person.Josh:It would be. Now that we're all vaxxed, we're all super vaxxed. I don't know that Starr is even down for that, though. I'm just looking at Starr.Starr:I don't know. Like, I-Josh:You don't look like you're too stoked on that idea.Starr:I don't know. I'm just-Josh:What with Delta lurking.Starr:The problem is, Josh, is that you have not been reading nursing Twitter.Josh:Uh-huh (affirmative).Starr:So I don't know. Yeah, it's doable. Currently, I think the CDC just released a thing that said vaccine efficiency of preventing COVID infections... It's very good still at preventing bad, I don't know, disease, health problems, whatever, keeping people out of the hospital. It's very good at that. With Delta, it's about 65% effective at preventing infections, and so if you get infected, you can transmit it to other people.Josh:Right.Starr:Yeah. So it's not impossible. It's just like we're just back to this fricking calculus where every possible social interaction you just have to run it through your spreadsheet and your risk analysis and... Ugh.Josh:Yeah.Ben:It's like, "Are you worthy of the hassle? No. Sorry, can't make it."Starr:Yeah. Yeah. It's like, "Okay, so what's the probability that meeting with you is going to send my child to the hospital? Okay, that's low enough. Sure."Josh:Yeah.Starr:It's just such a weird world.Josh:Wouldn't it be funny if when you get into your car in the morning, it reads out the probability of you dying in a car accident?Starr:Oh, yeah. Do you know about millimorts?Josh:No.Starr:Oh, you should go Google millimorts. A millimort is a one in a million chance that you will die, and so there's tables and stuff that you can find online that have different activities and what the number of millimorts is about them. So you can compare, and you can be like, "Okay, so going skydiving has this many millimorts as driving so many miles in a motorcycle."Josh:That's awesome. Okay, we have to link this in the show notes because I want to remember to look this up-Starr:Okay. I'll go find it.Josh:... so that I can depress people.Starr:I think there was a New York Times article, too.Ben:Yeah, I totally have to see this because I just signed up for a motorcycle training course and I'm going to get my endorsements so that I know exactly what kind of risks... Though that's probably part of the course, where they try to scare you out of actually getting your endorsement. They probably...Josh:By the way, I'm really glad my morbid humor or my morbid joke landed because for a minute there-Starr:Oh, I'm sorry, it's a micromort.Josh:Oh, a micromort. Okay.Starr:I was like, "Isn't milli 1000?"Josh:Minimort, like-Starr:Milli is 1000.Josh:Yeah.Starr:Yeah, that grated at me. I know. My old chemistry teachers are just giving me an F right now.Ben:Yeah, I got to see that.Josh:Well, I'm sure you'll be all right, Ben. I mean, the risk of a motorcycle is much higher than a car, but you just can't think about that all the time because the fun... I'm sure the fun is much...Ben:[inaudible].Josh:It's worth it.Ben:It's worth every hazard. Yeah.Josh:Yeah. The risk is worth the reward.Ben:Yesterday, I just hit 250 miles on the odometer on my scooter, so loving that. It's a lot of fun.Josh:That's cool.Starr:That's a lot of miles for a scooter.Josh:Mm-hmm (affirmative).Starr:I guess you just love to scoot.Ben:I love to scoot. Well, there you go, Starr. There's our happy ending after that slight dip there.Starr:That slight delay into reality.Josh:I like the dark humor. I don't know. It's always a gamble, though, with depending on... Yeah. But I think, Starr, you're always down to get dark.Starr:Oh, yeah. I'm down with the darkness. All right. Well, should we wrap it up?Ben:Let's wrap it.Starr:Okay. This has been a very witchy episode of FounderQuest, so if you liked it, go give us a review and... Yeah, if not, just keep listening to us. Make it a hate listen. You got to have a couple of those in your line-up. 

In Episode 57 of the SAP on Azure Video Podcast we talk about Powerful Dev Conference, Azure Traffic Manager & SAP Business Technology Platform, Enhanced telemetry with Logic Apps & SAP ERP Connector, Codespaces meets Dapr & DaprCon 2021. Then we have a great chat with Nishan Naicker from South Africa, a Cloud Solution Architect at Microsoft focusing on SAP on Azure. Nishan guides us through his journey to Microsoft and provides some great insights on why SAP on Azure is so great! https://youtu.be/nKbspchiaEQ https://github.com/hobru/SAPonAzure

Vasaros aktualijos Apžvelgėme Birželio mėnesio aktualijas ir padiskutavome šiomis temomis: Codespaces non beta! Talibanas ir technologijų kompanijų reakcija .NET atnaujinimai Zoom nerekomenduojama Vokietijoje Apple kontraversija Blizzard kontroversija Bumble saugumo spragos Extra: Tesla AI day ir Elon Musk naujienos

On this episode of DevTalk I speak to Geoffrey Huntley about reinventing the way developers work using Gitpod and GitHub Codespaces. Links: Gitpod GitHub Codespaces GitHub's Engineering Team has moved to Codespaces

Notícias que chamaram a nossa atenção nesta quinta-feira dia 12 de Agosto de 2021! Reprodução em áudio do e-mail recebido diariamente pela Newsletters (newsletter@filipedeschamps.com)

Guest Geoffrey Huntley Panelists Eric Berry | Richard Littauer Show Notes Hello and welcome to Sustain! The podcast where we talk about sustaining open source for the long haul. We are super excited to be going “down under” with our guest today, Geoff Huntley, who works at Gitpod as part of a team that focuses on community and he works with the engineering team. He is also a long-time open source developer advocate, and general coder dude from Australia. We learn from Geoff how he got started in coding, how he loves to teach people coming into the field, and the importance of turning up, sticking around, and helping out in this industry. He tells us all about Gitpod, what he does there, why more people are adopting it, what beer money does for maintainers, and how he's using Gitpod to try to solve the problem of maintainers sustainability. Also, Geoff shares some awesome advice to help the sustainers out there, and his advice on how to use money, which you really need to hear! Download this episode now to find out much more from Geoff #vanlife! [00:01:45] Geoff tells us about the van he lives in and the project he maintains called ReactiveUI. [00:02:50] We learn how Geoff got started with coding and how he ended up willing to take over an open source project that takes a lot of maintenance. [00:06:00] Richard asks Geoff to talk about the amount of maintainers out there and any opinions he has about the engineering code versus the maintainer parable he just mentioned. [00:08:49] We learn more about Gitpod from Geoff. [00:10:49] Eric asks why people are adopting Gitpod, what makes that different between that and Codespaces, and Geoff tells us what the response has been so far. [00:14:40] Geoff talks about how he's using Gitpod to try to solve this problem of maintainers sustainability, and how it goes back to Nadia Eghbal with her Roads and Bridges and the pivotal work she did with the Ford Foundation. [00:17:43] Eric wonders what Geoff thinks that beer money does for the maintainers, and when he was talking to the guys, what kind of response was he getting. [00:21:18] Geoff tells us how many people were involved in the distribution and if he was able to bring in more community members to help decide where those funds were allocated. [00:23:13] We find out the background of the team at Gitpod, and what Geoff does there. [00:25:12] Richard wonders how Geoff is structuring partnerships and how is he making it easier for developers to know about the whole suite of tools that are at their disposal to try and get not just beer money, but sticker money, backer money, and eventually, hopefully things like UBI coming out of code. [00:26:46] Geoff shares his knowledge to the sustainers out there and that can help others. [00:33:00] Eric and Richard share their thoughts on what the next five years is going to be. [00:39:24] Geoff leaves us with a final thought on, “How to use money?” We also find out where you can find him online. Quotes [00:03:27] “Well, it was for personal development and learning. I found at the company I didn't really have a mentor as such, and I found in open source there is an unlimited supply of learning if you just turn up and say, “How can I help?” [00:04:12] “No other industry has that opportunity if you just do the one simple thing of just turning up, sticking around, and helping out.” [00:04:36] “So these are common problems in open source. We have a lot of focus on the code, but there's so many different ways people can contribute to open source even if you still don't understand the code base.” [00:07:22] “So, one thing to always remember is problems can be fixed, we'll pull requests. Open source software is as is.” [00:16:03] “Now, one of the things we've found in that is it's still too hard to give projects money.” [00:18:56] “People are very excited just to even know that you're using their software and how it's getting value.” [00:39:31] “I suppose I'd leave to everyone to think about when you do have money and beer money is coming in, consider maybe not paying your developers.” [00:40:12] “So, use your funds to bring yourself joy. Think about all the things you do as an open source maintainer and the things that don't bring you joy, that's what the funds should be used to do.” Spotlight [00:42:22] Eric's spotlights are github1s and GitHub Web IDE. [00:43:31] Richard's spotlight is the Vermont Commission on Native American Affairs. [00:44:30] Geoff's spotlight is the open source project pre-commit. Links Geoffrey Huntley Twitter (https://twitter.com/geoffreyhuntley) Geoffrey Huntley Linkedin (https://www.linkedin.com/in/geoffreyhuntley) Geoffrey Huntley Website (https://ghuntley.com/) Gitpod (https://www.gitpod.io/) Iron Ring (https://en.wikipedia.org/wiki/Iron_Ring) Open Source Maintainers on GitHub (https://github.com/maintainers) GitHub-open source (https://github.com/open-source) Geoff Huntley's personal monorepo-GitHub (https://github.com/ghuntley/ghuntley) Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure by Nadia Eghbal (Ford Foundation) (https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/) DevX Conf (https://devxconf.org/opensource) “DevX Conf wrap & distributing $10k of open-source funding” by Geoffrey Huntley and Christin Frohne (https://www.gitpod.io/blog/devxconf-wrap) Gitpod chat (https://gitpod.io/chat) Geoff Huntley Gitpod chat (https://discord.com/invite/ZZ8wxgHtc6) “Gitpod Open-Source Sustainability Fund” by Geoffrey Huntley (https://www.gitpod.io/blog/gitpod-open-source-sustainability-fund/) github1s (https://github.com/conwnet/github1s) GitHub Web IDE (https://github.com/zvizvi/Github-Web-IDE) Vermont Commission on Native American Affairs (https://vcnaa.vermont.gov/) pre-commit (https://github.com/pre-commit/pre-commit) Russell Keith-Magee-“If you're relying on open-source software for your business”-YouTube (https://www.youtube.com/watch?v=0t85TyH-h04) Sustain Podcast-Episode 50-Gitcoin, Quadratic Funding, and how Crypto can sustain Open Source with Kevin Owocki (https://podcast.sustainoss.org/50) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr at Peachtree Sound (https://www.peachtreesound.com/) Special Guest: Geoffrey Huntley.

https://themummichogblog.com/utilizzando-visual-studio-net-codespaces-con-core12-06-2020/ Utilizzando Visual Studio .NET Codespaces con core Avatar Tim 21 maggio 2020 Che un tempo per essere uno sviluppatore .NET! Un sacco di grandi annunci a costruire, nuove release per .NET core e nuovi progetti di anteprima per il cloud make lo sviluppo nativo mi ha emozionato di essere uno sviluppatore .NET!

Links: Github main site: https://github.com/ The Open Guide to Amazon Web Services:https://github.com/QuinnyPig/og-aws Slackhatesthe.cloud: slackhatesthe.cloud Global Diversity CFP Day: https://www.globaldiversitycfpday.com/ Twitter: https://twitter.com/deniseyu21 Personal site: deniseyu.io TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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 Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.Corey: This episode is sponsored in part by VM Ware. Because lets face it, the past year hasn’t been kind to our AWS bills or, honestly, any cloud bills. The pandemic had a bunch of impacts. It forced us to move workloads to the cloud sooner than we would otherwise. We saw strange patterns such as user traffic drops off but infrastructure spend doesn't. What do you do about it? Well, the CloudLive 2021 Virtual Conference is your chance to connect with people wrestling with the same type of thing. Be they practitioners, vendors in the space, leaders of thought—ahem, ahem. And get some behind the scenes look into the various ways different companies are handling this. Hosted by Cloudhealth by VM Ware on May 20th the CloudLive 2021 Conference will be 100% virtual and 100% free to attend. So you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Vist cloudlive.com/corey to learn more and save your virtual seat today. Thats cloud l-i-v-e.com/corey c-o-r-e-y. Drop the “e,” we’re all in trouble. My thanks for VM Ware for sponsoring this ridiculous episode.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Denise Yu, who's a senior software engineer at a company that mispronounces itself as GitHub, but it's actually pronounced Jif-ub. Denise, welcome to the show.Denise: Thanks so much for having me, Corey. I am excited to scream in some clouds with you.Corey: Yes, and I do want to point out that Jif-ub is not accepted by the Jif-ub marketing team, and they're upset. But that's the nice thing about this being my show; they don't get to dictate the nonsense that I say. But this is not you endorsing my correct pronunciation, as an employee, in any way. Because that's not your role. You're a senior software engineer. What do you do?Denise: So, I work on a bunch of different things. I actually originally joined GitHub back in March at the beginning of this global pandemic that we're still living through, somehow, in the year 2021. But I joined a year ago to work on a team called ‘Community and Safety.’ That team has been rolled into other teams by this point, partly because the original team did too good of a job at creating abuse prevention tools for the platform. But these days, I still work on community-facing tools, which is very exciting. I'm actually in a department called Communities. And our whole charter is to build tools that make life better for open-source maintainers. So that's a mission that I'm actually really excited about. I think [laugh] of all the products that I've worked on, this is one of the few that I can say I actually really want to make life better for the end-users. [laugh].Corey: Oh, absolutely. For better or worse, GitHub—or Jif-up—has taken a central role in the open-source community. And on some level, I find it—how do I frame this—kind of weird in that we've taken this protocol that is widely decentralized, and that's its entire point. Well, what do we do about this? Oh, immediately, we're going to re-centralize it. That's the right answer. And it just never ceases to amuse me that that's what we have taken from it as a society. But it works. I can't argue otherwise. And I maintain—and this is a bet that I am definitely going to the wall with—that in five years or so we are going to look back at Microsoft acquiring GitHub as a transitional moment.Denise: Yeah, I think so. I think even though the Git technology is built for resilience and distributed work, I think what GitHub as a platform has shown that the process of building software is more than just pushing lines of code. The code is the artifact of collaboration, but we still need a place to do that collaboration, which is why—I’ve been using GitHub for five or six years now, and I only realized a few years ago that things like pull requests and issues don't exist outside of GitHub. That's an abstraction that's so, so deeply baked into my idea of what it means to work collaboratively. That didn't exist until GitHub invented it, which is pretty wild.Corey: Yeah, it's bizarre in a number of different levels. But so much of what we think is part of Git is not. It is the GitHub abstraction, but it's also something that is widely copied by all of GitHub’s competitors, in many respects. So, the line has gotten very, very blurry. And how people come to Git is also fascinating. I used to go to a Git training, I think in 2009, conducted by a GitHub employee—I may be misremembering the year by a few years in either direction—and it was a multi-day process, and it was complex, and I left it feeling in many ways that I had more questions than I answered. Now, I point people to a GitHub page that talks about how to use Git, and they're mostly there. So, it isn't that Git necessarily has improved as a product, it's that GitHub has made it far more accessible. And let's face it, after a few million times practicing, you get very good at explaining complicated things in simple ways.Denise: Oh, yeah. For sure. It's not a huge surprise that internally, we use GitHub for everything. So, if you want to, I don't know, collaborate on writing a—even a new blog post, new marketing copy, or new documentation, all of that happens through GitHub. And I think that people with different levels of proficiency with command line—actually these days, you don't even need command line. You do everything through the UI, which I think is pretty neat.Corey: Oh, it's phenomenal. And I do want to call out that I am the maintainer of an open-source project on GitHub. We know it's good because it has [28.3000 00:06:18] stars; at the time of this recording, almost 3000 forks. And what it is, is the “Open Guide to AWS” it's a big markdown document that more or less explains what all of the AWS services do. There are over 200 contributors, we have an online Slack community at slackhatesthe.cloud because they don't like open-source community stuff very well, and we make fun of them for it. But my point being is that even without knowing how to write a single line of code, this is more or less just a big readme that explains different aspects of what AWS is because it's incredibly hard to adjust to that. And that is every bit as much an open-source project as anything that's included in NPM, or any command line tool that you'll use in any aspect of your job.Denise: Yeah, exactly. And I think the nice thing about editing a document like an AWS Guide, or anything else, really. A couple years ago, I would have said, “Okay, that sounds like it should be a wiki page.” Wiki pages support revisions, collaboration—or maybe a Google Doc or something. But the nice thing about putting it somewhere like GitHub, is like, well, you're already—probably all your other tools already integrate into GitHub. Like, you maybe get Slack notifications, when you have a PR requires review, or whatever it is. It's just so much easier to have everything in one place. And you also get the cool green squares for contributing. [laugh].Corey: Oh, of course, the most important thing is fill that thing up. It’s—talking about gamification causing weird behavior patterns. Yeah, we have a GitHub workflow on this, that fires off on every pull request that looks at the entire site, and validates the thousand and some odd links are still resolving and valid because when you link to this many different sites across the internet, link rot’s a real thing, and it's depressing and sad to be able to look at this and, “Oh, that didn't work.” Now, we do have to fix some of this because it winds up, in some cases, flagging people's submitted pull requests as not being valid, but it has nothing to do with what they're submitting because I'm bad at this. But the fact that that's built in and is available for use is incredible. Every time I look at GitHub’s site, it's gotten better than the last time I looked at it.Denise: Oh, that's so nice.Corey: Well, can't shake the feeling that at some point, there's going to be at the proper moment, a deploy to Azure button that as soon as someone clicks, whatever they've written is suddenly running in some environment in Azure. Now, if it comes too soon, it's going to be terribly implemented, and no one's going to trust it; if it comes too late, then people will already have solved this problem in different ways, so timing is going to be critical. But that is going to be—well-executed at least—a potential sea change in how people approach Cloud and what the default environment to run something on it.Denise: Wait, have you looked at Codespaces? Or seen the demo around that?Corey: I was hoping you would bring those up. Back in the before times, I would travel kind of a lot. And the only computer I brought with me was my iPad.Denise: Mm-hm. Yeah, a lot of people do this.Corey: Oh, yeah. Trying to get a environment on an iPad, it turns out, it's not terrific. The solution that I fell back to was, well, I've been using VI for 20 years, so I'll just SSH into an instance and call it good. But there were interesting projects of varying degrees of success that would run VS Code in a instance somewhere and then just present its interface as a web page. GitHub has actually integrated this as a core offering: all right, you click a button, it spins it up, and it's there. Denise: Yep.Corey: And oh, my God, is that better.Denise: Yeah. I think it's still in limited beta. So, I think you still have to request access to it—I don't know if this will still be the case in March, but yeah, I've tried it out a couple of times, and it works really, really well. My only gripe is that I don't like to use VS Code, so I'm going to have to learn VS Code in order to use it.Corey: I've got to say that is my single biggest barrier to adoption. I already know how to use VI, but a lot of the VS Code stuff, of you having a full featured IDE that does all of these things, is extraordinarily heavy of a lift for me. It more or less is breaking 20 years of muscle memory.Denise: Yeah. Tons of my co-workers love VS Code and use it every day. I only know how to use RubyMine for, [laugh] like, large monolithic Ruby development. And if I'm not doing work on the monolith, I don't want to use an IDE otherwise; I want to just use VI. I'm working in a small enough codebase where I know the name of every file, then I don't want to use the IDE for it. The VS Code to me sits in this middle ground that I know I need to learn how to exist in that middle ground, but it requires me going off to the internet and hunting down every single plugin that I need to put onto VS Code to make it feel like RubyMine again. And that's the thing that I don't want to do.Corey: Well, I'll take it a step further, and most of the tutorials I see about how to get up with VS Code as an IDE are JavaScript based—or YavaScript. [unintelligible 00:11:01] pronunciation once again—and my lingua franca is crappy Python. So, whenever I look for, oh, I want a VS Code tutorial for Python, the first eight pages of it are here the different ways you can do virtual environments and dependency management because that is Python. It focuses on that, and it winds up getting hung up on those implementation details before ever getting to, “Here's a reasonable Python project that someone who's not very good at Python can understand, and here's how VS Code can add value to it.” I mean, those posts exist, but they're hard to find. And it honestly makes me feel like an imposter for not knowing JavaScript.Denise: Yeah, the feature that I use the most in a full IDE like RubyMine is command-click to go to definition. And with Ruby, you get the correct definition about 70 percent of the time, but it's still better than nothing. Because if I'm not doing that, I'm doing a full text search for the method definition, and that's like—my brain can only work with one of those two things. With VS Code, after 15 minutes of trying to find the right plug-in that does click to go to definition and failing, I was just like, this is just not worth it. Nobody should have to live through this much pain. [laugh]. I don't want to do this anymore. [laugh].Corey: Exactly. It becomes this situation where at least when you're starting to learn something, it's breaking everything you're used to, and it feels like instead of helping you, you're fighting with it.Denise: Yeah, this reminds me of how people talk about switching their keyboard layout to Dvorak, or whatever—Corey: Oh, my God. I want to do that on one hand because I'm deep into the mechanical keyboard space. But on the other is, I don't really have six months to teach myself to type all over again.Denise: Yeah, that's the thing. It's like, maybe it'll speed up my typing by, like, two percent. But I already type really fast. I think I would have extremely diminishing returns on that. But also, I don't want my brain to just not work for weeks or months. Corey: Oh, it is worse than that because as soon as you leave that and go on to someone else's computer—which admittedly is not nearly as frequent as it used to be when I was in help desk and desktop support—“Oh, can you type in your password on this thing?” “Absolutely not. Thank you for asking.” It's effectively having to go back and restart it over. I understand that it's more efficient, but you need a societal shift to it, not individuals doing it piecemeal.Denise: Yeah, that's true.Corey: So you're relatively recent, as far as hires over a Jif-ub. You joined mid-pandemic, or early pandemic, depending on how you want to slice that, and you've never been to their headquarters. What is that like?Denise: Everyone keeps telling me how awesome HQ is like, and I’m like, “Cool.” I actually have a brick wall in my office that looks like some of the spaces in HQ, I guess, so people get super confused when I tell them that I'm in Toronto. Corey: Oh, yeah, I've been to HQ a bunch of times for various things. It's great. You’ve really—Denise: Yeah.Corey: —got to see it. I'm not helping, am I?Denise: [laugh]. You're really not helping. I really want to go to HQ. I was meant to go to HQ in March. So, my start date was March 13th, or 14th—I can't remember—in 2020. And I was part of the first onboarding class to not get to go out to HQ because that was when the travel restrictions around COVID were finally being implemented. So I'm very sad about that.Corey: I will say that GitHub has the advantage of a lot of other companies in that—to my understanding—they had a remarkably resilient remote culture before this all hit. Is that correct, or am I misremembering my history?Denise: No, you're right. I think the figure was 75 percent of employees don't live within commuting distance to HQ when I first joined.Corey: Well, not with that attitude.Denise: [laugh]. Yeah, that's true. We just got to try harder. But I think that number is a lot higher now because we have been hiring internationally. And we've grown a lot in the last year or so that I've been here. Yeah, so I think we were better equipped than a lot of other companies to go full remote because it basically just was telling that 25 percent of employees, “Don't come into HQ anymore.” And giving people a little bit more office budget, I guess, to get set up fully for full time remote work. There are a lot of challenges though, especially when you join as a remote employee and you've never worked in a fully remote environment before. It took me a really, really long time to get used to the fact that Slack was my portal to everything. Corey: Oh, yeah. Here at the Duckbill Group, we were full remote from the beginning, just because I decided to merge my consultancy with my business partner’s ten days before he moved from across the street to Portland, Oregon. So, we at that point decided, all right, we're full remote. And we've never had a critical mass of staff in one city to the point where they're became a de facto headquarters because as soon as that happens, it changes your culture. Trying to retrofit something like full remote to a company that historically has always been face-to-face, it shatters a lot of the dynamics. So, on some level it was easy for us. On the other, it feels like we're at a bit of a disadvantage in some respects, once things return to normal. But that's a future problem, unfortunately.Denise: Yeah, I think the biggest thing is learning to work asynchronously, which GitHub was already pretty good at. So I'm pretty used to opening a PR on Wednesday evening, for example, and not really expecting to get feedback on and until the next day, Thursday, or even Friday, especially if I needed a feedback from a different team. Actually, that's something that I've learned since joining GitHub; that wasn't something I was used to before because I've only ever worked in co-located environments before. Someone didn't review my PR in time, I would take a Nerf gun and go over to them [laugh] and gently ask them to [laugh] review my PR. But it's been very interesting. So, I also used to work at Pivotal, which I'm sure you've heard rumors about our kind of cultish pairing [laugh] culture. So, my default state of working was to constantly be talking to another human about what I was doing all the time. And so, suddenly joining a fully remote company in a time when we have to work a little bit more asynchronously than before because people's lives are just completely upended by this pandemic, that was a big adjustment.Corey: So, in the before time, something else that you were effectively renowned for was not only giving conference talks yourself, but helping other people give conference talks, too. Let's talk a little bit about that because speaking at conferences was always one of my passion projects because I love the sound of my own voice, simply love it. And helping other people do that, too, was also something I was very interested in doing, but it was always hard for me to get traction around getting people to let me help them for reasons that are probably blindingly obvious to everyone except me. So, tell me about that. What's the story?Denise: Yeah, so I have always been pretty comfortable speaking in public. I think it's something that I almost took for granted. And the reason for that is because I spent upwards of 10 years of my teenage and adult years doing competitive debate. It was traveling to debate tournaments pretty much every single weekend in college and spent a lot of time doing both structured and off-the-cuff speaking in front of large groups of people. And when I got into tech, it took me a long time to realize that not everyone is like me. I kind of had this special strand, I guess of imposter syndrome, where I think that if I know how to do a thing, then everybody else knows how to do that thing also. Which is aggressively not a correct assumption to make, ever. Corey: Oh, same here across the board. It's one of those I thought for a while I fit in tech because the stereotypes seem to fit me super well. It's like, yeah, “We're bad with people.” “Absolutely.” “We prefer dealing with computers to humans.” “Absolutely.” “I hate my boss.” “Absolutely.” “I'm good at programming…” “Oh… okay, never mind.” But yeah, there's a lot that I think people miss about what it takes to give a good talk. It's not technical mastery. It is an ability to tell a story.Denise: Exactly. I think you hit the nail on the head there. And so after I realized that, okay, I am, at least at the median. I actually think I'm quite good at public speaking and telling stories about technical subject matter, and breaking things down in a way that someone without as much technical context as me can understand it. The thing that got me into doing more and more public speaking, specifically at tech conferences was, after I gave my first talk, people just kept coming up to me, basically, and being like, “Hey, I saw you talk to this conference. Do you want to come talk at this other conference that I'm running?” or whatever. I think like, once you've got a couple of larger stage conference talks under your belt, you almost don't really have to look for speaking opportunities anymore.Corey: No, they fall into your lap. And then you have different problems such as, oh, I've been invited to speak at this conference. Let me do some checking to figure out are they a trash fire, or are they a reasonable place?Denise: Yeah. Am I going to be the only not white guy speaking at this conference?Corey: Am I going to be on a manel? I won't do it. Is there not a code of conduct that has actual teeth and doesn't read as a joke? I won't do it. And that stuff is way more important to me than the technical content of the talk.Denise: For sure. For sure.Corey: But tying it back to even the stuff that GitHub does, one of the talks that was transformative for how I approach this was a Git talk, “Terrible Ideas in Git.” And I like to teach people things by counterexample, and the first iteration of that talk would have been great if the Git maintainers themselves had been the target audience for this, but two people would have loved that and the rest of the audience would have been looking at this with what the hell are you talking about? So, I had to refactor it, and it made it a far stronger talk all the way to the point where there's jokes for everyone in there. But my favorite time giving the talk, I said that, “I now need to be able to explain Git in such a way that my mother would understand it. And that is a problematic way of framing on ageism and sexism basis in most cases, but not this time because she's sitting in the front row. Hi, mom.” That was one of my favorite speaker moments that was just, it's hard to get that one pulled off, mostly because getting my mother to fly to various parts of the world and watch me speak is a bit of a heavier lift than one expected. But here we are.Denise: Yeah, I use a similar litmus test for my stepdad. My stepdad is not a technologist. He is a biologist by training, actually. But he asks me a lot of questions about what I do. And back when I worked at Pivotal, I had to explain cloud virtualization to him every time I went home. [laugh]. I don't know if it's gotten easier. With GitHub, I feel like GitHub is a little bit easier to explain to the average person than Cloud Foundry. But my bar kind of is, every time I put together a talk, do I think that my stepfather could understand the content.Corey: This episode is sponsored in part by our friends at New Relic. If you’re like most environments, you probably have an incredibly complicated architecture, which means that monitoring it is going to take a dozen different tools. And then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They’ve designed everything you need in one platform with pricing that’s simple and straightforward, and that means no more counting hosts. You also can get one user and a hundred gigabytes a month, totally free. To learn more, visit newrelic.com. Observability made simple.Corey: Increasingly, I found the best way to explain GitHub to folks who aren't familiar with it and are non-technical but work in the business space has been, “You know how Microsoft Word has track changes? Yeah, imagine that only without the copy-of-copy-of-file-final-use-this-one-date.bak.PDF.doc? Yeah, imagine that. Instead, this makes this streamlined and easy for multiple people to work on at the same time,” at which point they stare at you hungrily and say, “Oh, my God, how can I use this for my work?” And I feel like there's a breakout moment waiting for GitHub if they ever decide to focus on that part of the market because my God, is there an appetite for it?Denise: Yeah, I think like that kind of revision driven editing, I think that's applicable to so many different domains. I've heard people experimenting with the idea for—I think, Figma does something similar for designs for visuals, but I've also heard the idea floated of this being done for, like, sound mixing, sound engineering, which I think would be super, super cool. I don't know how you could visualize that, but someone who has more knowledge of that space, I'm sure could come up with a way.Corey: Oh, yeah, the challenge I find with stuff like that, for podcasts, for example, is GitHub gets very, very angry because Git gets very, very angry when you start doing things like checking in large uncompressed media files, and then making small changes to them, but you can't diff that so every revision for video work is, “Oh, here's another 150 gig file to put up,” and that becomes a problem.Denise: Yeah.Corey: Yeah, there's a lot that's neat out there. I also want to credit GitHub with fixing the state of working with Git because let's face it, Git makes everyone feel stupid at some point. The question is, is just how far along are you before that hits? And invariably, the approach was always, when you get into that territory, you wind up asking the question on some forum somewhere, and then you wind up getting a few minutes later, this giant essay where it starts out, “Well, Git is not really a version tracker, it's instead of distributed graph that”—and then you just skip down eight paragraph to the bottom where they give you the one-liner that fixes the problem. GitHub has fixed the result of queries for, “How do I X in Git?” And just gives you the answer outright. It's transformative, and it's one of the things that everyone takes for granted because no one really stops to think this documentation is awesome, and accessible, and answers my problem, but the result of it is, is that you just don't see people complaining about how hard Git is anymore.Denise: Yeah, yeah. Oh, my God, Git is so hard. I think the first-time I correctly did an interactive rebase—like, I typed all the arguments correctly. I think I just got up and did a lap around the office. [laugh]. There's just all this random stuff that you have to remember when you're using—especially some people use the desktop GUIs or whatever. I always just use command line. But it took forever and I still make a ton of mistakes with it.Corey: Oh, we all do. That's the beautiful part of it. The nice thing is, “Oh, well the nice thing about Git is that nothing ever really gets truly lost.” And you say, “Well, how do you figure?” “Oh, I copy the entire directory to a backup before I do anything.” Which is on the one hand, awful version control and, two, has saved my bacon multiple times. So, if it's stupid and it works, it's not really stupid, now is it?Denise: It's not stupid if it works. [laugh].Corey: So, a passion project of yours that I want to talk about has been teaching people to submit to conferences, to give talks at conferences, to convince them that yes, you can do this and you're good at it, you have a story that people want to tell, the things you find easy are not easy for everyone. ‘Give that story voice’ has been a recurring theme that you do. How has that manifested during this year of isolation?Denise: Ohh. This year’s definitely been tough. So, usually when I do that pitch, I run workshops specifically around a certain CFP. Like I help out conference organizers in the Toronto area. Like, I did a workshop for devopsdays last year, and another one for GoCon, also meant to be last year. And usually it's like, okay, here's how you write a strong proposal—and I'll have the committee in the room—and be like, here's what the committee is looking for; ask these people questions about what they would choose to program. And this is how you get your talk submitted. This is how you get accepted; you need to understand who your audience is. It's a product question. It's exactly the same mindset that you need to get into when you're playing product manager, or if you're actually a product manager. You need to understand who your target customer or audience is, what they're looking for, and how do you give that to them on a plate. This year, it's slowed down a lot, obviously because there have been fewer conferences, so I've just had fewer opportunities to do this kind of pitch without—it feels weird telling people to write talks without there being a place to submit a talk to. But I think—I found that there still is room for content creation, even if that isn't a conference talk. So, within the company, within my networks, I do try to encourage people to write blog posts. Err on the side of writing what you've learned; if you spent a couple days doing a technical investigation and you found it interesting, write it down so other people can learn about it. On the conference talk front, I think the unique benefit of doing conference talks and getting up on stage is you do build a personal brand. After a little while that kind of transcends the company that you're at, granted that you're not talking about your company's products in every single talk. Corey: Absolutely. And a lot of companies get profoundly insecure about that. And I'm sorry; they're wrong. That is not a bad thing. Anyone who gives a talk for your company will eventually become better known than your brand for some aspects and in some areas—harder at places like GitHub than it is Twitter for Pets, but that's okay—and you have to be okay with that and have a plan for how you're going to transition them out when they outgrow the role and move somewhere else. But that's okay. And companies that are insecure about that drive me up a wall.Denise: Yeah, there have been a few times when I went to very cloud specific conferences and talked about things that my company is working for, but other times, I've gone to just very general conferences where it was just like, let's talk about Agile, or let's talk about software, like super, super generally. And the ones who have gone to the really general conferences and talk about things that matter to me—like cross-functional collaboration, or test driven development, or whatever it is—those are the ones that I've actually managed to get people to apply to my company without even saying that we're hiring. It's a little mind blowing.Corey: It is. People want to work with interesting people, and when you find someone who's able to tell a story that touches you on some level, which is the point of telling stories, then at some point, the idea of I'd like to work with that person on ongoing basis becomes actively compelling. People ask so well, it's not like you could hire a whole lot of people who do what you do, so hiring and recruiting is going to be a problem. It's like, well, it is but it's because it's finding the right people with the right alignment, but we have an awful lot of candidates to choose from for basically any role, just because for better or worse, I make a splash.Denise: Yeah, exactly.Corey: So, as people are looking to get into the space and they're new to speaking, how do you get them to a point where there's at least a certain level of confidence? I would say, “How do you get them to not be terrified?” But I’ve been speaking almost full time for years, and I'm still scared to death every time I give a talk when I start out.Denise: Me too. I'm still terrified. I almost switch into a different persona when I go on stage, and I don't remember anything that happens. I don't know what—maybe there's psychology [laugh] around this, but I literally blank out the 40 minutes that I'm on stage. So, the most common objection that I hear about why someone doesn't want to give a talk is they'll say, “But everybody already knows about this. The thing that I want to talk about has already been talked about. There's already too much content out there. I wouldn't add anything new.” And for a long time, my response to that was just, I don't care. I still want to hear what you have to say, you're going to offer a fresh perspective, you're going to offer a new experience, you're going to explain something in a way that clicks for someone. Your explanation might be the one that works for them that they haven't been able to figure out by listening to anybody else. So, I historically said those things, and I still one hundred percent those things, and I still say those things to people but I actually came across something interesting on Twitter today. Someone was actually talking about fanfiction. I don't know if you’ve written or read fanfiction in the past. When I was a kid I used to—Corey: I can neither confirm nor deny…Denise: [laugh]. There’s varying levels of fanfiction out there. But fanfiction communities are actually incredibly collaborative places. I remember being, I don't know, like a 10 or 11-year-old and writing a lot of anime fanfiction, basically just writing myself into the Pokemon universe and things like that. And we would post these on forums. It'd be forums of strangers working together, and we’d post drafts. And then we would give each other feedback on those drafts. And in the end, there'd be 60 different pieces of fanfiction, roughly about the same universe, every story is a little bit different, and nobody was ever self-conscious that this had already been done. Because the whole point of fanfiction is that there's a lot of it, the value of the community is in the fact that the content is abundant. Not that every single piece of content is unique. So, I think a similar thing is true for content that's technical storytelling. Just because someone else has said this thing before, it doesn't matter. The fact that there's more content out there about this thing is good for the community, building a community around this thing. So, I don't know, that was something that just resonated with me a lot, and I just really liked that framing.Corey: We have this weird perspective that the things that we know are easy, the things we don't know are hard, so once you've learned how to do something, everyone else knows it. I mean, one of my most popular Twitter threads that exploded that I didn't see coming was just me talking about random things that live in my shell config file, and what they do. It's, “Well, this is stuff everyone knows, and everyone has something like this, right?” And it got into a dissection of what these things do, and how it works, and of course, it's snarky because that's my excuse for a personality, but it also shined a light on something that I forgot, once again: not everyone knows this. A lot of the viral tweets you see going around are people noticing something that we've all seen and been ignoring because that's just the way it is, and someone makes an observation about it and, oh, yeah, that's right. That is something that everyone can relate to.Denise: Yeah. Corey: People want stories.Denise: Yeah, exactly. I think about every six months, I try to retweet—every review cycle around mid-year, end-of-year. It’s like, “Hey, just a reminder, if someone on your team has done something for you write this down. Catalog what they did, write it down, send it to them, send it to their manager, put it into their file so they can use it at review time.” And every time I talk about this, I always get a ton of engagement. And I have to remind myself that this is not obvious. Even if someone was told to do this at some point in the past, reminding people to be deliberate and be active about giving each other peer feedback, writing stuff down. You just can't remind people to do that enough, I think.Corey: Yeah, it's one of those things where, “Well, I've already given that talk, so I have to give a different one.” No, you don't, I promise you, you have not given your talk to everyone in the industry, and the reason I know that is because by that point, you would see the view count on YouTube or whatnot—or the video winds up—and be flabbergasted because the industry is bigger than anyone thinks. I feel like I tell the same joke from time to time, but they always get laughs from the audience because it's new to them. My business partner and my romantic partner find it incredibly challenging, both—those are two people, incidentally—they find it incredibly irritating because, “Yes, yes, we've heard that one.” And every once a while they sit up, “Oh, Corey got a new joke.” But the rest of the world doesn't respond that way.Denise: Yeah, exactly. So, I don't know if we've talked about this already, but that closes the loop on the whole imposter syndrome piece where—just because I think one strain of imposter syndrome is telling yourself, just because I know this thing, means everybody else must also know it. I must be the last person in the world to learn this piece of information.Corey: There is no piece of technology, or anything even tangentially related to technology, that you couldn't do a tweet thread on and people would learn things about it. How an if-then-else loop works, for example. That is—sorry—ahh—do you see what I'm talking about? That's exactly what I mean. See, I meant to say ‘Conditional,’ and instead I said ‘Loop’ and we all trip over these things; they're all challenging, and the fact that we can still learn new things about that of, how does a flow control conditional actually work? What does that mean? Sure, anyone who spends their days writing code all the time is going to have some topical understanding of it, but not everyone's going to, first, be that person, or secondly, understand why that's valuable and relevant. You could do an entire conference talk on nothing more than that concept alone and it would be a dynamite talk.Denise: Yeah, exactly. I did go through a wave of imposter syndrome around last year, or maybe—uh, I don't even know what year is it. [laugh]. A little while back, I was feeling uncertain about this talk about distributed systems that I've done a few times. And then I got a random message on Twitter from a student who told me that she had just gotten her first engineering role out of university—ever, ever—and she said, I watched your talk on distributed systems; you gave me the vocabulary to talk about this stuff in an intelligent way, and I've landed my first role as an entry level—I forget exactly what kind of engineer but—I mean software engineering—but I forget if it was like infrastructure, or app dev, I don't know. But it was like, that kind of feedback, just—that's really cool to hear.Corey: I'm going to take it a step further and request anyone listening to this who’s seen the talk that has potentially changed the way they view things or helped them advance in their career, track down whoever gave that talk and send them a message. One of the hardest parts about being a speaker is that you very rarely get feedback. I mean, even on this podcast, I almost never get direct feedback online. People talk to me about it in person, when they run into me at a conference, in the before times. But it's not a thing where people wind up drafting an email, “Dear sir, I found your podcast to be compelling, and also you are a jackass.” I would love letters like that.Denise: Well, I don't love letters like that, so please don't write me letters like that. [laugh].Corey: Well, in my case, they're well-deserved. In your case, it would just be offensive.Denise: [laugh]. But yeah, reach out to those strangers whose content you've learned from, I think it can actually make someone's day.Corey: Absolutely. So, on the other side of that, if someone's listening to this, and they want to start giving a talk, but they don't know where to start, how to build a CFP, where to begin, where should they start? What is the next step for those people?Denise: So there's an initiative that I, in the before times, mentored and helped organize local chapters for. It's called Global Diversity CFP—it's either Global CFP Diversity or Global Diversity CFP, I always forget—day. And even if you're not a person who has a marginalized identity, they've done a really, really great job of consolidating a bunch of resources to get first-time speakers off the ground.Corey: And we will put a link to that in the [show notes 00:36:34], of course.Denise: Cool. So, I recommend reading through what they have. So it's actually an event that take place on a full day; it's a little bit different this year, I think they might be running it remotely this year. But all of their content is geared for first-time speakers, and they have a lot of material that's pepping people up to take the first step. But I would say that beyond that, the best way to get started, honestly, is to just pick a topic that you care about, and just try to write a talk. And if you don't have a place to deliver that talk—if there's no meetup, or conference or anything coming up, you should just record yourself giving the talk to your computer, actually. This is the thing that my debate coach used to have us do in college: the best way to improve as a speaker is to record yourself speaking and watch it. It's going to be terrible the first few times because you're going to be like, “Oh, God. I look so awkward.”Corey: Power through it. I still can't watch myself speak.Denise: [laugh]. Like, what are my hands doing? But you can only catch those things and improve at them once you're aware that you're doing them. So, that is the fastest way to improve your presence and your speaking ability.Corey: Yeah. I want to thank you for taking the time to speak with me and go through all these various topics today. If people want to learn more about you, where can they find you?Denise: So, you can find me on the internet on the cursed blue website at @deniseyu21 is my handle on Twitter. My personal website is deniseyu.io because—I used to have .com but some kids stole it and squatted on it after I forgot to renew it. So I'm not deniseyu.com anymore.Corey: Yeah, the joy of changing usernames on different platforms and the rest. I hear you.Denise: Yeah. Yeah, probably those two places. If you want to talk about anything that I talked about on the podcast, feel free to DM me on Twitter. Please don't send me mean feedback that starts with “Dear sir,” in my Twitter DMs, but other than that, I—Corey: Generally never a good plan for anyone.Denise: [laugh]. No. Corey: Thanks so much for taking the time to speak with me. I really appreciate it.Denise: Yeah. Thanks so much, Corey for having me on. It was a lot of fun. I feel like we covered a lot of ground. Probably too much. [laugh].Corey: It really was. And we did. Denise Yu, senior software engineer at Jif-ub. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with a comment containing a correctly formatted Git rebase command.Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey atscreaminginthecloud.com, or wherever fine snark is sold.This has been a HumblePod production. Stay humble.

Jonathan Carter (a.k.a. LostInTangent) is the principal program manager at Microsoft for VS Code Liveshare, GitHub Codespaces, and IntelliCode. We talk about how Liveshare is opening up new possibilities in pair programming, how Codespaces aims to reduce a key source of developer friction, and how he and his team want to enable more developers to say "yes" to the question, "Why not now?" Jonathan also talks about building dev tools in his spare time, including his latest project, Code Tour, a VS Code extension that lets you create guided tours through your codebase.Show notes and transcript: https://about.sourcegraph.com/podcast/jonathan-carter/

Nous accueillons dans ce podcast : Bassem ASSEH (GitHub | Regional Vice President | EMEA Enterprise solutions).  Nous revenons avec Bassem sur les dernières annonces produits : Codespaces, Discussions, Teacher Toolbox et Classroom.Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

 Los doctores japoneses se hartan del Fax. El sistema de mensajería analógico sigue siendo muy popular en Japón, pero es tedioso y les impide trabajar a la velocidad necesaria para tratar la emergencia creciente del coronavirus en el país.  Muchas medidas burocráticas y corporativas siguen requiriendo un papel escrito a mano y luego enviado por fax o correo postal. No valen medidas digitales.  Xiaomi actualiza sus navegadores para dejar de recopilar información sensible. Expertos en seguridad demostraron hace unos días que sus navegadores (Mi Browser y Mint) enviaban información anónima pero identificable incluso en modo incógnito.  La compañía primero lo negó, pero luego reconoció que no estaba bien implementado y acabó actualizando.  ¿Telemetría o espionaje? Todas las empresas recopilan información de navegación, incluso Safari o Firefox, para añadir funciones o mejoras. Pero qué envían, qué cortan y cómo lo envían es la clave.  Microsoft lanza dos nuevos portátiles Surface. Una nueva y mejorada versión con el Surface Book 3 (1.800 euros) (de 13 y 15″), y una Surface Go 2 (500 euros) que viene con bordes más reducidos, procesador Intel gama baja algo más rápido y opción 4G.  También nuevos auriculares de diadema, Surface Headphones 2 (280 euros), y de botón, Surface Earbuds (220 euros). Ambos con cancelación de ruido.  Black Shark 3 es un móvil muy feo pero muy recomendable. Con dos versiones, una básica a 600 euros y otra “Pro” a 900 euros. Vienen con posiblemente las specs más altas de un Android. Aun sin saber la calidad de la cámara.  No entiendo una cosa: Black Shark es una compañía “prima” de Xiaomi (invertida, comparten contratos de proveedores) y este Black Shark 3 es casi idéntico al Xiaomi Mi 10 Pro que salió hace unas semanas a 1000 euros.  Xiaomi lidera la venta de móviles en España por primera vez, con un gran crecimiento en el inicio de año, especialmente en los móviles de gama media y baja.  Dueños de casas se rebelan contra Airbnb creando sus plataformas. Descontentos con la gestión reciente de la pandemia, sumada a las quejas sobre las tarifas y reembolsos, fundan sistemas más favorables donde puedan controlar el precio.  Twitter detectará si pones insultos en tus tuits antes de que envíes y te dará un mensaje pidiendo calma. Una forma alternativa para intentar rebajar el nivel de toxicidad en la plataforma. Assorties  Spotify añadirá podcasts en vídeo a su plataforma.  GiHub ha lanzado su propio IDE llamado CodeSpaces, que permite escribir y probar código desde la web, incluso en iPad.  Nintendo se está forrando a vender Switch, que ya supera las ventas totales de Nintendo 64 y Game Cube.  Volvo incorporará los sensores LIDAR directamente en el parabrisas de una forma mucho más discreta.  Apple invierte 10 millones en una firma de diagnósticos de coronavirus para que pueda fabricar más de un millón de kits semanales.  Filmic Pro, la gran aplicación de grabación de vídeo ya está disponible para Android por 13 euros (que no incluye todas las opciones).  El actor Tom Cruise irá a la Estación Espacial Internacional a grabar una película.  La primera beta de Android 11 llegará el 3 de junio, y la versión final para el 8 de septiembre. ¿Quieres colaborar con el programa? Colabora en Patreon Colabora en Ko-Fi (PayPal) ---- Ahora también tenemos un grupo de Telegram para oyentes: https://t.me/joinchat/AF0lVBd8RkeEM4DL-8qYfw ---- Sigue la publicación en: Newsletter diaria: http://newsletter.mixx.io Twitter: http://twitter.com/mixx_io o sigue a Álex directamente en: http://twitter.com/somospostpc Envíame un email: alex@barredo.es Telegram: https://t.me/mixx_io Web: https://mixx.io

話した内容ScrapBox このポッドキャストでは、Kaggleを中心としたデータサイエンスに関連する情報を配信していきます。 今回は、ワンストップ オンライン生活、Kaggleでコピーしたnotebookについて、Codespaces、一人esa、今週のKaggleについて話しています。

About a year ago, Microsoft launched Visual Studio Online, its online code editor based on the popular Visual Studio Code project. It's basically a full code editor and hosted environment that lives in your browser. Today, the company announced that it is changing the name of this service to Visual Studio Codespaces. It's also dropping […]