Podcast appearances and mentions of scott chacon

Version control is a critical part of any modern software project and git is the most popular tool for the job. But it can be complex and confusing, especially for beginners.The team behind GitButler believes there is a better way.They are building a modern Git client that streamlines the process of managing branches, backing up your work, and more. We hear from co-founders Scott Chacon and Kiril Videlov about how they're making Git easier for everyone -- all without sacrificing the power and flexibility that makes Git so popular in the first place.

Scott Chacon writes up his insider take on GitHub's success, Sentry wants other companies to take the Open Source Pledge, Benj Edwards used AI to reproduce his late father's handwriting, Dave Kiss explains the current hype that PHP is getting & Taylor Otwell raises $57 million series A from Accel.

Scott Chacon writes up his insider take on GitHub's success, Sentry wants other companies to take the Open Source Pledge, Benj Edwards used AI to reproduce his late father's handwriting, Dave Kiss explains the current hype that PHP is getting & Taylor Otwell raises $57 million series A from Accel.

Scott Chacon writes up his insider take on GitHub's success, Sentry wants other companies to take the Open Source Pledge, Benj Edwards used AI to reproduce his late father's handwriting, Dave Kiss explains the current hype that PHP is getting & Taylor Otwell raises $57 million series A from Accel.

Vergiss Datenbanken - Benutze mehr Files!Warum denkst du eigentlich, dass du eine Datenbank brauchst?Würde deine Applikationskomplexität nicht deutlich niedriger sein, wenn du alles in einer Datei abspeichern würdest? Hast du wirklich so dynamische Daten? Liest du deine Daten nicht deutlich öfter, als dass du diese schreibst? Und macht die Datenbank deine Applikation nicht langsamer?Mit dieser steilen These kommt Wolfgang um die Ecke. Obwohl dies gegen alles geht, was wir sonst normalerweise so lernen und beigebracht bekommen. Und das von jemandem, der in dem Bereich Datenbanken studiert hat. Darum geht es in dieser Episode.Bonus: 1 Jahr Engineering Kiosk Alps Meetup.**** Diese Episode wird gesponsert von WeAreDevelopers World Congress Nimm am WeAreDevelopers World Congress teil, der weltweit führenden Veranstaltung für Entwickler*innen vom 17. bis 19. Juli 2024 in Berlin. WeAreDevelopers begrüßt 15.000+ Entwickler*innen und 500+ Speaker zu einem unvergesslichen Event in diesem Sommer. Nutze unseren exklusiven Rabattcode "WWC_EngineeringKiosk15" für 15% Rabatt.Zu den Speakern gehören: Scott Hanselman, Scott Farquhar, Douglas Crockford, Thomas Dohmke, Demetris Cheatham, John & Brenda Romero, Prashanth Chandrasekar, Madona Wambua, Jonas Andrulis, Denis Yarats, Scott Chacon und viele mehr!Sichern Sie sich Ihren Platz unter https://worldcongress.dev/ Hier geht es zum Gewinnspiel: https://www.linkedin.com/feed/update/urn:li:share:7211263176640729088/****Das schnelle Feedback zur Episode:

This week we have Scott Chacon, a co founder of GitHub, about his new product GitButler. We talk about the history of GitHub and how GitButler is changing what user centric version control is. We also talk about the future of version control and how AI is changing the way we work. https://scottchacon.com/ https://github.com/schacon https://twitter.com/chacon?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor https://www.linkedin.com/in/schacon/?originalSubdomain=de Episode sponsored By Clerk (https://clerk.com) Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. https://www.patreon.com/devtoolsfm https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 https://www.youtube.com/@devtoolsfm/membership

This week we're talking to Scott Chacon, one of the co-founders of GitHub, to discuss the history and future of Git and Scott's new project Git Butler, a branch manager tool that's aiming to improve the developer experience of Git using Git. We also touch on the contentious topic of open source licensing and the challenges of defining “Open Source”, FSL vs GPL, and more.

This week we're talking to Scott Chacon, one of the co-founders of GitHub, to discuss the history and future of Git and Scott's new project Git Butler, a branch manager tool that's aiming to improve the developer experience of Git using Git. We also touch on the contentious topic of open source licensing and the challenges of defining “Open Source”, FSL vs GPL, and more.

Scott Chachon ist einer der Mitgründer von GitHub, einer Entwicklerplattform, die für ca. 7,5 Milliarden Dollar an Microsoft verkauft wurde.Wir sprechen über den Moment, als er vom Verkauf an Microsoft erfahren hat, wie viel Geld er mit dem Verkauf verdient hat und ob es ihn glücklich gemacht hat.Inzwischen gründet er sein drittes Startup Gitbutler, nachdem er 12 Millionen seines eigenen Geldes in Chatterbug investiert und nun entschlossen hat, die Firma ohne Investment profitabel wachsen zu lassen.Wir sprechen über das Gründen in Deutschland und Europa im Gegensatz zu den USA und Scott erklärt, warum er nun zum zweiten Mal in Deutschland gründet.Was du lernst:Meilenstein Exit: Wie erstrebenswert ist der Exit als Ziel wirklich?Kundenbindung: Wie schwer ist es, Kunden zu binden und welche Möglichkeiten, wie beispielsweise erlebnisorientierte Ansätze, gibt es?Teamzusammensetzung: Was macht ein hoch performantes Team aus?Made in Germany: Welche Aspekte sprechen für und gegen eine Gründung in Deutschland vs. in den USA?Looking for 100.000€ in Cloud Credits, then apply for the OVHcloud Startup Program: https://startup.ovhcloud.comALLES ZU UNICORN BAKERY:https://zez.am/unicornbakery Scott ChaconLinkedIn: https://www.linkedin.com/in/schaconGitbutler: https://gitbutler.com/Merge: https://merge.berlin Unicorn Bakery Whatsapp Broadcast:Hier erfährst du alles, was du als Gründer wissen musst: https://drp.li/jrq5S Unser WhatsApp Broadcast hält dich mit Einblicken in die Szene, News und Top-Inhalten auf dem Laufenden.Marker:(00:00:00) What changes when you finally get the 100 million dollar exit? ?(00:06:20) Did you experience an exit-depression?(00:11:03) 12 million personal investment in Chatterbug?(00:15:04) What is your advice for founders to get to the "zero-to-one-effect"?(00:23:01) Gitbutler: Product & Vision(00:29:04) How did you build your third venture with all your experience?(00:32:55) What does it take to make a developer tool successful?(00:36:11) Was your product ready for a lot of attention when you got thousands of signups?(00:39:03) What do non-technical-founders forget about that makes it harder for tech people to succeed in the company?(00:42:26) Why is building from Germany great in some parts?(00:55:44) Investors vs. Bootstrapping: What are your thoughts?(01:00:14) How did you plan your runway?(01:03:44) The Merge: The developers conference Hosted on Acast. See acast.com/privacy for more information.

