46 episodes

Software at Scale is where we discuss the technical stories behind large software applications.

www.softwareatscale.dev

Software at Scale Utsav Shah

    • Technology
    • 4.9 • 10 Ratings

Software at Scale is where we discuss the technical stories behind large software applications.

www.softwareatscale.dev

    Software at Scale 46 - Authorization with Or Weis

    Software at Scale 46 - Authorization with Or Weis

    Or Weis is the CEO and founder of Permit.io, a Permission as a Service platform. Previously, he founded Rookout, a cloud-debugging tool.

    Apple Podcasts | Spotify | Google Podcasts

    Many of us have struggled (or are struggling) with permission management in the various applications we’ve built. The complexity of these systems always tends to increase through business requirements - for example, some content should only be accessed by paid users or users in a certain geography. Certain architectures like filesystems have hierarchical permissions that efficient evaluation, and there’s technical complexity that’s often unique to the specific application.

    We talk about all the complexity around permission management, and techniques to solve it in this episode. We also explore how Permit tries to solve this as a product and abstract this problem out for everyone.

    Highlights

    [0:00] - Why work on access control?

    [02:00] - Sources of complexity in permission management

    [08:00] - Which cloud system manages permissions well?

    [11:00] - Product-izing a solution to this problem

    [17:00] - What kind of companies approach you for solutions to this problem?

    [22:00] - Why are there research papers written about permission management?

    [38:00] - Permission management across the technology stack (inter-service communication)

    [42:00] - What are you excited about building next?

    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.softwareatscale.dev

    • 49 min
    Software at Scale 45 - Q/A with Jon Skeet

    Software at Scale 45 - Q/A with Jon Skeet

    Jon Skeet is a Staff Developer Platform Engineer at Google, working on Google Cloud Platform client libraries for .NET. He's best known for contributions to Stack Overflow as well as his book, C# in Depth. Additionally he is the primary maintainer of the Noda Time date/time library for .NET. You may also be interested in Jon Skeet Facts.

    Apple Podcasts | Spotify | Google Podcasts

    We discuss the intricacies of timezones, how to attempt to store time correctly, how storing UTC is not a silver bullet, asynchronous help on the internet, the implications of new tools like GitHub Copilot, remote work, Jon’s upcoming book on software diagnostics, and more.

    Highlights

    [01:00] - What exactly is a Developer Platform Engineer?

    [05:00] - Why is date and time management so tricky?

    [13:00] - How should I store my timestamps? We discuss reservation systems, leap seconds, timezone changes, and more.

    [21:00] - StackOverflow, software development, and more.

    [27:00] - Software diagnostics

    [32:00] - The evolution of StackOverflow

    [34:00] - Remote work for software developers

    [41:00] - Github Copilot and the future of software development tools

    [44:00] - What’s your most controversial programming opinion?

    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.softwareatscale.dev

    • 50 min
    Software at Scale 44 - Building GraphQL with Lee Byron

    Software at Scale 44 - Building GraphQL with Lee Byron

    Lee Byron is the co-creator of GraphQL, a senior engineering manager at Robinhood, and the executive director of the GraphQL foundation.

    Apple Podcasts | Spotify | Google Podcasts

    We discuss the GraphQL origin story, early technical decisions at Facebook, the experience of deploying GraphQL today, and the future of the project.

    Highlights

    (some tidbits)

    [01:00] - The origin story of GraphQL.

    Initially, the Facebook application was an HTML web-view wrapper. It seemed like the right choice at the time, with the iPhone releasing without an app-store, Steve Jobs calling it an “internet device”, and Android phones coming out soon after, with Chrome, a brand-new browser.

    But the application had horrendous performance, high crash rates, used up a lot of RAM on devices and animations would lock the phone up. Zuckerberg called the bet Facebook’s biggest mistake.

    The idea was to rebuild the app from scratch using native technologies. A team built up a prototype for the news feed, but they quickly realized that there weren’t any clean APIs to retrieve data in a palatable format for phones - the relevant APIs all returned HTML. But Facebook had a nice ORM-like library in PHP to access data quickly, and there was a parallel effort to speed up the application by using this library. There was another project to declaratively declare data requirements for this ORM for increased performance and a better developer experience.

    Another factor was that mobile data networks were pretty slow, and having a chatty REST API for the newsfeed would lead to extremely slow round-trip times and tens of seconds to load the newsfeed. So GraphQL started off as a little library that could make declarative calls to the PHP ORM library from external sources and was originally called SuperGraph. Finally, the last piece was to make this language strongly typed, from the lessons of other RPC frameworks like gRPC and Thrift.

    [16:00] So there weren’t any data-loaders or any such pieces at the time.

    GraphQL has generally been agnostic to how the data actually gets loaded, and there are plugins to manage things like quick data loading, authorization, etc. Also, Facebook didn’t need data-loading, since its internal ORM managed de-duplication, so it didn’t need to be built until there was sufficient external feedback.

    [28:00] - GraphQL for public APIs - what to keep in mind. Query costing, and other differences from REST.

    [42:00] - GraphQL as an open-source project

    [58:00] - The evolution of the language, new features that Lee is most excited about, like Client-side nullability.

    Client-side nullability is an interesting proposal - where clients can explicitly state how important retrieving a certain field is, and on the flip side, allow partial failures for fields that aren’t critical.

    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.softwareatscale.dev

    • 1 hr 4 min
    Software at Scale 43 - Growth at Loom with Harshyt Goel

    Software at Scale 43 - Growth at Loom with Harshyt Goel

    Harshyt Goel is a founding engineer and engineering manager of Platform and Integrations at Loom, a video-messaging tool for workplaces. He’s also an angel investor, so if you’re looking for startup advice, investments, hiring advice, or a software engineering job, please reach out to him on Twitter.

    Apple Podcasts | Spotify | Google Podcasts

    We discuss Loom’s story, from when it had six people and a completely different product, to the unicorn it is today. We focus on driving growth, complicated product launches, and successfully launching the Loom SDK.

    Highlights

    [00:30] - How it all began

    [03:00] - Who is a founding engineer? Coming from Facebook to a 5 person startup

    [06:00] - Company inflection points.

    [10:30] - Pricing & packaging iterations.

    [14:30] - Running growth for a freemium product, and the evolution of growth efforts at Loom

    [30:00] - Summing up the opportunities unlocked by a growth team

    [33:00] - Sometimes, reducing user friction isn’t what you want.

    [34:30] - The Loom SDK, from idea to launch.

    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.softwareatscale.dev

    • 43 min
    Software at Scale 42 - Daniel Stenberg, founder of curl

    Software at Scale 42 - Daniel Stenberg, founder of curl

    Daniel Stenberg is the founder and lead developer of curl and libcurl.

    Apple Podcasts | Spotify | Google Podcasts

    This episode, along with others like this one, reminds me of this XKCD:

    We dive into all the complexity of transferring data across the internet.

    Highlights

    [00:30] - The complexity behind HTTP. What goes on behind the scenes when I make a web request?

    [11:30] - The organizational work behind internet-wide RFCs, like HTTP/3.

    [20:00] - Rust in curl. The developer experience, and the overall experience of integrating Hyper.

    [30:00] - Web socket support in curl

    [34:00] - Fostering an open-source community.

    [38:00] - People around the world think Daniel has hacked their system, because of the curl license often included in malicious tools.

    [41:00] - Does curl have a next big thing?

    This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.softwareatscale.dev

    • 46 min
    Software at Scale 41 - Minimal Entrepreneurship with Sahil Lavingia

    Software at Scale 41 - Minimal Entrepreneurship with Sahil Lavingia

    Sahil Lavingia is the founder of Gumroad, an e-commerce platform that helps you sell digital services. He also runs SHL Capital, a rolling fund for early-stage startups.

    Apple Podcasts | Spotify | Google Podcasts

    Sahil’s recent book, Minimal Entrepreneurship, explores a framework for building profitable, sustainable companies. I’ve often explored the trade-off between software engineering and trying to build and launch my own company, so this conversation takes up that theme and explores what it means to be a minimal entrepreneur for a software engineer.

    Highlights

    (edited)

    Utsav: Let’s talk about VCs (referencing your popular blog post “Reflecting on My Failure to Build a Billion-Dollar Company”). Are startups pushed to grow faster and faster due to VC dynamics, or is there something else going on behind the scenes?

    It’s a combination of things. People who get caught up in this anti-VC mentality are missing larger forces at play because I don't really think it's just VCs who are making all of these things happen. Firstly, there’s definitely a status game being played. When I first moved to the Bay Area, as soon as you mention you’re working on your own, the first question people ask you is how far along your company is, who you raised money with, how many employees you have, and comparing you with other people they know. You can’t really get too upset at that, since that’s the nature of the people coming to a boomtown like San Francisco.

    The way I think about it, there’s a high failure rate in being able to build a billion-dollar company, so you want to find out reasonably quickly whether you will succeed or not. Secondly, we’re in a very unique industry, where equity is basically the primary source of compensation. 90% of Americans don’t have some sort of equity component in the businesses they work for, but giving equity has a ton of benefits. It’s great to have that alignment, and folks who take an early risk for your company should get rewarded.  The downside of equity is that it creates this very strong desire and incentive to make your company as valuable as possible, as quickly as possible. In order to get your equity to be considered valuable to investors, you need to grow quickly, so that investors use these models that project your growth rate to form your valuation.

    Many people took my blog to say - it’s the VC’s fault, but that’s not true. The VCs let me do what I wanted, they don’t really have that much power. The issue was that in order for employees to see a large outcome, you need the company to have a large exit. As a founder, you’d do pretty well if the company sold for $50 million dollars, but that’s not true for employees, they really need this thing to work, otherwise, the best ones can just go work for the next Stripe. So you have this winner-take-all behavior for employees, and it’s ultimately why I ended up shrinking the company to just me for a while.

    Utsav: So do you give employees equity in the minimalist entrepreneurship framework?

    Firstly: avoid hiring anyone else for as long as possible, until you know you have some kind of product-market fit. I think It depends on your liquidity strategy. How are you as a founder about to make money from this business? The way you incentivize your employees should align with that. If you want to sell your company for a hundred million dollars, consider sharing that and giving equity. If you plan to create a cash cow business, consider profit sharing.

    Utsav: What, if any, is the difference between indie-hacking and minimalist entrepreneurship?

    They’re pretty similar. Indie hacker seems like a personality, perhaps similar to a Digital Nomad, where the lifestyle seems to be the precedent. I went to MicroConf in Las Vegas, and the attendee’s goals were fairly consistent - to buy a nice house and spend more time with their family. In that case, your goal should be to build the most boring but profitabl

    • 59 min

Customer Reviews

4.9 out of 5
10 Ratings

10 Ratings

Top Podcasts In Technology

Jason Calacanis
Lex Fridman
NPR
Jack Rhysider
Gimlet
PJ Vogt

You Might Also Like

Adam Gordon Bell - Software Developer
Changelog Media
se-radio@computer.org
Thoughtworks
Michael Kennedy (@mkennedy)
Changelog Media