Scott Chachon is one of the co-founders of GitHub, a developer platform that was sold to Microsoft for around 7.5 billion dollars. We talk about the moment he found out about the sale to Microsoft, how much money he made from the sale and whether it made him happy. He is now founding his third startup, Gitbutler, after investing 12 million of his own money in Chatterbug and has now decided to grow the company profitably without investment. We talk about founding in Germany and Europe as opposed to the US and Scott explains why he is now founding in Germany for the second time. What you learn: Milestone exit: How desirable is exit as a goal really? Customer retention: How hard is it to retain customers and what options, such as experiential approaches, are there? Team composition: What makes a high-performance team? Made in Germany: What are the pros and cons of setting up in Germany vs. the USA? Looking for 100.000€ in Cloud Credits, then apply for the OVHcloud Startup Program: https://startup.ovhcloud.com EVERYTHING ABOUT UNICORN BAKERY: https://zez.am/unicornbakery      Scott Chacon LinkedIn: https://www.linkedin.com/in/schacon/ Gitbutler: https://gitbutler.com/   Merge: https://merge.berlin  Unicorn Bakery Whatsapp Broadcast: Find out everything you need to know as a founder: https://drp.li/jrq5S        Our WhatsApp Broadcast keeps you up to date with insights into the scene, news and top content. Marker: (00:00:00) What changes when you finally get the 100 million dollar exit? ? (00:06:20) Did you experience an exit-depression? (00:11:03) 12 million personal investment in Chatterbug? (00:15:04) What is your advice for founders to get to the "zero-to-one-effect"? (00:23:01) Gitbutler: Product & Vision (00:29:04) How did you build your third venture with all your experience? (00:32:55) What does it take to make a developer tool successful? (00:36:11) Was your product ready for a lot of attention when you got thousands of signups? (00:39:03) What do non-technical-founders forget about that makes it harder for tech people to succeed in the company? (00:42:26) Why is building from Germany great in some parts? (00:55:44) Investors vs. Bootstrapping: What are your thoughts? (01:00:14) How did you plan your runway? (01:03:44) The Merge: The developers conference

Reimagine version control systems with Scott Chacon, Co-founder of GitHub and GitButler. Because, even Scott, a Git Veteran, will admit it: ``` Git is a pain sometimes.

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.

About KatieKatie Sylor-Miller, Frontend Architect at Etsy, has a passion for design systems, web performance, accessibility, and frontend infrastructure. She co-authored the Design Systems Handbook to spread her love of reusable components to engineers and designers. She's spoken at conferences like Smashing Conf, PerfMatters Conf, JamStack Conf, JSConf US, and FrontendConf.ch (to name a few). Her website ohshitgit.com (and the swear-free version dangitgit.com) has helped millions of people worldwide get out of their Git messes, and has been translated into 23 different languages and counting.Links: Etsy: https://www.etsy.com/ Design Systems Handbook: https://www.designbetter.co/design-systems-handbook Book of staff engineering stories: https://www.amazon.com/dp/B08RMSHYGG staffeng.com: https://staffeng.com ohshitgit.com: https://ohshitgit.com dangitgit.com: https://dangitgit.com 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 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 our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part. Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Katie Sylor-Miller, who is a frontend architect at Etsy. Katie, thank you for joining me.Katie: Hi, Corey. Thanks for having me.Corey: So, I met you a long time ago—before anyone had ever heard of me and the world was happier for it—but since then you've done a lot of things. You're obviously a frontend architect at Etsy. You're a co-author of the Design Systems Handbook, and you were recently interviewed and included Will Larson's book of staff engineering stories that people are mostly familiar with at staffeng.com.Katie: Yeah.Corey: So, you've done a lot of writing; you've done some talking, but let's begin with the time that we met. To my understanding, it's the only time we've ever met in person. And this harkens back to the first half—as I recall—of 2016 at the frontend conference in Zurich.Katie: Yes, before either of us were known for anything. [laugh].Corey: Exactly. And it was, oh, great. And I wound up getting invited to speak at a frontend conference. And my response was, “Uh, okay. Zurich sounds lovely. I'm thrilled to do it. Do you understand who you're asking?”There are frontend folks—which, according to the worst people on the internet is the easiest form of programming; it isn't a real engineering job, and if that's your opinion, please stop listening to anything I do ever again—secondly, then there's the backend folks who write the API side of things and what the deep [unintelligible 00:02:03] and oh, that's the way of the future. And people look at me and they think, “Oh, you're a backend person,” if their frontend. If they're backend, they look at me and think, “Oh, you're a DevOps person.” Great. And if you're on the DevOps space, you look at me and think, “What is wrong with this person?” And that's mostly it.But I was actually invited to speak at a frontend conference. And the reason that they invited me at all—turns out wasn't a mistake—was that I was giving a talk that year called, “Terrible Ideas in Git,” which is the unifying force that ties all of those different specialties together by confusing the living hell out of us.Katie: Yes. [laugh].Corey: So, I gave a talk. I thought it was pretty decent. I've done some Twitter threads on similar themes. You did something actually useful that helps people and is more lasting—and right at that same conference, I believe, you were building slash kicking it off—ohshitgit.com.Katie: Yes. Yeah. It was—Corey: Which is amazing.Katie: Thank you. Yeah, it was shortly thereafter. I think the ideas were kind of starting to percolate at that conference. Because you know—yeah I was—Corey: Because someone gave a talk about Git. Oh, I'm absolutely stealing credit for your work.Katie: No, Corey—Corey: “Oh, yeah. You know, that was my idea.”Katie: [laugh].Corey: Five years from now, I'm going to call myself the founder of it, and you're just on the implementation details.Katie: I don't—nonononono—Corey: That's right. I'm going to D.C. Bro my way through all of this.Katie: [laugh]. No, no, no, no. See, my recollection is that my talk about being a team player and a frontend expert with a T-shape happened at exactly the same time as your talk about Git because I remember I wanted to go watch your talk because at the time, I absolutely hated Git. I was still kind of learning it. So yeah, so I don't think you really get any credit because I have never actually heard that talk that you gave. [laugh].Corey: A likely story.Katie: [laugh]. However, however, I will say—so, before I was up to give my talk, the emcee of the conference was teasing me, you know, in a very good-natured ribbing sort of way, he was teasing me about my blog being totally empty and having absolutely nothing in it. And I got on the plane home from Zurich, and I was starting to think, “Oh, okay. What are some things that I could blog about? What do I have to say that would be at all interesting or new to anyone else?”And like I think a lot of people do, I had a really hard time figuring out, okay, what can I say that's, maybe, different? And, I went back home, I went back to work, and at one point, I had this idea, I had this file that I had been keeping ever since I started learning Git and I call it, like, gitshit.txt. And hopefully, your listeners don't mind lots of swears because I'm probably going to swear quite a bit.Corey: No, no. I do want to point out, you're accessible to all folks: dangitgit.com, also works but doesn't have the internal rhyming mechanism which makes it, obviously, nowhere near where it needs to be.Katie: [laugh]. Well—Corey: It's sort of a Subversion to Git if you will.Katie: Yes, exactly.Corey: I—Subversion fans, don't yell at me.Katie: [laugh]. Anyways, so I remember I tweeted something like, “Oh, what about if I took this text file that I had,” where every time I got into a Git mess, I would go on to Stack Overflow—as you do—and I would Google and I—it was so hard. I couldn't find the words to find the answers to what I was trying to fix. Because one of the big problems with Git that we can talk about it a bit more in detail later is that Git doesn't describe workflows, Git describes internal plumbing commands and everything that it exposes in its API. So, I had a really hard time with it; I had a hard time learning it.And, you know, what I said, “Okay, well, maybe if I published on my blog about these Git tips that I had saved for myself.” And I remember I tweeted, and I got a handful of likes on the tweet, including from Eric Meyer, who is one of my big idols in the frontend world. He's one of the godfathers of modern CSS. And he liked my tweet, and I was like, “Oh, okay. Maybe this is a real thing. Maybe people will actually find this interesting.”And then I had this brilliant idea for this URL, ohshitgit.com, and it was available, and I bought it. And I swear to you, I think I spent two hours writing some HTML around my text file and publishing it up to my server. And I tweeted about it, and then I went to bed.And I kind of expected maybe half a dozen of my coworkers would get a little sensible chuckle out of it, and like, that would be the end of it. But I woke up the next morning and my Twitter had blown up; I was on the front page of Hacker News. I had coworkers pinging me being like, “Oh, my God, Katie, you're on Hacker News. This is insane.” And—Corey: Wait, wait, for a good thing, or the horrifying kind of thing because, Hacker News?Katie: Well, [laugh] as I have discovered with Hacker News, whenever my site ends up on Hacker News, the response is generally, like, a mix of, “Ha ha ha, this is great. This is funny,” and, “Oh, my God, somebody actually doesn't understand Git and needs this. Wow, people are really stupid.” Which I fundamentally disagree with and I'm sure that you fundamentally [laugh] disagree with as well.Corey: Oh, absolutely.Katie: Yeah. So—Corey: It's one of those, “Oh, Git confuses you. You know what that means? It means you're human.” It confuses everyone. The only question is, at what point does it escape your fragile mortal understanding? And if you are listening to this and you don't believe me, great. I'm easy to find, I will absolutely have that discussion with you in public because I promise, one of us is going to learn something.Katie: [laugh]. Awesome. I love—I hope that people take you up on that because—Corey: Oh, that would be an amazing live stream, wouldn't it?Katie: It would. It would because Git is one of those things that I think that people who don't understand it, look at it and think, “Gosh, you know, I must be stupid,” or, “I must not be cut out to be a developer,” or, “I must not know what I'm doing.” And I know that this is how people feel because that's exactly how I felt myself, even when I made ohshitgit.com, that became this big reference that everybody looks at to help them with Git, like, I still didn't understand it. I didn't get Git at all.And since then, I've kind of been forced because people started asking me all these questions, and, “Well, what about this? What about that?” And I was just like, “Uh… I don't know. Uh…” and I didn't like that feeling, so I did what, you know, obviously, anyone would do in my situation and I sent out a proposal to give a talk about Git at a conference. [laugh].And what that did is when my talk got accepted, I had to then go off and actually learn Git and understand how it works so that I could go and teach it to other people at this conference. But it ended up being great, I think because I found a lot of really awesome books. There's A Book Apart book called Git for Humans, which is incredibly good. There's a couple of websites like learngitbranching.com.There's a bunch more that I can't think of off the top of my head. But I went out and I sort of slowly but surely developed this mental model, internally, of how Git works. And I'm a visual thinker and I'm a visual learner, and so it's a very visual model. And for what it's worth, I think that was my biggest problem with Git was, like, I came from Microsoft .NET environment before that, and we used a program called TFS, Team Foundation Server, which is basically like a SVN or a CVS type source control system that was completely integrated into Visual Studio.So, it was completely visual; you could see everything happening in your IDE as you were doing it. And then making this switch to the command line, I just could not figure it out until I had this visual mental model. So yeah, so ever since then I've just been going around and trying to teach people about Git and teach people this visual mental model that I've developed, and the tips and the tricks that I've learned for navigating Git especially on the command line. And I give talks, I do full-day training workshops, I do training workshops at work. And it's become my thing now, which is flabbergasting [laugh] because I never intended [laugh] for—I didn't set out to go and be this Git expert or to be, quote-unquote, “Famous” for a given value of famous, for knowing stuff about Git. I'm a frontend engineer. There's still a piece of me that looks at it, and is like, “How on earth did this even happen to me?” So, yeah, I don't know. So, that's my Oh shit, Git!?! story. And now—Corey: It's a great one. It's—Katie: Thank you.Corey: Git is one of those weird things where the honest truth of were, “Terrible Ideas in Git”—my talk—came from was that I kept trying and failing to understand Git, and I realized, “How do I fix this? I know. I will give a talk about something.” That is what we know as a forcing function. If I'm not quite ready, they will not move the conference. I know because I checked.Katie: Yep. [laugh]Corey: And one in Zurich was not the first time I'd given it, but it was very clearly something that everyone had problems with. The first version of that talk would have absolutely killed it, if I'd been able to give it to the core Git maintainers. And all, you know, seven of those people would have absolutely loved it, and everyone else would have been incredibly confused. So, I took the opposite tack and said, “All right. How do I expand this to as broad an audience as possible?”And in one of the times I gave it, I said, “Look, I want to make sure it is accessible to everyone, not just people who are super deep into the weeds but also be able to explain Git to my mother.” And unlike virtually every other time where that, “Let me explain something to my mom.” And that is basically coded ageism and sexism built into one. In that case, it was because my mother was sitting in the front row and does not understand what Git is. And she got part of the talk and then did the supportive mother thing of, and as for the rest of it. “Oh, you're so well-spoken. You're so funny. And people seem to love it.” Like, “Did you enjoy my discussion of rebases?”Katie: [laugh].Corey: She says, “Just so good at talking. So, good.” And it was yeah.Katie: [laugh]. Oh, yeah. No, I, I—totally—I understand that. There's this book that I picked up when I was doing all of this research, and I'm looking over at my bookshelf, it's called Version Control with Git. It's an O'Reilly book.And if I remember correctly, it was written by somebody who actually worked at Git. And the way that they started to describe how Git works to people was, they talked about all kinds of deep internals of Unix, and correlated these pieces of the deep internals of Git to these deep Unix internals, which, at the time, makes sense because Git came out of the Unix kernel project as their source control methodology, but, like, really? Like, [laugh] this book, it says at the beginning, that it's supposed to teach people who are new to Git about how to use it. And it's like, well, the first assumption that they make is that you understand the 15 years' worth of history of the Linux kernel project and how Linux works under the hood. And it's like, you've got to be absolutely kidding me that this is how anyone could think, “Oh, this is the right way to teach people Git.”I mean, it's great now, going back in and rereading that book more recently, now that I've already got that understanding of how it works under the hood. This is giving me all of this detail, but for a new person or beginner, it's absolutely the wrong way to approach teaching Git.Corey: When I first sat down to learn Git myself it was in 2008, 2009, Scott Chacon from GitHub at the time wound up doing a multi-day training at the company I worked at the time. And it was very challenging. I'm not saying that he was a bad teacher by any stretch of the imagination, but back in those days, Git was a lot less user-friendly—[laugh] not that it's tremendously good at it now—and people didn't understand how to talk about it, how to teach it, et cetera. You go to GitHub or GitLab or any of the other sites that do this stuff, and there's a 15-step intro that you can learn in 15 minutes and someone who has never used Git before now knows the basics and is not likely to completely shatter things. They've gotten the minimum viable knowledge to get started down to a very repeatable, very robust thing. And that is no small feat. Teaching people effectively is super hard.Katie: It really is. And I totally agree with you that if you go to these providers that they've invested in improving the user experience and making things easier to learn. But I think there's still this problem of what happens when everything goes wrong? What happens if you make a mistake, or what happens if you commit a file on the wrong branch? Or what happens if you make a commit but you forgot to add one of the files you wanted to put in the commit?Or what happens if you want to undo something that you did in a previous commit? And I think these are things that are still really, for some reason, not well understood. And I think that's kind of why Oh Shit, Git!?! has fallen into this little niche corner of the Git world is because the focus is really like, “Oh, shit. I just made a mistake and I don't know what to do, and I don't know what terminology to even Google for to help me figure out how to fix this problem.” And I've come out and put these very simple, like, here: step one, step two, step three.And people might disagree or argue [laugh] with some of the commands and some of the orders, but really, the focus is, like, people have this idea in their head, I think, particularly at their jobs, that Git is this big, important thing and if you screw up, you can't fix it. When really a lot of helping people to become more familiar and comfortable with Git is about ensuring them that no, no, no, the whole point of Git is that just about everything can be undone, and just about everything is fixable, and here's how you do it. So, I still think that we have a long way to go when it comes to teaching Git.Corey: I would agree wholeheartedly. And I think that most people are not thinking about this from a position of educators, they're thinking about it from the position of engineering, and it's a weird combination of the two. You're not going to generally find someone who has no engineering experience to be able to explain things in a context that resonates with the people who will need to apply it. And on the other side, you're not going to find that engineers are great at explaining things without having specific experience in that space. There are exceptions, and they are incredibly rare and extremely valuable as a result. The ability to explain complex things simply is a gift.Katie: It really is.Corey: It's also a skill and you can get better at it, but a lot of folks just seem to never put the work in in the first place.Katie: Well, you know, it's quote-unquote, “soft skills.” So [laugh].Corey: Oh, God. They're hard as hell, so it's a terrible name.Katie: [laugh]. Yeah. Though I could not agree more, I think something that I really look at as a trait of a super senior engineer is that they are somebody who has intentionally worked on and practiced developing that skill of taking something that's a really complex technical concept, and understanding your audience, and having some empathy to put yourself in the shoes of your audience and figure out okay, how do I break this down and explain it to someone who maybe doesn't have all the context that I do? Because when you think about it, if you're working at a big company, and you're an engineer, and you want to, like, do the new hotness, cool thing, and you want to make Kubernetes the thing or whatever other buzzword term you want to use, in order to get that prioritized and on a team's backlog, you have to turn around and explain to a product person why it's important for product reasons, or what benefits is this going to bring to the organization as far as scalability, and reliability. And you have to be able to put yourself in the shoes of someone whose goals are totally different than yours.Like, product people's goals are all around timelines, they're around costs, they're around things short-term versus long-term improvements. And if you can't put yourself into the shoes of that person, and figure out how to explain your cool hot tech thing to them, then you're never going to get your project off the ground. No one's ever going to approve it, nobody's going to give budget, nobody's going to put it in a team's backlog unless you have that skill.Corey: That's the hard part is that people tend to view advancement as an individual contributor or engineer purely through a lens of technical ability. And it's not. The higher you rise, the more your job involves talking to people, and the less it involves writing code in almost every case.Katie: One hundred percent. That's absolutely been my experience as an architect is that, gosh, I almost never write code these days. My entire job is basically writing docs, talking to people, meeting with people, trying to figure out, where, what is the left hand doing and what is the right hand doing so I can somehow create a bridge between them. You know, I'm trying to influence teams, and their approach, and the way that they think about writing software. And, yes there is a foundation of technical ability that has to be there.You have to have that knowledge and that experience, but at this point, it's like, my God—you know, I write more SQL as a frontend architect that I write HTML, or CSS, or JavaScript because I'm doing data analysis and [laugh] I'm doing—I'm trying to figure out what does the numbers tell us about the right thing to choose or the right way to go, or where are we having issues? And, yeah, I think that people's perceptions and the reality don't always match up when it comes to looking at the senior IC technical track.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: At some level, you hear people talking about wanting to get promoted, and what they're really saying—and it doesn't seem that they realize this—is, “I love what I do, so I'm really trying to get promoted so I can do less of what I love and a lot more of things I hate.”Katie: [laugh]. Yes. Yeah. Yeah. [laugh]. In some ways, in some ways, I think that you've got to kind of learn to accept it. And there are some people, I think that once you get past the senior engineer, or maybe even the staff engineer, maybe they don't even want to go there because they don't want to do the kind of sales pitch, people person, data numbers pitching, trying to get people to agree with you on the right way forward is really hard, and I don't think it's for everyone. But I love it. [laugh]. I absolutely love it. It's been great for me. And I feel like it really—it plays to my strengths in a lot of ways.Corey: What I always found that worked for me, as far as getting folks on board with my vision of the world is, first, I feel like I have to grab their attention, and my way is humor. With the Git talk, I have to say giving that talk a few times made me pretty confident in it. And then I was invited to the frontend conference. And in hindsight, I really, really should have seen this coming, but I'm there, I'm speaking in the afternoon, I'm watching the morning talks, and the slides are all gorgeous.Katie: Yes. [laugh].Corey: And then looking at my own, and they are dogshit. Because this was before I had the sense to hire a designer to help with these things. It was effectively black Helvetica text on a white background. And I figured, “All right, this is a problem. I only have a few hours to go, what do I do?”And my answer was, “Well, I'm not going to suddenly become an amazing designer in the four hours I have.” So, I changed some of the text to Comic Sans because if you're doing something bad, do it worse, and then make it look intentional. It was a weird experience, and it was a successful talk in that no one knew what the hell to make of what I was doing. And it really got me thinking that this was the first time I'd spoken to an audience who was frontend, and it reminded me that the DevOps problems that I normally talked about, were usually fairly restricted to DevOps. But the things that everyone touches, like Git, for example, start to be things that resonate and break down walls and silos better than a given conference ever can. But talking instead about shared pain and shared frustrations.Katie: Yes. Yes. Everyone likes to know that they are not alone in the world, particularly folks who are maybe underrepresented minorities in tech and who are afraid to speak up and say, “Oh, I don't understand.” Or, “That doesn't make any sense to me,” because they're worried that they're already being taken not as seriously as their white, male counterparts. And I feel like something I really try to lean into as a very senior woman in a very male-dominated field is if I don't understand something, or if I have a question, or something doesn't make sense is I try to raise my hand and ask those questions and say, out loud, “Okay, I don't get this.”Because I can't even tell you, Corey, the number of times I've had somebody reach out to me after a meeting and say, “Thank you. I didn't understand it either.” Or, “I thought maybe I just didn't understand the problem space, or maybe I just wasn't smart enough to understand their explanation.” And having somebody who's very senior who folks look up to, to be able to say, “Wait a minute, this doesn't make sense.” Or, you know, I don't understand that explanation.Can you explain it a different way? It's so powerful and it unblocks people and it gives them this confidence that, hey, if that person up on stage, or leading this meeting, or writing this blog post doesn't get this either, maybe I'm not so stupid, or maybe I do deserve to be in this industry, or maybe it's not just me. And I really hope that more and more people can feel empowered to do that in their daily lives more. I think that's been something that has been a tremendous learning through all of this experience with Oh shit, Git!?!For me is the number of people that come up to me after conference talks, or tweet me, or send me a message, just saying, “Thank you. I thought I was alone. I thought I was the only one that didn't get this.” And knowing that not just am I not the only one, but that people are universally frustrated, and universally Git makes them want to swear all the time, I mean, that's the best compliments that I get is when folks come up to me and say, “Thank you, I thought I was alone.”Corey: That's one of the things that I find that is simultaneously the most encouraging and also the most galling. Every once in a while I will have some company reach out to me—over a Twitter thread or something—where I'm going through their product from a naive user perspective of, like, I'm not coming at this with 15 years of experience and instinct that feed into how I approach this, but instead the, I actually haven't used this product before. I'm not going to jump ahead and make assumptions that tend to be right. I'm going to follow the predictable user path flow. And they are very often times where, “Okay. I'm hitting something. I don't understand this. Why is it like this? This is not good.”And usually, companies are appreciative when I do stuff like that, but every once in a while, I'll get some dingus who will come in, and like, “I didn't appreciate the fact that you end up intentionally misinterpreting what we're saying.” And that's basically license for me to take the gloves off and say, “No, this was not me being intentionally dumb. Sure, I didn't apply a whole bunch of outside resources I could have to this, but it wasn't me intentionally failing to get the point. I did not understand this, and you're coming back to me now reinforces that you are too close to the problem. And, on some level, when your actual customers have problems with this, they are hearing an element of contempt from you.”Katie: Totally.Corey: “This is an opportunity to fix it and make it more approachable because spoiler, not a lot of people love paying money to something that makes them feel stupid.”Katie: [laugh]. See, Corey, I don't know. You say that you're not really a frontend person, but that is a very strong UX mindset. Like that—Corey: Oh, my frontend stuff is actually pretty awesome because as soon as I have to do something that even borders on frontend, I have the insight and I guess, willingness to do the smart thing, which is to immediately stop talking and pay someone who knows what they're doing.Katie: [laugh]. Thank you. On behalf of all frontend engineers everywhere, I applaud that, and I appreciate it.Corey: It comes down to specialty. I mean, again, it would also be sort of weird from my perspective, which is my entire corporate position is I fix the horrifying AWS bill. So, if you're struggling with the bill in various capacities, first, join basically everyone, but two, you're not alone so maybe hire someone who is an expert in this specific thing to come in and help you with it. And wouldn't it be a little hypocritical of me to go in and say, “Oh, yeah, but I'm just going to YOLO my way through this nonsense?”Katie: Mm-hm. [laugh]. Yeah, [laugh] I don't know we'll want to include this in the final recording, but I have a really hilarious story, actually, about Amazon. So—Corey: Oh, please. They listen to this and they love customer feedback.Katie: [laugh].Corey: I'm not being sarcastic. I'm very sincere here.Katie: Well, this is many, many, many years ago. I mean, probably, oh, gosh, this is probably eight years ago at this point. I was interviewing for a job at Amazon. It was a job to be a frontend engineer on the homepage team, which at the time, I was like, “Oh, my God, this is Amazon. This is such an honor. I'm so excited.”Corey: And you look at amazon.com's front page, and it's, “Oh, I can fix this. There's so much to fix here.”Katie: Yes.Corey: And then reality catches up if I might not be the first person in the world to have made that observation.Katie: [laugh].Corey: What's—Katie: Well—Corey: Going on in there?Katie: Yeah. Well, I'll tell you what's going on. So, I think I did five different phone interviews. You know, before they invite you out to Seattle, there's—and again, this was eight years ago, so this was well before everyone was working at home. And in those five hours of phone interviews, I want you to make a guess at how many minutes we spent talking about HTML, CSS, and JavaScript.Corey: I am so unfamiliar with the frontend world, I don't know what the right answer is for an interview, but it's either going to be all the time or none of it, based on the way you're framing it.Katie: Yes. [laugh]. It was basically, like, half an hour. So, when you are a frontend engineer, your job is to write HTML, CSS, and JavaScript. And in five hours, I talked about that for probably half an hour.It was one small question and one small discussion, and all the rest of the time was algorithms, and data structures, and big O notation, and oh, gosh, I think they even did the whole, like, “I typed something into my browser, tell me what happens after I type a URL into my browser.” And I think that just told [laugh] me everything that I needed to know about how Amazon approached the frontend and why their website was such a hot mess was because they weren't actually hiring anyone with real frontend skills to work on the frontend. They were hiring backend people who probably—not to say that they weren't capable or didn't care, but I don't know. That's my favorite Amazon story that I have is trying to go work there, and they basically were like, “Yes, we want a frontend engineer.” And then they didn't actually ask about any frontend engineering skill sets in the job. They didn't offer me anyth—I don't think I got invited to go to Seattle, but I probably wouldn't have anyways.Corey: No. Having done it a couple of times now, again, I like the people I meet at Amazon very, very much. I want to be very clear on that. But some of their processes on the other hand, oh, my God. It shows that being a big company is clearly not necessarily a signal that you solved all of these problems. In some cases, you're basically just crashing through the problem space by sheer power of inertia.Katie: Yeah, definitely. I think you can see that when looking at their frontend. Harkening back a little bit to what we were talking about earlier is you don't go to Amazon and learn patterns of interaction that are applicable to every single site on the web. Amazon kind of expects that users are going to learn the Amazon way of shopping and that users are going to adjust how they navigate the web in order to accommodate Amazon. You know, people learn, “Oh, this is what I do on Amazon.” And then, you know, they're—Corey: Oh, that's the biggest problem with bad user experience is people feel dumb.Katie: Mm-hm.Corey: They don't think, “This company sucks at this thing.” They think, “I must not get it.” And I know this, and I am subject to it. I run into this problem all the time myself.Katie: Oh, yes.Corey: And that is a problem.Katie: Yeah. It's why I think, like you said earlier, it's so important when you work somewhere to figure out how do you get that distance between being a power user enough so that you can understand and appreciate what it's like for a regular user who's not a power user of your site. And what do they do? And UX researchers are amazing. A good UX researcher is worth absolutely their weight in gold because, I don't know if you've ever sat in on a UX session where the researcher is walking a user through completing a specific task on a website, but oh my God, it's painful.It's because [laugh] you just want to, you want to push them in the right direction, and you want to be like, “Oh, but what about in the upper right over there, that big orange button,” and you can't do that. You can't push people. You have to be very open-ended, you have to ask them questions. And every single time I've listened in on a UX research recording, or a call, I want to scream through the computer and be like, “Oh, my gosh. This is how you do it.”But, you know, you can't do that. So, [laugh] I think it's important to try to develop that kind of skill set on your own of, “Okay, if I didn't stare at this website every day, what would it be like for me to try to navigate? If I was using a keyboard for navigation or a screen reader instead of a mouse, what would my experience be like?” Having that empathy, and that ability to get outside of yourself is just really important to be a successful engineer on the web, I think.Corey: Yeah. And you really wish, on some level, that they would be able to articulate this as an industry. And I say ‘they,' I guess I'm speaking of about three companies in particular. I have a lot more sympathy for a small startup that is having problems with UX than I am for enormous companies who can basically hurl all the money at it. And maybe that's unfair, but I feel like, at some point of market dominance, it is beholden on you to set the shining example for how these things are going to work.I don't feel that way, necessarily about architecture on the backend. Sure, it can be a dangerous, scary tire fire, but that's not something your customers or users need to think about or worry about, as long as it is up from their perspective. UX is very much the opposite of that.Katie: Totally. And I think, working at a former startup, there's a tendency to really focus a lot on those backend problems. You know, you really look at, “Okay, we're going to nitpick every single RPC request. We're going to have all kinds of logging and monitoring about, okay, this is the time that it takes for a database API request to return.” And just the slightest movement and people freak out.But it's been a process that I've been working really hard on the last couple of years, to get folks to have that same kind of care and attention to the stuff that they ship to the frontend, especially for a lot of organizations that really focus on, “Well, we're a tech company,” it's easy to get into this, oh, engineering is all of these big hard systems problems, when really your customers don't care about all of that. Yes, ultimately, it does affect them because if your database calls are really, really slow, then it has an effect on how quickly the user gets a response back and we know that slow-performing websites, folks are more likely to abandon them. Not that it doesn't matter completely, but personally, I would really love it to see more universally around the industry that frontend is seen as this is the entirety of your product and if you get that wrong, then none of the rest of your architecture, or your infrastructure, or how great your DevOps is matters because you need customers to come to your site and buy things.Corey: It turns out that the relationship between customers coming to your site and buying things and the salaries engineering likes to command is sometimes attenuated in ways that potentially shouldn't be. These are interesting times, and it does help to remember the larger context of the work we do, but honestly, at some point, you wind up thinking about that all the time, and not the thing that you're brought in specifically to fix. These are weird times.Katie: Yes.Corey: Katie, thank you so much for taking the time to speak with me about several things. Usually—it's weird. Normally, when someone says thank you for speaking to me about Git, there is no way that isn't a sarcastic—Katie: [laugh].Corey: —statement. But in this case, it is in fact genuine.Katie: Yes, I will bitch about Git until I am blue on the face, so I appreciate you having me on board to talk about it, Corey. Thank you.Corey: Of course. If people want to learn more, where can they find you?Katie: They can find me at ohshitgit.com, or as you pointed out, the dangitgit.com swear-free version. As a little plug for the site, we now have had the site translated by volunteers in the community into 28 different languages. So, if English is not your first language, there's a really good chance you'll find a version of OSG—as I like to call it—that is in your language.Corey: Terrific. And we will, of course, put links to these wonderful things in the [show notes 00:39:16]. Thank you so much for taking the time to speak with me. I really appreciate it.Katie: Thank you, Corey. It's been lovely to reconnect, and gosh, look at where we are now compared to where we were almost five years ago.Corey: I know. It's amazing how the world works.Katie: Really.Corey: Katie Sylor-Miller, frontend architect at Etsy. 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 written in what is clearly your preferred user interface: raw XML.Katie: [laugh].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.This has been a HumblePod production. Stay humble.

Top 3 Value Bombs: 1. Allow yourself to act intuitively 2. A 100% remote workforce is the new trend since the pandemic 3. Structure your validation process to ensure your success The Famous Five: 1. What's your favorite business book? Answer: "Let My People Go Surfing: The Education of a Reluctant Businessman by Yvon Chouinard" 2. Is there a CEO you're following or studying? Answer: "GitHub: Founders - Tom Preston-Werner, Chris Wanstrath, Scott Chacon, P. J. Hyett & CEO - Nat Friedman" 3. What's your favorite online tool for growing your business? Answer: "Confluence" 4. If you could give your 20 year old self a piece of advice, what would it be? Answer: "Trust your intuition." 5. How many hours of sleep do you get every night? Answer: "6-9 hours." Episode Information: https://www.takingyoutothetop.io/episodes/episode-60-teamway-co-founder-ceo-søren-nørgaard

The one question Scott Chacon never stops asking is, ‘why?’ It’s this insatiable sense of curiosity that led him to become a certified sommelier, a karaoke expert, and even run for office. It also led him to start Github, which he ended up selling to Microsoft for $7B.

The one question Scott Chacon never stops asking is, ‘why?’ It’s this insatiable sense of curiosity that led him to become a certified sommelier, a karaoke expert, and even run for office. It also led him to start Github, which he ended up selling to Microsoft for $7B.

State of Mind is a podcast series that tells the intimate stories of the world's best authors, entrepreneurs, athletes, and artists, through an immersive audio experience. Hosted by Blinkist's co-founder Niklas Jansen. Season 2 out on November 18th.

State of Mind is a podcast series that tells the intimate stories of the world's best authors, entrepreneurs, athletes, and artists, through an immersive audio experience. Hosted by Blinkist's co-founder Niklas Jansen. Season 2 out on November 18th.

Interview with Github Co-Founder, Scott Chacon. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/techforgranted/support

How is it to sell a company for 7.5bn dollars? Imagine you sit down next to somebody who sold his former company five days ago to Microsoft for more than 7bn dollars. That's what it felt like when I interviewed Scott. We sat down in Berlin and talked about GitHub, what he learned for his new company Chatterbug and why customer focus is so important for him. Have a lot of fun while listening, it is definitely worth it. See the whole article & show notes at https://thevaluelab.co/ Moreover, here are some useful links: You can get the newest strategies and tools here: https://thevaluelab.co/news Look at our Digital Leaders merch: https://thevaluelab.co/shop Digital Leaders on YouTube: https://thevaluelab.co/r/youtube/ Digital Leaders Community on LinkedIn: https://www.linkedin.com/groups/8680696/ Digital Leaders on Instagram: https://instagram.com/digitalleaderspodcast --- Send in a voice message: https://anchor.fm/digital-leaders/message

On this episode of the Moringa School podcast, we are joined by Scott Chacon, an entrepreneur, software developer, startup enthusiast and language learner. Scott is the co-founder and CEO of Chatterbug, and Co-founder and former CIO of Github. Scott and his team of co-founders built a software development platform called Github, which brings together the world's largest community of developers to discover, share and build better software. Github was sold to Microsoft for $7.5B in 2018. Scott joined GitHub in late 2008 when Git was still a rather obscure and difficult to use version control system. From those days of the 4 co-founders working from coffee shops, Scott helped build GitHub into a global company of more than 400 employees. In that time, Scott did a little of everything as GitHub grew - backend Git infrastructure work, Ruby and frontend development, training, sales, financial forecasting, documentation, internal tools development, hiring, fundraising, office planning and buildout, internal communications, evangelization and public speaking. While at GitHub Scott also did everything he could to help Git become the dominant technology it is today. He wrote two of the very first books on Git - Git Internals published by Peepcode and Pro Git published by Apress, both now open sourced and free to read. Pro Git is in it's second edition and has been translated into more than 10 languages. Scott helped start and supported the libgit2 project, which is used by nearly every Git user interface, plugin and hosting solution today. Scott gave more than 75 talks, tutorials and workshops across the globe, from small local meetups to training the Android development team. He also registered, developed and maintained the official Git website for 8 years. Scott went on to his current venture, Chatterbug, a language learning system that helps users to learn a new language to fluency through adaptive courses that respond to the way users learn, as well as one-on-one video sessions with native speakers from around the world. Chatterbug combines the flexibility of digital language apps with the effectiveness of in-person language schools. Listen as Scott shares his entrepreneurial journey, the software development process, the future of work and learning and so much more on the podcast. Enjoy and share. You can find Scott on Twitter at @chacon. Hosted by Eugene Nzioki, Leo Igane, Kevin Ahere, Melissa Malala, Michel Atieno and Victor Ireri.

Learnings from building a multibillion dollar company. Live recording from the Fireside Chat in Factory Berlin with Scott Chacon. See acast.com/privacy for privacy and opt-out information.

Podcasts erreichen Menschen auf einer neuen Ebene, bauen Vertrauen auf und binden Zuhörer. Fabian Tausch ist Gründer des Jungunternehmer-Podcasts und der Podcast Consulting Firma Meucci Media in Berlin. Er sagt: „Um dir Zeit auf dem Weg zum Erfolg zu sparen, lerne von erfolgreichen Leuten“. Nach sechs Wochen brach er sein Studium ab und entschied sich Deutsche Gründer wie Daniel Kraus von Flixbus und internationale Persönlichkeiten, wie Cal Henderson von Slack & Flickr oder Scott Chacon von Github zu interviewen. Mittlerweile hat er über 100 Gäste interviewt und sein Podcast erreichte mehr als 1.000.000 Zuhörer.

In this episode @itstheandre speaks with @chacon about everything from GitHub, Ruby on Rails, Open Source and Language LearningScott ChaconLinkedInTwitterMediumGitHubGitHubWebsiteTwitterChatterbugWebsiteTwitterYoutubeResources Mentioned during the episodeThe Hard Thing About Hard Things: Building a Business When There Are No Easy Answers - by Ben HorowitzThe New Jim Crow: Mass Incarceration in the Age of Colorblindness by Michelle AlexanderProGit by Scott ChaconDeep Work: Rules for Focused Success in a Distracted World by Cal NewportMIT Scientists prove adults learn language to fluency nearly as well as children by Scott ChaconHidden Brain Podcast Episode : Lost in TranslationThibault, aka DJ Rawdia is a fantastic DJ that happily created the new songs for the Pioneers Show. Check it on Instagram. See acast.com/privacy for privacy and opt-out information.

In this episode @itstheandre speaks with @chacon about everything from GitHub, Ruby on Rails, Open Source and Language LearningScott ChaconLinkedInTwitterMediumGitHubGitHubWebsiteTwitterChatterbugWebsiteTwitterYoutubeResources Mentioned during the episodeThe Hard Thing About Hard Things: Building a Business When There Are No Easy Answers - by Ben HorowitzThe New Jim Crow: Mass Incarceration in the Age of Colorblindness by Michelle AlexanderProGit by Scott ChaconDeep Work: Rules for Focused Success in a Distracted World by Cal NewportMIT Scientists prove adults learn language to fluency nearly as well as children by Scott ChaconHidden Brain Podcast Episode : Lost in TranslationThibault, aka DJ Rawdia is a fantastic DJ that happily created the new songs for the Pioneers Show. Check it on Instagram. See acast.com/privacy for privacy and opt-out information.

Komplizierte Feedbackformulare, noreply-Mails und kein Ansprechpartner in Sicht - richtig guter Kundenservice ist auch in Zeiten der Digitalisierung längst noch keine Selbstverständlichkeit. Scott Chacon, Mitgründer von GitHub hat auf unserem Business Festival hub.berlin über seine Erfahrungen darüber gesprochen, wie man ansprechende Angebote schafft und zufriedene Kunden gewinnt. Der Vortrag als Video: https://youtu.be/lthMpODHX6c

Vi pratar versionshantering med Git. Verktyg, kommandon, inställningar, arbetsflöden och en del annat. Vi avslutar som vanligt med nyheter, nya lanseringar samt modultips från Drupalsfären. Länkar till moduler, webbplatser och tjänster vi pratade om i detta avsnitt: Bra resurser för att lära sig om Git Watch Git For Ages 4 And Up | Open Source Developers Conference Episodes Introduction to Git with Scott Chacon of GitHub - YouTube http://git-scm.com/book http://gitref.org/ http://gitready.com/ http://think-like-a-git.net/ http://randyfay.com/topics/git http://mislav.uniqpath.com/2010/07/git-tips/ http://pcottle.github.io/learnGitBranching/ Git verktyg Tower - Git client for Mac Git+Hg Client SmartGit/Hg Tortoisegit - Windows Shell Interface to Git SourceTree: Free Mercurial and Git Client for Windows and Mac Tig: text-mode interface for Git (ncurses-based) Aquire achievements while using git Webbtjänster för Git https://bitbucket.org/ https://github.com/ (Mer Git grejor längre ned.) Nya webbplatser med Drupal http://www.mkse.com/2013/10/21/fler-drupal-webbar-fran-miemi http://www.mkse.com/2013/10/22/ihm-se-relanserad-pa-drupal http://www.mkse.com/2013/10/22/pfizer-bygger-enorm-global-drupal-7-plattform Modultipset Views Autocomplete Filters http://webwash.net/tutorials/how-add-autocomplete-functionality-text-filters-views Genomgång av olika fält moduler http://wizzlern.nl/drupal/unwrap-your-field-content Feature 2.0 http://www.systemseed.com/blog/features-20-released Open Atrium 2 http://www.phase2technology.com/blog/collaboration-software-needs-a-better-open-source-alternative-and-its-here Nyheter SEO risker http://brath.se/farlig-sokmotoroptimering-betygsatt/ Drush Staging Workflow | Jackson River Tjänst hos Kodamera https://groups.drupal.org/node/354768 Git-kommandon vi gick igenom git init git status git add git commit git diff git branch git checkout git clone git fetch git merge git pull git push git merge –no-ff git rebase git stash git gc git bisect Git completion och prompt Med git brukar det följa med en git-completion.* fil för olika shells. Läs på hur man aktiverar den så får du tab complete på git kommandon, branches etc. Otroligt smidigt och tidsbesparande! Det går också att få shell prompten att visa aktuell branch, status och annat. Sök efter information om “git prompt” så finns en uppsjö av information och exempel. Git ignore I filen gitignore kan man ange vilka filer man vill att git ska ignorera. Som i exemplet från Fredrik nedan kan man ha en i sin hemmamapp, den kommer alltid att vara aktiv. Sedan kan man ha en specifik per projekt också. Fil: ~/.gitignore *.a *.o *.py[co] *.so *.sw[nop] *.tmp *.patch *.orig *.sql *.gz *.tar *.zip *~ .#* [#]*# .DS_Store Git config I hemmamappen finns också en git config fil. Här är exempel från Fredriks config fil. Kopiera inte dessa rakt av utan kolla upp vad kommandona gör först. core / trustctime fungerar inte alltid så bra i OS X och kan ge falska besked om att en fil är ändrad när den inte är det. push / default gör att git inte försöker köra push på alla brancher när man kör “git push” utan bara aktuell branch till aktuell remote branch med samma namn. Varför detta inte är det förvalda beteendet i git har jag inte sett några svar på. branch / autosetuprebase är för de som gillar ett rebase baserat arbetsflöde som standard. Fil: ~/.gitconfig [user] name = Kalle Svensson email = kalle@exempel.se [core] excludesfile = ~/.gitignore trustctime = false whitespace = tab-in-indent,trailing-space [alias] br = branch co = checkout ci = commit cia = commit -a cim = commit -m cima = commit -am ciam = commit --amend -m st = status cp = cherry-pick w = whatchanged df = diff --patch-with-stat dfs = diff --staged --patch-with-stat l = log ll = log --oneline --decorate hist = log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short [color] ui = auto whitespace = red reverse [push] default = upstream [branch] autosetuprebase = always Några exempel från Fredriks fil med shell aliaser # Git stuff alias g='git' alias gg='git grep -I --line-number --heading' alias ga='git add -u .' alias gaa='git add --all .' alias gci='git commit -a -m' alias gcm='git commit -m' alias gcam='git commit --amend -m' alias gst='git status -sb' alias gcp='git cherry-pick' alias gbr='git branch' alias gfo='git fetch origin' alias gfu='git fetch upstream' alias gp='git push' alias gpo='git push -u origin' alias gl='git pull' alias glu='git pull upstream' alias glnr='git pull --no-rebase' alias grm='git rebase origin/master' alias gmn='git merge --no-ff' alias gsl='git stash list' gsa () { git stash apply stash@{$1} } gss () { git stash save "$@" } gra () { git remote add $2 git@github.com:$2/$1.git } # tig stuff alias t='tig' alias tst='tig status'

This is the second set of interviews from Git Merge 2013 in Berlin. If you cannot see the audio controls, your browser does not support the audio element. Use the link below to download the mp3 manually. Link to mp3First guest of the day, Scott Chacon, with the Berliner Dom in the background.Photo CC-BY Thomas RastScott Chacon (homepage, twitter, github), works at GithubAbout Git community. GitTogether.Mislav Marohnić (homepage, twitter, github)About the passion of Git users. Hub. Git tips. Merge vs rebase.Update: Mislav's lightning talk about Hub at Git MergeThomas Rast (homepage, google+, github)On Git internals, git-notes, git log -L, developing Git. Listen to the episode on YouTube

本期由 Daniel 主持，参与嘉宾有 SaitoWu, Dingding Ye。武鑫(Saito) 是著名自托管 Git 项目仓库开源项目 GitLab 的核心开发者之一，也是 RubyConfChina 2012 的讲师。本期 SaitoWu 同学继续第六期的话题，跟我们聊聊 Gitlab 的故事，包括 Gitlab 的项目领导人 Randx 其人，武鑫如何成为 Gitlab 的核心开发者之一，Gitlab 这个开源项目对武鑫产生的影响可以给我们带来什么样的启发，以及对 Gitlab 将来发展的展望。在节目的最后，武鑫回答了大家关心的问题。 Gitlab 专题问题收集帖 How Gitlab Works How Gitlab Works PPT Randx Gitlab core team members Gitlab.com Randx join Gitlab.com as a co-founder IRC Gitlab Googlegroup grit_ext Skyrim 上古卷轴5：天际 Github Enterprise 打造Facebook 王淮 Smart HTTP Support Scott Chacon Gitosis Gitolite grack Git Transfer Protocols GitLab 5.0 Gitlab Shell Github Hooks Gitlab Hooks Project Management Tools Gitlab-CI Travis-CI Jenkins-CI Gitolite Mirror Gitlab-grit Gitlab-recipes gitlab-vagrant-vm Feedly gitlab_meta Special Guest: saitowu.