Podcasts about Codebase

Adeline Atlas 11 X Published AUTHOR Digital Twin: Create Your AI Clone: ⁠⁠https://www.soulreno.com/digital-twin⁠⁠SOS: School of Soul Vault: Full Access ALL SERIES⁠⁠⁠https://www.soulreno.com/joinus-202f0461-ba1e-4ff8-8111-9dee8c726340⁠⁠Instagram: ⁠⁠⁠https://www.instagram.com/soulrenovation/⁠⁠Soul Renovation - BooksSoul Game - ⁠⁠https://tinyurl.com/vay2xdcp⁠⁠Why Play: ⁠⁠⁠https://tinyurl.com/2eh584jf⁠⁠How To Play: ⁠⁠⁠https://tinyurl.com/2ad4msf3⁠⁠Digital Soul: ⁠⁠https://tinyurl.com/3hk29s9x⁠⁠Every Word: ⁠⁠⁠⁠http://tiny.cc/ihrs001⁠⁠Drain Me: ⁠⁠⁠https://tinyurl.com/bde5fnf4⁠⁠The Rabbit Hole: ⁠⁠https://tinyurl.com/3swnmxfj⁠⁠Destiny Swapping: ⁠⁠https://tinyurl.com/35dzpvss⁠⁠Spanish Editions: Every Word: ⁠⁠https://tinyurl.com/ytec7cvc⁠⁠Drain Me: ⁠⁠https://tinyurl.com/3jv4fc5n⁠⁠

When your project has the same thing done three different ways, how do you bring everything up to date with a consistent approach?In the latest episode of the No Compromises podcast, we discuss different strategies for tackling upgrades when parts of your codebase are multiple versions behind.We walk through two main approaches and weigh the tradeoffs for both the developer doing the work and the person reviewing it.(00:00) - Setting up the upgrade scenario (02:15) - Approach one: upgrade each area to current (04:00) - Why the reviewer's experience matters too (07:30) - A third approach neither one expected (09:00) - Silly bit Want help upgrading your Laravel project?

Joël and Sally tidy up the place as they discuss the different ways a new codebase and team can feel welcoming to them. Together they break down the things that help them ingrate into a new project more easily, explain why the lore of a project can be sacred to some, what you can do in the present to make things easier for a developer down the road, and why communication is crucial for keeping everyone on the same page even long after you've moved on. — Check out these resources for a deeper dive into some of the topics mentioned in this week's episode - Fixtures (https://api.rubyonrails.org/v3.1/classes/ActiveRecord/Fixtures.html) - Hierarchy of Documentation (https://challahscript.com/hiearchy_of_documentation) - Domain Modelling 1 (https://martinfowler.com/bliki/AnemicDomainModel.html) - Domain Modelling 2 (https://thoughtbot.com/blog/avoid-putting-logic-in-map-blocks) Thanks to our sponsor for this episode Scout Monitoring (https://www.scoutapm.com/). Your hosts for this episode have been thoughtbot's own Joël Quenneville (https://www.linkedin.com/in/joel-quenneville-96b18b58/) and Sally Hall (https://www.linkedin.com/in/sallyannahall). If you would like to support the show, head over to our GitHub page (https://github.com/sponsors/thoughtbot), or check out our website (https://bikeshed.thoughtbot.com). Got a question or comment about the show? Why not write to our hosts: hosts@bikeshed.fm This has been a thoughtbot (https://thoughtbot.com/) podcast. Stay up to date by following us on social media - YouTube (https://www.youtube.com/@thoughtbot/streams) - LinkedIn (https://www.linkedin.com/company/150727/) - Mastodon (https://thoughtbot.social/@thoughtbot) - BlueSky (https://bsky.app/profile/thoughtbot.com) © 2026 thoughtbot, inc.

פרק מספר 508 של רברס עם פלטפורמה, שהוקלט ב-30 בדצמבר 2025, קצת לפני שנגמרה השנה וקצת אחרי שבאמת התחיל סוג של חורף - אורי ורן לוגמים תה ומארחים את מישה פיינשטיין מחברת Bria AI כדי לדבר על איך עושים תמונות בצורה שבאמת התכוונתם (וגם קצת על חורף).

What if understanding your codebase was no longer a blocker for great testing? Most testers were trained to work around the code — clicking through UIs, guessing selectors, and relying on outdated docs or developer explanations. In this episode, Playwright expert Ben Fellows flip that model on its head. Using AI tools like Cursor, testers can now explore the codebase directly — asking questions, uncovering APIs, understanding data relationships, and spotting risk before a single test is written. This isn't about becoming a developer. It's about using AI to finally see how the system really works — and using that insight to test smarter, earlier, and with far more confidence. If you've ever joined a new team, inherited a legacy app, or struggled to understand what really changed in a release, this episode is for you. Registration for Automation Guild 2026 Now: https://testguild.me/podag26

BONUS: Swimming in Tech Debt — Practical Techniques to Keep Your Team from Drowning in Its Codebase In this fascinating conversation, veteran software engineer and author Lou Franco shares hard-won lessons from decades at startups, Trello, and Atlassian. We explore his book "Swimming in Tech Debt," diving deep into the 8 Questions framework for evaluating tech debt decisions, personal practices that compound over time, team-level strategies for systematic improvement, and leadership approaches that balance velocity with sustainability. Lou reveals why tech debt is often the result of success, how to navigate the spectrum between ignoring debt and rewriting too much, and practical techniques individuals, teams, and leaders can use starting today. The Exit Interview That Changed Everything "We didn't go slower by paying tech debt. We went actually faster, because we were constantly in that code, and now we didn't have to run into problems." — Lou Franco   Lou's understanding of tech debt crystallized during an exit interview at Atalasoft, a small startup where he'd spent years. An engineer leaving the company confronted him: "You guys don't care about tech debt." Lou had been focused on shipping features, believing that paying tech debt would slow them down. But this engineer told a different story — when they finally fixed their terrible build and installation system, they actually sped up. They were constantly touching that code, and removing the friction made everything easier. This moment revealed a fundamental truth: tech debt isn't just about code quality or engineering pride. It's about velocity, momentum, and the ability to move fast sustainably. Lou carried this lesson through his career at Trello (where he learned the dangers of rewriting too much) and Atlassian (where he saw enterprise-scale tech debt management). These experiences became the foundation for "Swimming in Tech Debt." Tech Debt Is the Result of Success "Tech debt is often the result of success. Unsuccessful projects don't have tech debt." — Lou Franco   This reframes the entire conversation about tech debt. Failed products don't accumulate debt — they disappear before it matters. Tech debt emerges when your code survives long enough to outlive its original assumptions, when your user base grows beyond initial expectations, when your team scales faster than your architecture anticipated. At Atalasoft, they built for 10 users and got 100. At Trello, mobile usage exploded beyond their web-first assumptions. Success creates tech debt by changing the context in which code operates. This means tech debt conversations should happen at different intensities depending on where you are in the product lifecycle. Early startups pursuing product-market fit should minimize tech debt investments — move fast, learn, potentially throw away the code. Growth-stage companies need balanced approaches. Mature products benefit significantly from tech debt investments because operational efficiency compounds over years. Understanding this lifecycle perspective helps teams make appropriate decisions rather than applying one-size-fits-all rules. The 8 Questions Framework for Tech Debt Decisions "Those 8 questions guide you to what you should do. If it's risky, has regressions, and you don't even know if it's gonna work, this is when you're gonna do a project spike." — Lou Franco   Lou introduces a systematic framework for evaluating whether to pay tech debt, inspired by Bob Moesta's push-pull forces from product management. The 8 questions create a complete picture:   Visibility — Will people outside the team understand what we're doing? Alignment — Does this match our engineering values and target architecture? Resistance — How hard is this code to work with right now? Volatility — How often do we touch this code? Regression Risk — What's the chance we'll introduce new problems? Project Size — How big is this to fix? Estimate Risk — How uncertain are we about the effort required? Outcome Uncertainty — How confident are we the fix will actually improve things?   High volatility and high resistance with low regression risk? Pay the debt now. High regression risk with no tests? Write tests first, then reassess. Uncertain outcomes on a big project? Do a spike or proof of concept. The framework prevents both extremes — ignoring costly debt and undertaking risky rewrites without proper preparation. Personal Practices That Compound Daily "When I sit down at my desk, the first thing I do is I pay a little tech debt. I'm looking at code, I'm about to change it, do I even understand it? Am I having some kind of resistance to it? Put in a little helpful comment, maybe a little refactoring." — Lou Franco   Lou shares personal habits that create compounding improvements over time. Start each coding session by paying a small amount of tech debt in the area you're about to work — add a clarifying comment, extract a confusing variable, improve a function name. This warms you up, reduces friction for your actual work, and leaves the code slightly better than you found it. The clean-as-you-go philosophy means tech debt never accumulates faster than you can manage it. But Lou's most powerful practice comes at the end of each session: mutation testing by hand. Before finishing for the day, deliberately break something — change a plus to minus, a less-than to less-than-or-equal. See if tests catch it. Often they don't, revealing gaps in test coverage. The key insight: don't fix it immediately. Leave that failing test as the bridge to tomorrow's coding session. It connects today's momentum to tomorrow's work, ensuring you always start with context and purpose rather than cold-starting each day. Mutation Testing: Breaking Things on Purpose "Before I'm done working on a coding session, I break something on purpose. I'll change a plus to a minus, a less than to a less than equals, and see if tests break. A lot of times tests don't break. Now you've found a problem in your test." — Lou Franco   Manual mutation testing — deliberately breaking code to verify tests catch the break — reveals a critical gap in most test suites. You can have 100% code coverage and still have untested behavior. A line of code that's executed during tests isn't necessarily tested — the test might not actually verify what that line does. By changing operators, flipping booleans, or altering constants, you discover whether your tests protect against actual logic errors or just exercise code paths. Lou recommends doing this manually as part of your daily practice, but automated tools exist for systematic discovery: Stryker (for JavaScript, C#, Scala) and MutMut (for Python) can mutate your entire codebase and report which mutations survive uncaught. This isn't just about test quality — it's about understanding what your code actually does and building confidence that changes won't introduce subtle bugs. Team-Level Practices: Budgets, Backlogs, and Target Architecture "Create a target architecture document — where would we be if we started over today? Every PR is an opportunity to move slightly toward that target." — Lou Franco   At the team level, Lou advocates for three interconnected practices. First, create a target architecture document that describes where you'd be if starting fresh today — not a detailed design, but architectural patterns, technology choices, and structural principles that represent current best practices. This isn't a rewrite plan; it's a North Star. Every pull request becomes an opportunity to move incrementally toward that target when touching relevant code. Second, establish a budget split between PM-led feature work and engineering-led tech debt work — perhaps 80/20 or whatever ratio fits your product lifecycle stage. This creates predictable capacity for tech debt without requiring constant negotiation. Third, hold quarterly tech debt backlog meetings separate from sprint planning. Treat this backlog like PMs treat product discovery — explore options, estimate impacts, prioritize based on the 8 Questions framework. Some items fit in sprints; others require dedicated engineers for a quarter or two. This systematic approach prevents tech debt from being perpetually deprioritized while avoiding the opposite extreme of engineers disappearing into six-month "improvement" projects with no visible progress. The Atlassian Five-Alarm Fire "The Atlassian CTO's 'five-alarm fire' — stopping all feature development to focus on reliability. I reduced sync errors by 75% during that initiative." — Lou Franco   Lou shares a powerful example of leadership-driven tech debt management at scale. The Atlassian CTO called a "five-alarm fire" — halting all feature development across the company to focus exclusively on reliability and tech debt. This wasn't panic; it was strategic recognition that accumulated debt threatened the business. Lou worked on reducing sync errors, achieving a 75% reduction during this focused period. The initiative demonstrated several leadership principles: willingness to make hard calls that stop revenue-generating feature work, clear communication of why reliability matters strategically, trust that teams will use the time wisely, and commitment to see it through despite pressure to resume features. This level of intervention is rare and shouldn't be frequent, but it shows what's possible when leadership truly prioritizes tech debt. More commonly, leaders should express product lifecycle constraints (startup urgency vs. mature product stability), give teams autonomy to find appropriate projects within those constraints, and require accountability through visible metrics and dashboards that show progress. The Rewrite Trap: Why Big Rewrites Usually Fail "A system that took 10 years to write has implicit knowledge that can't be replicated in 6 months. I'm mostly gonna advocate for piecemeal migrations along the way, reducing the size of the problem over time." — Lou Franco   Lou lived through Trello's iOS navigation rewrite — a classic example of throwing away working code to start fresh, only to discover all the edge cases, implicit behaviors, and user expectations baked into the "old" system. A codebase that evolved over several years contains implicit knowledge — user workflows, edge case handling, performance optimizations, and subtle behaviors that users rely on even if they never explicitly requested them. Attempting to rewrite this in six months inevitably misses critical details. Lou strongly advocates for piecemeal migrations instead. The Trello "Decaffeinate Project" exemplifies this approach — migrating from CoffeeScript to TypeScript incrementally, with public dashboards showing the percentage remaining, interoperable technologies allowing gradual transition, and the ability to pause or reverse if needed. Keep both systems running in parallel during migrations. Use runtime observability to verify new code behaves identically to old code. Reduce the problem size steadily over months rather than attempting big-bang replacements. The only exception: sometimes keeping parallel systems requires scaffolding that creates its own complexity, so evaluate whether piecemeal migration is actually simpler or if you're better off living with the current system. Making Tech Debt Visible Through Dashboards "Put up a dashboard, showing it happen. Make invisible internal improvements visible through metrics engineering leadership understands." — Lou Franco   One of tech debt's biggest challenges is invisibility — non-technical stakeholders can't see the improvement from refactoring or test coverage. Lou learned to make tech debt work visible through dashboards and metrics. The Decaffeinate Project tracked percentage of CoffeeScript files remaining, providing a clear progress indicator anyone could understand. When reducing sync errors, Lou created dashboards showing error rates declining over time. These visualizations serve multiple purposes: they demonstrate value to leadership, create accountability for engineering teams, build momentum as progress becomes visible, and help teams celebrate wins that would otherwise go unnoticed. The key is choosing metrics that matter to the business — error rates, page load times, deployment frequency, mean time to recovery — rather than pure code quality metrics like cyclomatic complexity that don't translate outside engineering. Connect tech debt work to customer experience, reliability, or developer productivity in ways leadership can see and value. Onboarding as a Tech Debt Opportunity "Unit testing is a really great way to learn a system. It's like an executable specification that's helping you prove that you understand the system." — Lou Franco   Lou identifies onboarding as an underutilized opportunity for tech debt reduction. When new engineers join, they need to learn the codebase. Rather than just reading code or shadowing, Lou suggests having them write unit tests in areas they're learning. This serves dual purposes: tests are executable specifications that prove understanding of system behavior, and they create safety nets in areas that likely lack coverage (otherwise, why would new engineers be confused by the code?). The new engineer gets hands-on learning, the team gets better test coverage, and everyone wins. This practice also surfaces confusing code — if new engineers struggle to understand what to test, that's a signal the code needs clarifying comments, better naming, or refactoring. Make onboarding a systematic tech debt reduction opportunity rather than passive knowledge transfer. Leadership's Role: Constraints, Autonomy, and Accountability "Leadership needs to express the constraints. Tell the team what you're feeling about tech debt at a high level, and what you think generally is the appropriate amount of time to be spent on it. Then give them autonomy." — Lou Franco   Lou distills leadership's role in tech debt management to three elements. First, express constraints — communicate where you believe the product is in its lifecycle (early startup, rapid growth, mature cash cow) and what that means for tech debt tolerance. Are we pursuing product-market fit where code might be thrown away? Are we scaling a proven product where reliability matters? Are we maintaining a stable system where operational efficiency pays dividends? These constraints help teams make appropriate trade-offs. Second, give autonomy — once constraints are clear, trust teams to identify specific tech debt projects that fit those constraints. Engineers understand the codebase's pain points better than leaders do. Third, require accountability — teams must make their work visible through dashboards, metrics, and regular updates. Autonomy without accountability becomes invisible engineering projects that might not deliver value. Accountability without autonomy becomes micromanagement that wastes engineering judgment. The balance creates space for teams to make smart decisions while keeping leadership informed and confident in the investment. AI and the Future of Tech Debt "I really do AI-assisted software engineering. And by that, I mean I 100% review every single line of that code. I write the tests, and all the code is as I would have written it, it's just a lot faster. Developers are still responsible for it. Read the code." — Lou Franco   Lou has a chapter about AI in his book, addressing the elephant in the room: will AI-generated code create massive tech debt? His answer is nuanced. AI can accelerate development tremendously if used correctly — Lou uses it extensively but reviews every single line, writes all tests himself, and ensures the code matches what he would have written manually. The problem emerges with "vibe coders" — non-developers using AI to generate code they don't understand, creating unmaintainable messes that become someone else's problem. Developers remain responsible for all code, regardless of how it's generated. This means you must read and understand AI-generated code, not blindly accept it. Lou also raises supply chain security concerns — dependencies can contain malicious code, and AI might introduce vulnerabilities developers miss. His recommendation: stay six months behind on dependency updates, let others discover the problems first, and consider separate sandboxed development machines to limit security exposure. AI is a powerful tool, but it doesn't eliminate the need for engineering judgment, testing discipline, or code review practices. The Style Guide Beyond Formatting "Have a style guide that goes beyond formatting to include target architecture. This is the kind of code we want to write going forward." — Lou Franco   Lou advocates for style guides that extend beyond tabs-versus-spaces formatting rules to include architectural guidance. Document patterns you want to move toward: how should components be structured, what state management approaches do we prefer, how should we handle errors, what testing patterns should we follow? This creates a shared understanding of the target architecture without requiring a massive design document. When reviewing pull requests, teams can reference the style guide to explain why certain approaches align with where the codebase is headed versus perpetuating old patterns. This makes tech debt conversations less personal and more objective — it's not about criticizing someone's code, it's about aligning with team standards and strategic direction. The style guide becomes a living document that evolves as the team learns and technology changes, capturing collective wisdom about what good code looks like in your specific context. Recommended Resources Some of the resources mentioned in this episode include:  Steve Blank's Four Steps To Epiphany The podcast episode with Bernie Maloney where we discuss the critical difference between "enterprise" and "startup". And Geoffrey Moore's Crossing the Chasm, and Dealing with Darwin.   About Lou Franco   Lou Franco is a veteran software engineer and author of Swimming in Tech Debt. With decades of experience at startups, as well as Trello, and Atlassian, he's seen both sides of debt—as coder and leader. Today, he advises teams on engineering practices, helping them turn messy codebases into momentum.   You can link with Lou Franco on LinkedIn and learn more at LouFranco.com.

I know you're out there. The developer who watches their colleagues enthusiastically embrace Claude Code and Cursor, having AI write entire feature sets while you proudly type every semicolon by hand. The founder who sees AI-generated code as a ticking time bomb of bugs and security vulnerabilities. The software entrepreneur who believes that real code comes from human minds, not language models.This one's for you.This episode of The Bootstraped Founder is sponsored by Paddle.comYou'll find the Black Friday Guide here: https://www.paddle.com/learn/grow-beyond-black-fridayThe blog post: https://thebootstrappedfounder.com/ai-for-the-code-writing-purist-how-to-use-ai-without-surrendering-your-keyboard/The podcast episode:  https://tbf.fm/episodes/420-ai-for-the-code-writing-purist-how-to-use-ai-without-surrendering-your-keyboardCheck out Podscan, the Podcast database that transcribes every podcast episode out there minutes after it gets released: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

We're living through a fascinating moment in software development. AI coding tools can build features faster than ever before. They can scan entire codebases, spot things we might miss, and implement changes across dozens of files in seconds. It's incredible.But there's something we need to talk about. Something that's quietly accumulating in our projects while we marvel at how quickly we can ship features.This is called comprehension debt.This episode of The Bootstraped Founder is sponsored by Paddle.comThe blog post: https://thebootstrappedfounder.com/why-ai-generated-code-hurts-your-exit/The podcast episode: https://tbf.fm/episodes/418-why-ai-generated-code-hurts-your-exitCheck out Podscan, the Podcast database that transcribes every podcast episode out there minutes after it gets released: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

This week, we're off to a very near-future Tokyo for Happyend, in which a bunch of clubbing-mad high school teens turn rabblerousers when their headmaster installs a sinister surveillance system in their school, which mirrors the darkening political situation unfolding beyond the school gates. We also take a look at the documentary Power Station, which sees an artist couple try to tackle the fuel poverty crisis in their local community by turning their street into a literal and metaphorical power station.  Power Station opens the community-minded Take One Action film festival, which leads us on to discuss some of the other film festivals coming to Scotland over the next wee while, from the Glasgow Youth Film Festival to a touring programme of highlights from the London Film Festival. TIMESTAMPS: What We've Been Watching: The Horse Whisperer, The Guns of Navarone, Weapons, Raising Arizona and The Secret Garden (1:05) Happyend review (13:14) Power Station n review (36:54) Smaller film fests: Take One Action, LFF on tour, IberoDocs and GYFF (37:40) Recorded on location in the Codebase meeting room with the lovely chairs. Get us on Twitter, Bluesky, Instagram and Letterboxd  @thecineskinny, email us at cineskinny@theskinny.co.uk Intro and interstitial music: Too Cool by Kevin MacLeod (https://incompetech.filmmusic.io/song/4534-too-cool) License: https://filmmusic.io/standard-license

For episode 594 of the BlockHash Podcast, host Brandon Zemp is joined by Michael Martin of Codebase, Avalanche’s flagship incubator, which is a launchpad for testing ideas, building products and scaling your Web3 Startup. ⏳ Timestamps: (0:00) Introduction(0:30) Who is Michael Martin?(4:35) What is Codebase?(13:28) Codebase at Permissionless(16:48) RWAs on Avalanche(22:16) Learn more about Codebase & Avalanche

Today! The Edinburgh International Film Festival starts today (if you're listening to this podcast the day it comes out, which you should), so Peter, Jamie and Ellie take a closer look at three films from the programme. We've got Canary Islands-based family mystery Islands, Charlie Shackleton's new metadoc Zodiac Killer Project, and The Golden Spurtle, 75 delightful minutes following the World Porridge Championships. All that, and a few more picks and tips from your extremely warm friends in the studio... CHAPTERS: Islands review (4:20) Zodiac Killer Project review (20:05) The Golden Spurtle review (36:35) More EIFF picks (50:35) Edinburgh International Film Festival, 14-20 Aug, edfilmfest.org Recorded on location in the Codebase meeting room with the lovely chairs. Get us on Twitter, Bluesky, Instagram and Letterboxd  @thecineskinny, email us at cineskinny@theskinny.co.uk Intro and interstitial music: Too Cool by Kevin MacLeod (https://incompetech.filmmusic.io/song/4534-too-cool) License: https://filmmusic.io/standard-license

In this episode, the team was bowled over by Dreams, part of a new arthouse trilogy by Norwegian writer-director Dag Johan Haugerud called The Oslo Stories Trilogy (not to be confused with Joachim Trier's similarly named Oslo Trilogy). The other two instalments - Love and Sex - are released later in August. Dreams got us talking about our favourite trilogies in general, from the first three Toy Story movies to Richard Linklater's Before... films via Edgar Wright's Cornetto trilogy. We also squeeze in a review of stop-motion film Savages, the long-awaited new work from Belgian director Claude Barras, best known for his bruising coming-of-age animation My Life as a Courgette.  TIMESTAMPS: What We've Been Watching: Female Perversion, Legally Blonde the Musical, Safe and Lena Dunham's new series Too Much (02:44) Savages review (15:23) Dreams review (27:52) Movie Trilogies: What are they, and which ones do we love? (46:25) Recorded on location in the Codebase meeting room with the lovely chairs. Get us on Twitter, Bluesky, Instagram and Letterboxd  @thecineskinny, email us at cineskinny@theskinny.co.uk Intro and interstitial music: Too Cool by Kevin MacLeod (https://incompetech.filmmusic.io/song/4534-too-cool) License: https://filmmusic.io/standard-license

On this week's podcast, we head off in two *completely* different directions – the gang review art doc/biopic hybrid The Ballad of Suzanne Césaire, then Anahit sings the praises of the new Superman movie. Cinema - it truly has a bit of everything. Elsewhere, Jamie reports back from Karlovy Vary Film Festival in his fresh KVIFF t-shirt, the squad discuss the idea of cult cinema (what is it, good examples, etc etc), and a few more bits and bobs. A good pod, come hang out. TIMESTAMPS: Jamie's KVIFF recap (1:15) What We've Been Watching: Sidney Lumet, The Parent Trap (10:05) The Ballad of Suzanne Césaire review (19:10) Superman review (37:00) Cult Films: What Are They, and Why? (50:45) Recorded on location in the Codebase meeting room with the lovely chairs. Get us on Twitter, Bluesky, Instagram and Letterboxd  @thecineskinny, email us at cineskinny@theskinny.co.uk Intro and interstitial music: Too Cool by Kevin MacLeod (https://incompetech.filmmusic.io/song/4534-too-cool) License: https://filmmusic.io/standard-license

These principles don't just create pretty code—they reduce bugs, simplify updates, and prevent real-world problems like the $10,000 mistake I made early in my career.Yeah, that was not a fun one.Check out https://www.dofactory.com/javascript/design-patterns/adapter if you want to learn more patterns.PS - I write unfiltered advice for early career developers here:

In this episode, Dan and I (Steve) dove deep into what turned out to be a surprisingly complex, yet incredibly insightful topic: gradually migrating a massive legacy JavaScript project over to TypeScript. We're talking about nearly 1,000 JS files, 70,000+ lines of code, and years of developer history—all transitioning carefully to a typed, modern future.Dan walked us through how he started by setting up the project for success before converting even one file—getting CI/CD ready, setting up tsconfig.json, sorting out test dependencies, dealing with mock leaks, and even grappling with quirks between VS Code and WebStorm debugging.We talked tools (like TS-ESLint, concurrently, and ts-node), why strict typing actually uncovered real bugs (and made the code better!), and why it's crucial not to touch any .js files until your TypeScript setup is rock solid.Key Takeaways:Gradual migration is 100% possible—and often better—than ripping the bandaid off.TypeScript can and will catch bugs hiding in your JavaScript. Be prepared!Use VS Code extensions or TS-Node to support your devs' tooling preferences.Don't underestimate the setup phase—it's the foundation of long-term success.Start small: Dan's team converted just one file at first to test the whole pipeline.If you're sitting on a legacy JS project and dreaming of TypeScript, this episode is your blueprint—and your warning sign.Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Large language models are helping developers move faster than ever. But behind the convenience of AI-generated code lies a security vulnerability: package hallucinations. In this episode, Ashok sits down with U.S. Army cybersecurity officer and PhD researcher Joe Spracklen to unpack new research on how hallucinated package names—fake libraries that don't yet exist—can be weaponized by attackers and quietly introduced into your software supply chain. Joe's recent academic study reveals how large language models like ChatGPT and Code Llama are frequently recommending software packages that don't actually exist—yet. These fake suggestions create the perfect opportunity for attackers to register malicious packages with those names, compromising developer machines and potentially entire corporate networks. Whether your team is deep into AI pair programming or just starting to experiment, this conversation surfaces key questions every tech leader should be asking before pushing AI-generated code to production. Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Inside the episode... What "package hallucinations" are and why they matter How AI code assistants can introduce real vulnerabilities into your network Which models were most likely to hallucinate packages Why hallucinated package names are often persistent—not random How attackers could weaponize hallucinated names to spread malware What mitigation strategies were tested—and which ones failed Why simple retrieval-based techniques (like RAG) don't solve the problem Steps security-conscious teams can take today to protect their environments The importance of developer awareness as more non-traditional engineers enter the field Mentioned in this episode Python Package Index (PyPI) npm JavaScript package registry Snyk, Socket.dev, Phylum (dependency monitoring tools) Artifactory, Nexus, Verdaccio (private package registries) ChatGPT, Code Llama, DeepSeek (AI models tested) Subscribe to the Convergence podcast wherever you get podcasts including video episodes on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow. Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Subscribe to the Convergence podcast wherever you get podcasts including video episodes to get updated on the other crucial conversations that we'll post on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow.   Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence

Thank you for joining me again as we continue this new journey together. Today's set is a daytime exploration, starting with dreamy soundscapes and warm, melodic grooves. We'll flow through soulful classics before building into vibrant, uplifting rhythms. It's a lighter, more reflective journey designed to brighten your day and spark your imagination. In this episode, you'll hear music from Sneaker Pimps, Codebase, Orbital, Alex Smoke and many others. Tracklist 01 Max Scholpp - The Dream 02 Âme - Shiro 03 Sneaker Pimps - Post Modern Sleaze (Salt City Orchestra Nightclub Mix) 04 AN-2 - Road Through The Rain 05 Codebase - Seek and Destroy 06 Unit 4 - Bodydub (Tiefschwarz Remix) 07 Orbital - Walk Now... 08 Cobblestone Jazz - Dump Truck 09 Silicone Soul - Les Nocturnes 10 Bent - Exercise 5 11 Basic Soul Unit - Things Pass 12 Roman Flügel - Brian Le Bon 13 Alex Smoke - Don't See the Point 14 D5 - Floatation Tank 15 Extrawelt - Pink Panzer 16 Jürgen Paape - Mit Dir https://www.facebook.com/lowfrequencypodcast https://www.facebook.com/itsmestevedj https://soundcloud.com/st-eve_dj

Send us a textBusiness did not come kindly to Gunjan Saini Bradshaw and that is exactly what shaped her into the powerful entrepreneur she is today. From her beginnings as a TV and radio host in India to co-founding a thriving tech company across India and the United States, Gunjan's story is one of bold pivots, resilience and redefining leadership. In this episode of the Badass Women in Business podcast, Gunjan shares how she built Codebase alongside her husband, navigated cultural and gender barriers, and turned personal challenges into a global success story.Whether you are scaling a startup, breaking into tech, or balancing business with personal life, Gunjan's raw and real insights will inspire you to embrace change, trust your instincts and lead with both heart and grit.Show NotesWelcome Gunjan Saini BradshawGunjan's early career path from journalism and marketing in India to the entertainment worldHow business "happened" unexpectedly through her relationship with her now husband and business partnerThe story behind Codebase, a fully bootstrapped journey connecting Indian tech talent with US venture-backed companiesNavigating the transition from TV to tech, India to Utah, and from dating to building a business togetherFinding her voice as a non-technical co-founder and earning respect in a male-dominated industryBridging cultural differences between India and the United States and building strong cross-cultural teamsWhy staying bootstrapped mattered and how it helped preserve the company's vision and valuesCommitment to excellence by focusing only on hiring A players and redefining offshore collaborationLessons learned about resilience, adaptability, leadership and trusting yourself when the path is unclearKey TakeawaysYour gender should never define your potential or leadership presenceBootstrapping can build a strong foundation even if it means growing slowerUnderstanding cultural nuance is critical for building international teamsFounders must wear multiple hats and continuously evolve based on the needs of the businessTrue success is not about avoiding failure but about embracing challenges as opportunities to growFavorite Quotes“You are not your gender, you are a person. Hustle, grind and lead without the baggage.” “Business life did not come kindly to me, but that is where I found my true strength.” “Building a dream should never be limited by capital. It is about smart, scrappy collaboration.”Contact InformationWebsite: CodebaseLinkedIn: Gunjan Saini BradshawInstagram: @goofwomanKeep up with more content from Aggie and Cristy here: Facebook: Empowered Women Leaders Instagram: @badass_women_in_business LinkedIn: ProveHer - Badass Women in Business Website: Badasswomeninbusinesspodcast.com Athena: athenaac.com

Welcome to another episode of Entrepreneur Weekly with Alan Taylor who is at the SheTech Event 2025 took place at the Mountain America Expo Center, featuring insights from Ryan Starks of the Governor's Office for Economic Opportunity. He highlighted Utah's strong economic environment, praised community support for training future leaders, and discussed efforts to mentor students. The office focuses on business growth, entrepreneurship, and tourism, contributing to job creation and household tax relief. John Bradshaw, host of the Venture Capital Podcast, joined the event to promote opportunities for women. Drawing from his experiences of having nine nieces and his childhood interests, he emphasized breaking traditional gender roles. He encouraged young girls to explore diverse paths and shared details about his software company, Codebase.com, which is committed to creating opportunities for future generations. Jerry Henley leads the Utah Innovation Fund, managing a $30 million fund that invests around $250,000 in promising university startups across Utah. The state aims to boost its entrepreneurial ecosystem with a planned 225,000 square foot Innovation Center to support over 300 startups. Henley is optimistic about engaging more local entrepreneurs. The fund's team, under Executive Director Jeff Moss, is notably diverse, with four out of six members being women. Kat Kennedy from Kickstart Fund joined Alan to discuss a STEM education and entrepreneurship event that encouraged hands-on technology creation. Alan shared a personal story about nurturing young people's risk-taking and resilience. The event also focused on women's challenges in entrepreneurship and the need for supportive environments. Overall, it highlighted the importance of practical experience in developing future leaders in technology and business. McKay Christensen, CEO of Thanksgiving Point, discussed the organization's mission to empower children through confidence-building STEM programs. He highlighted the significant disparity in STEM career pursuits based on socioeconomic status in Utah: 31% of children from high-income households pursue STEM careers compared to only 7% from low-income backgrounds. To support disadvantaged youth, Thanksgiving Point provides free access to its science centers for families receiving public assistance like WIC or SNAP, aiming to spark interest and confidence in STEM. Tara Rosander shared her experiences at the recent SheTech event attended by over 3,000 girls. She emphasized the importance of mentorship with a 3 to 1 mentor-to-girl ratio, suggesting more frequent events to expand their impact. Tara recounted a success story of a girl who, after attending SheTech, pursued a STEM degree and received five job offers after presenting at an event. She expressed pride in how the program empowers future generations. [00:00:00] Ryan Starks – Governor's Office of Economic Opportunity . [00:07:23] John Bradshaw – Venture Capital Podcast [00:11:28] Jerry Henley – Utah Innovation Fund [00:19:18] Kat Kennedy – Kickstart Fund [00:26:21] McKay Christensen – CEO of Thanksgiving Point [00:34:51] Tara Rosander – Managing Director of Exceed Consulting Learn more about your ad choices. Visit megaphone.fm/adchoices

Eighteen TV platforms, one codebase—what could possibly go wrong? Tune in to find out how to tackle the technical and UX challenges of building for Android TV, Apple TV, Fire TV, Tizen, and more—all with React Native! In the 49th episode of React Universe On Air, Łukasz Chludziński (https://x.com/lukasz_app) teams up with Michael Khirallah (https://x.com/mkralla11), Senior Director of Engineering at DIRECTV, and Chris Trag (https://x.com/chris_trag), Developer Evangelist at Amazon, to discuss why cross-platform development is not just a time-saver but also a way to deliver a consistent user experience. You know that at Callstack, we're all about performance—and with devices like Samsung's Tizen TVs released in 2017 (running Chromium 47!), performance is a serious concern. That's why we asked our guests to share real-world techniques for optimizing TV apps, from architectural choices to strategies that avoid unnecessary performance hits on newer devices. The complexity of TV app development doesn't stop at coding, though. Our host and guests know it all to well, so they couldn't help but discuss how they balance unit, integration, automation, and manual testing, leveraging tools like AWS Device Farm and custom-built frameworks to ensure stability across all supported platforms. What's in it for you? Tips on automating QA without compromising thoroughness and why manual testing remains crucial for end-user experience. Want to get started with React Native TV app development? Download our guide

In this episode David Rubinstein interviews Eran Yahav, co-founder and CTO of Tabnine, about why its important to provide AI assistants with clean code.They discuss: The importance of defining organizational rules and best practices to guide the AIHow to use AI-assisted refactoring to improve legacy codebasesIf organizations should apply KonMari principles to their codebases

After 10 years and 550 episodes of Giant Robots, Chad and Sami are ready to discuss what's next for the podcast. The pair dive into some podcast role-play as they test out some ideas for iterating the show's formula. Peek behind the curtain as they discuss the inner workings of the show, the challenges of working on a mature codebase, how thoughtbot tackles impostor syndrome when onboarding new employees and the developing accessibility of AI. — Your hosts for this episode have been Chad Pytel and Sami Birnbaum. You can find Chad all over social media as @cpytel, or over on LinkedIn (https://www.linkedin.com/in/cpytel/). Sami can be found through his website (https://samibirnbaum.com) or via LinkedIn (https://www.linkedin.com/in/samibirnbaum/). — If you would like to support the show, head over to our GitHub page (https://github.com/sponsors/thoughtbot), or check out our website (https://podcast.thoughtbot.com). Got a question or comment about the show? Why not write to our hosts: hosts@giantrobots.fm This has been a thoughtbot (https://thoughtbot.com/) podcast. Stay up to date by following us on social media - LinkedIn (https://www.linkedin.com/company/150727/) - Mastodon (https://thoughtbot.social/@thoughtbot) - Instagram (https://www.instagram.com/thoughtbot/) © 2024 thoughtbot, inc.

In this episode of the podcast, we look at how we can get started analyzing an existing codebase in Java. Check out our courses at ⁠⁠⁠⁠⁠⁠⁠https://courses.javaeasily.com⁠⁠⁠⁠⁠⁠⁠ Get your Java Beginner's Starter Kit over at ⁠⁠⁠⁠⁠⁠⁠https://javaeasily.com⁠⁠⁠⁠⁠⁠⁠ This is the Java Easily Podcast where beginning and intermediate Java developers can get all the latest tips, tutorials and advice on Java software development.

Episode 32: How can you build an app with a backend using AI in just 20 minutes? Matt Wolfe (https://x.com/mreflow) and Nathan Lands (https://x.com/NathanLands) sit down with AI enthusiast Riley Brown (https://x.com/rileybrown_ai) to explore this exciting and challenging process. In this episode, Riley brings his unique perspective and experience, from a non-coder to a developer leveraging AI tools. The discussion covers Riley's journey, the tools he recommends for beginners, like Cursor and Replit, and the integration with Firebase for seamless app development. They venture into creating a simple web app, discuss the evolution of app capabilities, and contemplate innovative features and platforms driven by AI. Whether you're a novice or an experienced developer, this episode offers a wealth of insights and practical advice. Check out The Next Wave YouTube Channel if you want to see Matt and Nathan on screen: https://lnk.to/thenextwavepd — Show Notes: (00:00) Riley Brown shares app-building methods, templates. (04:15) Using Claude artifacts for code generation amazed me. (08:35) Start with Cursor, avoid multiple tool distractions. (09:34) Codebase setup using SSH for syncing changes. (12:55) AI integrates and updates code in steps. (17:49) App to log and track AI skill development. (20:04) Tools: Cursor, Firebase, Replit for project management. (25:12) Discusses free use of Replit, Firebase, Cursor. (27:32) App for threading voice notes and AI formatting. (30:58) Appreciating design effort; seeking AI improvement. (33:31) Building community to create apps efficiently. (35:20) Follow Riley Brown on X, subscribe YouTube. — Mentions: Riley Brown: https://community.softwarecomposer.com/c/templates/replit-templates https://replit.com/@an732001/Riley-and-Ansh-Full-Stack-Nextjs-Template-version-1?v=1#README.md Software Composer: https://www.softwarecomposer.com/ Cursor: https://www.cursor.so/ Replit: https://replit.com/ Firebase: https://firebase.google.com/ Midjourney: https://www.midjourney.com/ Claude: https://www.anthropic.com/index/claude Wispr Flow: https://www.flowvoice.ai/ — Check Out Matt's Stuff: • Future Tools - https://futuretools.beehiiv.com/ • Blog - https://www.mattwolfe.com/ • YouTube- https://www.youtube.com/@mreflow — Check Out Nathan's Stuff: Newsletter: https://news.lore.com/ Blog - https://lore.com/ The Next Wave is a HubSpot Original Podcast // Brought to you by The HubSpot Podcast Network // Production by Darren Clarke // Editing by Ezra Bakker Trupiano

In this episode of Book Overflow, Carter and Nathan discuss Tidy First? by Kent Beck. Join them as they discuss when you should prioritize tidying your code over feature improvements, what tidying means, and the Beck's thoughts on software and the time value of money! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- Tidy First?: A Personal Exercise in Empirical Software Design by Kent Beck https://amzn.to/40uOEtL (paid link) Refactoring: Improving the Design of Existing Code (2nd Edition) by Martin Fowler https://amzn.to/3C9d5mq (paid link) Building Evolutionary Architectures: Automated Software Governance by Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage https://amzn.to/4fmoIVC (paid link) A Philosophy of Software Design, 2nd Edition by John Ousterhout https://amzn.to/4ecmYgv (paid link) The Practice of Programming by Brian Kernighan, Rob Pike https://amzn.to/4fuMP4b (paid link) ---------------- 00:00 Intro 03:14 About the Book 05:41 Thoughts on the Book 11:17 Techniques and Approaches for Tidying (Part 1) 36:20 How to prioritize and manage tidying tasks (Part 2) 47:30 Optionality, Reversibility and The Philosophy of Tidying (Part 3) 01:05:38 Final Thoughts ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

Jimmy Miller talks to us about his experience with a legacy codebase at his first job as a programmer. The codebase was massive, with hundreds of thousands of lines of C# and Visual Basic, and a database with over 1,000 columns. Let's just say Jimmy got into some stuff. There's even a Gilfoyle involved. This episode is all about his adventures while working there.

Jimmy Miller talks to us about his experience with a legacy codebase at his first job as a programmer. The codebase was massive, with hundreds of thousands of lines of C# and Visual Basic, and a database with over 1,000 columns. Let's just say Jimmy got into some stuff. There's even a Gilfoyle involved. This episode is all about his adventures while working there.

Jimmy Miller tells us about the best, worst codebase he's ever seen, The Phylum Research Team follows up on the great npm garbage patch, Zach Leatherman logs his findings on sneaky serverless costs, David Cain wants you to go on quests instead of goals & Ashley Janssen gives us szeven rules for effective meeting culture.

Jimmy Miller tells us about the best, worst codebase he's ever seen, The Phylum Research Team follows up on the great npm garbage patch, Zach Leatherman logs his findings on sneaky serverless costs, David Cain wants you to go on quests instead of goals & Ashley Janssen gives us szeven rules for effective meeting culture.

Jimmy Miller tells us about the best, worst codebase he's ever seen, The Phylum Research Team follows up on the great npm garbage patch, Zach Leatherman logs his findings on sneaky serverless costs, David Cain wants you to go on quests instead of goals & Ashley Janssen gives us szeven rules for effective meeting culture.

Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: Causal Graphs of GPT-2-Small's Residual Stream, published by David Udell on July 10, 2024 on LessWrong. Thanks to the many people I've chatted with this about over the past many months. And special thanks to Cunningham et al., Marks et al., Joseph Bloom, Trenton Bricken, Adrià Garriga-Alonso, and Johnny Lin, for crucial research artefacts and/or feedback. Codebase: sparse_circuit_discovery TL; DR: The residual stream in GPT-2-small, expanded with sparse autoencoders and systematically ablated, looks like the working memory of a forward pass. A few high-magnitude features causally propagate themselves through the model during inference, and these features are interpretable. We can see where in the forward pass, due to which transformer layer, those propagating features are written in and/or scrubbed out. Introduction What is GPT-2-small thinking about during an arbitrary forward pass? I've been trying to isolate legible model circuits using sparse autoencoders. I was inspired by the following example, from the end of Cunningham et al. (2023): I wanted to see whether naturalistic transformers[1] are generally this interpretable as circuits under sparse autoencoding. If this level of interpretability just abounds, then high-quality LLM mindreading & mindcontrol is in hand! If not, could I show how far we are from that kind of mindreading technology? Related Work As mentioned, I was led into this project by Cunningham et al. (2023), which established key early results about sparse autoencoding for LLM interpretability. While I was working on this, Marks et al. (2024) developed an algorithm approximating the same causal graphs in constant time. Their result is what would make this scalable and squelch down the iteration loop on interpreting forward passes. Methodology A sparse autoencoder is a linear map, whose shape is (autoencoder_dim, model_dim). I install sparse autoencoders at all of GPT-2-small's residual streams (one per model layer, 12 in total). Each sits at a pre_resid bottleneck that all prior information in that forward pass routes through.[2] I fix a context, and choose one forward pass of interest in that context. In every autoencoder, I go through and independently ablate out all of the dimensions in autoencoder_dim during a "corrupted" forward pass. For every corrupted forward pass with a layer N sparse autoencoder dimension, I cache effects at the layer N+1 autoencoder. Every vector of cached effects can then be reduced to a set of edges in a causal graph. Each edge has a signed scalar weight and connects a node in the layer N autoencoder to a node in the layer N+1 autoencoder. I keep only the top-k magnitude edges from each set of effects NN+1, where k is a number of edges. Then, I keep only the set of edges that form paths with lengths >1.[3] The output of that is a top-k causal graph, showing largest-magnitude internal causal structure in GPT-2-small's residual stream during the forward pass you fixed. Causal Graphs Key Consider the causal graph below: Each box with a bolded label like 5.10603 is a dimension in a sparse autoencoder. 5 is the layer number, while 10603 is its column index in that autoencoder. You can always cross-reference more comprehensive interpretability data for any given dimension on Neuronpedia using those two indices. Below the dimension indices, the blue-to-white highlighted contexts show how strongly a dimension activated following each of the tokens in that context (bluer means stronger). At the bottom of the box, blue or red token boxes show the tokens most promoted (blue) and most suppressed (red) by that dimension. Arrows between boxes plot the causal effects of an ablation on dimensions of the next layer's autoencoder. A red arrow means ablating dimension 1.x will also suppress downstream dimension 2.y. A blue arrow means ...

In this episode, Robby welcomes Robin Heinze, Director of Engineering at Infinite Red, to discuss the intricacies of building and maintaining robust software systems. Key topics covered include:Characteristics of Maintainable Software: Robin shares insights from her team on what makes software maintainable, emphasizing the need for clear documentation, robust setup scripts, and ongoing code refinement.Technical Debt: They delve into managing technical debt, particularly in a consultancy setting, and how to balance client expectations with software quality.React Native: Robin explains the advantages of using React Native for cross-platform development, highlighting its efficiency and accessibility to a broader range of developers.Consultancy Challenges: The conversation also covers the unique aspects of working in a consultancy, including how to embed standards while respecting client processes.Major Takeaways:Effective communication and a proactive approach to maintenance are crucial in software development.Visual elements like graphics can significantly enhance the accessibility and appeal of open source projects.Book Recommendation:A Thursday Murder Club Mystery Series by Richard OsmanHelpful Links:React NativeInfinite RedChain React ConferenceReact Native Radio PodcastFor more insights, make sure to follow Robin on: LinkedInTwitterThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this episode of Maintainable, Robby welcomes Scott Hanselman, VP of Developer Community at Microsoft and host of the Hanselminutes Podcast, to discuss the emotional side of maintainable software. Scott shares his thoughts on fear as a common thread in poorly maintained software, the importance of building a team culture of trust, and how finding a good work-life balance helps create better software.The Role of Fear in Technical DebtScott believes that if you fear the software you work on, it's a tell-tale sign that it has maintainability issues.Technical debt is rooted in fear--either fear of making a change that will break something or fear of being unable to change something when needed.He encourages teams to talk openly about their fears and anxieties regarding the software and to consider what things give them confidence in the codebase.Building a Team Culture of ConfidenceScott emphasizes the importance of empathy in overcoming technical debt and making software more maintainable.Senior engineers and team leads have a responsibility to make junior developers feel safe enough to speak up and ask questions.He advocates for providing new hires with small, achievable tasks to build their confidence and trust in the software.Scott encourages teams to use "inner loop" and "outer loop" thinking.Inner loop - The cycle of making a change, hitting f5, and seeing changes immediately.Outer loop - Things like deploying the codebase, getting it tested, ensuring production stability.Both experienced and junior engineers have their own inner and outer loops as individuals, and continuous improvement at all levels is key.Overcoming Fear, Embracing Maintainability, and Finding BalanceScott shares stories about Microsoft's journey with open-source software and how that process has shaped the company's culture around maintainable code.He talks about the importance of striking a balance between source-opened and open-source software and finding the sweet spot for a project or organization.Scott warns against the trap of striving for unattainable perfection. Aiming for good, solid repeatable work over perfection ultimately yields better results.He uses his own projects, like the Hanselminutes podcast, as examples of focusing on consistent outputs and utilizing a simple workflow.Scott advocates for using AI tools to transcribe coding sessions, freeing up developers from extensive note-taking.Book Recommendation:The Daily Stoic By Ryan HolidayScott Hanselman - Personal WebsiteHanselminutes Podcast.NET Open Source History: .NET Core | Microsoft LearnHelpful Links:Scott Hanselman - Personal WebsiteHanselminutes Podcast.NET Open Source History: .NET Core | Microsoft LearnThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this episode of Maintainable, Robby chats with Stig Brautaset, Staff Software Engineer at CircleCI. Stig shares his insights on maintaining well-documented but complex legacy code, the impact of team dynamics on software maintenance, and his experiences with the SBJSON library.Stig discusses the characteristics of well-maintained software, emphasizing the importance of team experience, domain knowledge, and risk appetite. He reflects on his own career journey, highlighting the transition from overconfidence to a balanced approach to risk-taking.A significant portion of the conversation delves into Stig's concept of "Alien Artifacts," which describes highly resistant legacy code written by highly skilled engineers. He explains the challenges of modifying such code and shares examples from his own experiences.Stig also talks about his work on the SBJSON library, addressing the complexities of handling multiple versions and dependency conflicts. He advocates for developers maintaining the software they ship and discusses the balance between shipping features quickly and maintaining long-term code quality.Key TakeawaysThe influence of team dynamics on software maintenanceUnderstanding the concept of "Alien Artifacts" in legacy codeStrategies for handling multiple versions of a software libraryThe importance of developers being on call for the software they shipManaging different types of technical debtBook Recommendation:The Scout Mindset by Julia GalefStig Brautaset on LinkedInAlien Artifacts Blog PostSBJSON Library CircleCIThe Confident Commit PodcastHelpful Links:Stig Brautaset on LinkedInAlien Artifacts Blog PostSBJSON Library CircleCIThe Confident Commit PodcastWant to share your thoughts on this episode? Reach out to Robby at robby@maintainable.fm.Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Join Robby as he welcomes Brit Myers to the podcast. Brit, currently thriving as the VP of Engineering at System Initiative, discusses the intricacies of maintaining software. She emphasizes the importance of navigable software, where the ease of tracing the code and understanding its structure is paramount. Brit highlights the significance of clear naming conventions and inline documentation, as they help in maintaining a cohesive narrative within the software. The conversation touches on the challenges posed by discrepancies in vocabulary between product management and engineering, and how glossaries can bridge these communication gaps. Brit advocates for the use of glossaries more as a reflective tool rather than a proactive one, given the dynamic nature of software development. She also delves into strategies for managing legacy code and technical debt, proposing a pragmatic approach where wrapping and modularizing legacy components can mitigate risks. She discusses the balance between immediate feature delivery and long-term code health, stressing the importance of aligning technical risks with business objectives. The episode explores the impact of company culture on development practices, the benefits of synchronous work environments, and the evolving landscape of DevOps. Tune in to tap into Brit's valuable wisdom.Book Recommendation:Crucial Conversations: Tools for Talking When Stakes are High By Kerry Patterson, Stephen R. Covey, Joseph Grenny, Ron McMillan, and Al SwitzlerHelpful Links:System InitiativeBrit on LinkedInSPACE FrameworkDORA metricsThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this episode, Robby interviews Andrea Guarino, a Software Engineer at Sonar, about the importance of leveraging static analysis tools for maintaining clean and adaptable code. Andrea emphasizes that well-maintained software should be easy to change, consistent, intentional, and responsible. He explains that static analysis tools play a crucial role in identifying potential issues, ensuring code quality, and preventing security leaks. Andrea also highlights the importance of educating developers on these best practices and integrating such tools into the development workflow to uphold a high standard of code quality. He discusses the challenges of maintaining consistency in code, especially when dealing with legacy code written in different periods and by different teams. Andrea also touches on the concept of technical debt, suggesting a pragmatic approach to address it by balancing between new code quality and gradual improvements to legacy code. Stay tuned for that and more!Book Recommendation:The Brothers Karamazov by Fyodor DostoevskyHelpful Links:Andrea on LinkedInSonarPersonal WebsiteThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this episode of Maintainable, our host Robby Russell sits down with Martin Emde, a sage in the Ruby community and the current Director of Open Source at Ruby Central. Together, they weave through the intricacies of maintainable software, legacy code, and the unwavering power of the Ruby ecosystem. Martin, with his wealth of experience, shares tales from the trenches of open-source software development, focusing on RubyGems and Bundler, and how they've evolved to face the challenges of modern software needs.Martin addresses the elephant in the room - complexity in software. He muses on the natural progression of software projects from simplicity to complexity, drawing parallels to the growth of living organisms. It's not about fighting complexity, but embracing it with open arms, ensuring the software remains adaptable and maintainable. This conversation sheds light on the importance of testing, documentation, and community support in navigating the seas of complex software development.Diving deeper, they discuss the essence of technical debt, not as a villain in our stories but as a necessary step in the rapid evolution of technology. Martin's perspective on technical debt as a tool for progress rather than an obstacle is refreshing, encouraging developers to approach their work with more kindness and understanding.The discussion also highlights Ruby Central's pivotal role in nurturing the Ruby community, emphasizing the importance of contributions, whether code, conversation, or financial support. Martin's call to action for developers to engage with open-source projects, to adopt gems in need, and to provide support where possible, is a heartwarming reminder of the collective effort required to sustain the vibrant Ruby ecosystem.For those curious minds eager to dive into the world of Ruby, contribute to its growth, or simply enjoy a captivating discussion on software development, this episode is a delightful journey through the challenges and joys of maintaining open-source software. Don't miss out on the gems of wisdom shared in this episode, and be sure to check out the useful links below for more information on how you can contribute to the Ruby community.Book Recommendation:Project Hail Marry by Andy WeirHelpful Links:BundlerRuby CentralAdopt a GemMartin on GithubMartin's websiteThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this captivating episode of the Maintainable Software Podcast, host Robby Russell delves deep with Esther Olatunde, Senior Product Engineer at Intercom, into the realms of software maintenance, technical debt, and the impact of AI on software development. The discussion kicks off with Esther's insights on what constitutes well-maintained software, emphasizing the importance of quality from both the user's and developer's perspectives. They explore how ease of onboarding for new developers and the ability to swiftly navigate codebases significantly contribute to a project's maintainability.The conversation then shifts towards the nuances of managing technical debt, with Esther sharing her evolved understanding of the term over her career. From her early days in startups to her current role at Intercom, she provides a rich perspective on the challenges and strategies for advocating maintenance work within diverse organizational sizes. This episode takes an intriguing turn as Robby and Esther speculate on the future of software engineering in the age of AI, pondering how tools like GitHub Copilot could redefine the developer's role.Robby probes into the potential of AI in accelerating development processes and the implications for software quality and team dynamics. They also touch upon the critical aspect of advocating for maintenance tasks to non-developers, underscoring the long-term benefits over immediate functionality gains. The episode is peppered with practical advice for engineers at all levels, encouraging them to persistently champion the cause of addressing technical debt for healthier codebases.As a bonus, Esther recommends a non-technical yet profoundly relevant book, "Built" by Tony Fadell, which offers insights into product development and innovation, further enriching the discussion with broader perspectives on creating meaningful and lasting technology. Dive into this episode for a thorough exploration of the intricacies of software maintenance, the evolving landscape of software development, and how to navigate the challenges of technical debt, all through the lens of an experienced software engineer at the forefront of the industry.Helpful Links:Esther's WebsiteEsther on LinkedInEsther on GitHubIntercomGitHub Copilot"Built" by Tony FadellThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Starting off, Robbie Russell and Robbie Wagner bonding over the complexities of their names in the coffee queue.They dive into the essence of maintainable software, debating the importance of recent commits and the dangers of a single-contributor project.Tech debt, the ever-looming shadow over software development, gets a moment in the spotlight. They share a laugh over buying GitHub stars as a measure of project health.Wagner's approach to tackling tech debt without permission is both rebellious and pragmatic, advocating for quality and refactoring 'on-the-go'.The conversation shifts to the Scout rule in software maintenance, and how constant vigilance is key to overcoming tech debt fatigue.Discussions around Ember.js, its community, and the evolution of front-end development light up the conversation.The narrative takes a turn as they explore automating the mundane, with ESLint, Prettier, and CI tools like Dependabot starring as the unsung heroes in the quest for quality.They touch upon the challenges of maintaining a balance between new features and tech debt, with Wagner emphasizing the sneaky art of integrating tech debt fixes into regular work.Robbie Wagner shares his love for rye whiskey, introducing listeners to his favorite brands and distilleries.Wrapping up, they delve into the world of podcasts, discussing the uniqueness of "Whiskey, Web and Whatnot" and how it blends technical discussions with personal stories and whiskey.Helpful Links:Check out Whiskey, Web and Whatnot for more episodes and whiskey recommendations!Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Jumping into a codebase you're unfamiliar with can be challenging. Are there better & worse ways to go about it? In this episode, Ian gathers a panel (Johnny, Kris & Jon) to discuss the ins & outs of familiarizing yourself with an existing codebase.

In the latest episode of Maintainable, Robby Russell has a fascinating conversation with Irina Nazarova, the CEO of Evil Martians, a name that resonates with innovation and bold strides in the software development world. They dive deep into what it takes to maintain not just code, but also the delicate balance between rapid development and long-term sustainability in the ever-evolving startup landscape.Irina shares her unique perspective on the common traits of well-maintained software, stressing the importance of adaptability and the role of technical debt at different stages of a company's growth. With a background rich in pushing the boundaries of what's possible in software consultancy, she offers a fresh take on commercializing open-source projects, nurturing innovation within the team, and the significance of building genuine relationships with clients.Listeners will get a glimpse into the challenges and triumphs of running a software consultancy that dares to dream big. From the intricacies of investing in internal projects to the philosophy behind fostering a culture of innovation and respect, this episode is a goldmine of insights for anyone curious about the intersection of consultancy work and product development.Don't miss out on this engaging discussion that reveals the byproducts of passion, dedication, and a relentless pursuit of excellence in the software industry. Check out the episode and let us know your thoughts!Book Recommendations:The Challenger SaleHelpful Links:Evil MartiansIrina on LinkedInIrina on TwitterAnyCableLayered Design for Ruby on Rails Applications by Vladimir DementyevThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Marc Louvion (@marc_louvion) is the Maker of the Year 2023 and the visionary behind the innovative ShipFast. His product development philosophy emphasizes rapid shipping and focusing on feature-specific builds, which has transformed his approach to creating tech products. Utilizing platforms like ProductHunt for launches, Marc highlights the importance of pre-validation and community feedback in fine-tuning his products, illustrating his strategic and responsive methodology to product creation.In our insightful conversation —that at some point turns into a founder brainstorming session— Marc delves into the emotional nuances of creators who navigate various expressive avenues, from entrepreneurship to writing, and then returning to coding. His journey with ShipFast showcases the blend of strategic foresight and serendipity crucial for digital market success, alongside the continuous process of innovation. The discussion dive into the intricacies of building a community around a product, the challenges of SaaS businesses, and the significance of maintaining a work-life balance that incorporates personal interests, which in turn fosters a lifestyle that integrates personal well-being with technological advancement.Marc on Twitter: https://twitter.com/marc_louvion00:00:00 Building and Launching00:07:54 Building Startups, Creating Magic, Finding Success00:13:41 Building a Community Around a Product00:26:08 Building a Software Community Platform00:32:25 Balancing Work and Life as Founders00:41:43 Sharing Hobbies and Life ReflectionsThis episode is sponsored by Acquire.comThe blog post: https://thebootstrappedfounder.com/marc-louvion-becoming-a-product-launch-beast/The podcast episode: https://tbf.fm/episodes/300-marc-louvion-becoming-a-product-launch-beastThe video: https://youtu.be/yFy1n1TPWNMYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw (00:00) - Building and Launching (07:54) - Building Startups, Creating Magic, Finding Success (13:41) - Building a Community Around a Product (26:08) - Building a Software Community Platform (32:25) - Balancing Work and Life as Founders (41:43) - Sharing Hobbies and Life Reflections

Robby has a chat with Kyle Daigle, the Chief Operating Officer at GitHub. They dive into the evolution of software development from the perspective of maintaining and scaling software within large organizations like GitHub. Kyle talks about the importance of simplicity and readability in code over complexity, advocating for well-named variables and straightforward codebases to enhance maintainability.He reflects on his journey from a young developer to understanding the value of well-maintained software, noting the balance between creativity in naming and the necessity for clarity as projects and teams grow. The conversation also covers the approach to technical debt, highlighting that not all old code is debt, but rather it depends on whether it hinders progress. Additionally, they explore the impact of AI tools like GitHub Copilot on software development, suggesting that these tools can aid in quicker code reviews and foster higher-level problem-solving discussions among developers. Stay tuned to learn more.Book Recommendations:Turn The Ship Around By David MarquetHelpful Links:Githubkdaigle @ githubThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Robby speaks to the Senior Software Engineer at Perchwell, Jon Moniaci. They discuss the delicate balance between innovation and stability in software development. Jon emphasizes the importance of fostering an environment where engineers can experiment without fear, advocating for a culture of defensive programming to mitigate the fear of breaking things in production. He shares insights from his experiences, including the challenges of working with legacy code and the importance of testing and QA processes. He also talks about the value of considering software pieces as potential microservices to encourage maintainability and flexibility, even if full microservice architecture isn't implemented. This approach, Jon suggests, allows for more sustainable development practices, ultimately leading to more resilient and adaptable software systems. Tune in for that and so much more!Book Recommendations:Sapiens by Yuval Noah Harari The End of Everything (Astrophysically Speaking) by Katie MackHelpful Links:WebsiteJon on LinkedInPerchwellThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Robby has a candid chat with Chad Fowler, the General Partner & CTO at BlueYard Capital. They delve into the nuances of software maintenance, the evolution and challenges of managing software projects, and insights from Chad's tenure as CTO of Wunderlist. They discuss the importance of building software in small, manageable pieces to facilitate easy updates or replacements, the counterintuitive perspective on unit testing's impact on maintainability, and strategies for keeping software up-to-date by redeploying to new platforms.Additionally, Chad shares his thoughts on the current industry layoff trends, emphasizing the value of adaptability and resilience. The conversation also touches on the relevance of mentoring in the tech industry and the potential implications of AI and large language models on software engineering careers. Chad's philosophy on software development, emphasizing pragmatism, adaptability, and the continuous reevaluation of problems to make them smaller and more manageable, permeates the discussion.Book Recommendations:The E-myth Revisited by Michael E. GerberZen and the Art of Motorcycle Maintenance by Robert M. PirsigHelpful Links:WunderlistThe Passionate Programmer by Chad FowlerChad on X/TwitterChad on LinkedInThe Privacy PodcastBlueYard CapitalThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Robby has a conversation with John Nunemaker, the Owner at "Box Out Sports" and "Fewer & Faster". They dive into the basics of maintaining software projects, highlighting the crucial importance of keeping dependencies and versions up to date. John shares his wealth of experience from his time at GitHub, shedding light on the delicate balance between exploring new architecture patterns and adhering to existing ones. They explore practical approaches to software challenges, emphasizing tools like Dependabot for efficient dependency management and the significance of evaluating the potential risks associated with changes in dependencies. John also provides valuable insights into the release of open source libraries, emphasizing the need for clear communication of expectations from the community and personal visions for the project. The discussion spans topics ranging from navigating the challenges of legacy code reviews to the gratification derived from seeking and improving the darker corners of a codebase. The episode culminates with a discussion on personal satisfaction in project selection and the art of effectively marketing open source projects.In essence, this episode of Maintainable not only unveils the intricacies of maintaining software projects but also offers practical wisdom on navigating challenges related to dependencies, legacy code, and personal project satisfaction. Listeners gain valuable insights into the strategic use of tools, the thoughtful release of open source projects, and the importance of continual improvement in the ever-evolving landscape of software development. If you're a software engineer seeking tangible approaches to enhance the maintainability of your projects, then don't miss this episode. Stay tuned!Book Recommendations:Hell Yeah or No: What's Worth Doing by Derek DiversHelpful Links:Flipper RubygemFlipper CloudDon't Repeat Yourself, Repeat Others Slidedeck From RailsConf 2010The World Runs on Bad Software by Brandon KeepersThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Stephanie has a delightful and cute Ruby thing to share: Honeybadger, the error monitoring service, has created exceptionalcreatures.com, where they've illustrated and characterized various common Ruby errors into little monsters, and they're adorable. Meanwhile, Joël encourages folks to submit proposals for RailsConf. Together, Stephanie and Joël delve into the nuances of adapting to and working within new codebases, akin to aligning with a shared mental model or vision. They ponder several vital questions that every developer faces when encountering a new project: the balance between exploring a codebase to understand its structure and diving straight into tasks, the decision-making process behind adopting new patterns versus adhering to established ones, and the strategies teams can employ to assist developers who are familiarizing themselves with a new environment. Honeybadger's Exceptional Creatures (https://www.exceptionalcreatures.com/) RailsConf CFP coaching sessions (https://docs.google.com/forms/d/e/1FAIpQLScZxDFaHZg8ncQaOiq5tjX0IXvYmQrTfjzpKaM_Bnj5HHaNdw/viewform) HTTP Cats (https://http.cat/) Support and Maintenance Episode (https://bikeshed.thoughtbot.com/409) Transcript:  JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: I have a delightful and cute Ruby thing to share I'd seen just in our internal company Slack. Honeybadger, the error monitoring service, has created a cute little webpage called exceptionalcreatures.com, where they've basically illustrated and characterized various common Ruby errors into little monsters [laughs], and I find them adorable. I think their goal is also to make it a really helpful resource for people encountering these kinds of errors, learning about them for the first time, and figuring how to triage or debug them. And I just think it's a really cool way of, like, making it super approachable, debugging and, you know, when you first encounter a scary error message, can be really overwhelming, and then Googling about it can also be equally [chuckles] overwhelming. So, I just really liked the whimsy that they kind of injected into something that could be really hard to learn about. Like, there are so many different error messages in Ruby and in Rails and whatever other libraries you're using. And so, that's kind of a...I think they've created a one-stop shop for, you know, figuring out how to move forward with common errors. And I also like that it's a bit of a collective effort. They're calling it, like, a bestiary for all the little creatures [laughs] that they've discovered. And I think you can, like, submit your own favorite Ruby error and any guidance you might have for someone trying to debug it. JOËL: That's adorable. It reminds me a little bit of HTTP status codes as cat memes site. It has that same energy. One thing that I think is really interesting is that because it's Honeybadger, they have stats on, like, frequency of these errors, and a lot of these ones are tied to...I think they're picking some of the most commonly surfaced errors. STEPHANIE: Yeah, there's little, like, ratings, too, for how frequently they occur, kind of just like, I don't know, Pokémon [laughs] [inaudible 02:31]. I think it's really neat that they're using something like a learning from their business or maybe even some, like, proprietary information and sharing it with the world so that we can learn from it. JOËL: I think one thing that's worth specifying as well is that these are specific exception classes that get raised. So, they're not just, like, random error strings that you see in the wild. They don't often have a whole lot of documentation around them, so it's nice to see a dedicated page for each and a little bit of maybe how this is used in the real world versus maybe how they were designed to be used. Maybe there's a line or two in the docs about, you know, core Ruby when a NoMethodError should be raised. How does NoMethodError actually get used, you know, in real life, and the exceptions that Honeybadger is capturing. That's really interesting to see. STEPHANIE: Yeah, I like how each page for the exception class, and I'm glad you made that distinction, is kind of, like, crowdsourced guidance and information from the community, so I think you could even, you know, contribute to it if you wanted. But yeah, just a fun, little website to bring you some delight when you're on your next head-smacking, debugging adventure [laughs]. JOËL: And I love that it brings some joy to the topic, but, honestly, I think it's a pretty good reference. I could see myself linking to this anytime I want to have a deeper discussion on exceptions. So, maybe there's a code review, and maybe I want to suggest that we raise a different error than the one that we're doing. I could see myself in that GitHub comment being like, "Oh, instead of, you know, raising an exception here, why don't we instead raise a NoMethodError or something like that?" And then link to the bestiary page. STEPHANIE: So, Joël, what's new in your world? JOËL: So, just recently, RailsConf announced their call for proposals. It's a fairly short period this year, only about three-ish weeks long. So, I've been really encouraging colleagues to submit and trying to be a resource for people who are interested in speaking at conferences. We did a Q&A session with a fellow thoughtboter, Aji Slater, who's also a former RailsConf speaker, about what makes for a good talk, what is it like to submit to a call for proposals, you know, kind of everything from the process from having an idea all the way to stage presence and delivering. And there's a lot of great questions that got asked and some good discussion that happened there. STEPHANIE: Nice. Yeah, I think I have noticed that you are doing a lot more to help, especially first-time speakers give their first conference talk this year. And I'm wondering if there's anything you've learned or any hopes and dreams you have for kind of the amount of time you're investing into supporting others. JOËL: What I'd like to see is a lot of people submitting proposals; that's always a great thing. And, a proposal, even if it doesn't get accepted, is a thing that you can resubmit. And so, having gone through the effort of building a proposal and especially getting it maybe peer-reviewed by some colleagues to polish your idea, I think is already just a really great exercise, and it's one that you can shop around. It's one that you can maybe convert into a blog post if you need to. You can convert that into some kind of podcast appearance. So, I think it's a great way to take an idea you're excited about and focus it, even if you can't get into RailsConf. STEPHANIE: I really like that metric for success. It reminds me of a writer friend I have who actually was a guest on the show, Nicole Zhu. She submits a lot of short stories to magazines and applications to writing fellowships, and she celebrates every rejection. I think at the end of the year, she, like, celebrates herself for having received, you know, like, 15 rejections or something that year because that meant that she just went for it and, you know, did the hard part of doing the work, putting yourself out there. And that is just as important, you know, if not more than whatever achievement or goal or the idea of having something accepted. JOËL: Yeah, I have to admit; rejection hurts. It's not a fun thing to go through. But I think even if you sort of make it to that final stage of having written a proposal and it gets rejected, you get a lot of value out of that journey sort of regardless of whether you get accepted or not. So, I encourage more people to do that. To any of our listeners who are interested, the RailsConf call for proposals goes through February 13th, 2024. So, if you are listening before then and are inspired, I recommend submitting. If you're unsure of what makes for a good CFP, RailsConf is currently offering coaching sessions to help craft better proposals. They have one on February 5th, one on February 6th, and one on February 7th, so those are also options to look into if this is maybe your first time and you're not sure. There's a signup form. We'll link to it in the show notes. STEPHANIE: So, another update I have that I'm excited to get into for the rest of the episode is my recent work on our support and maintenance team, which I've talked about on the show before. But for any listeners who don't know, it's a kind of sub-team at thoughtbot that is focused on helping maintain multiple client projects at a time. But, at this point, you know, there's not as much active feature development, but the work is focused on keeping the codebase up to date, making any dependency upgrades, fixing any bugs that come up, and general support. So, clients have a team to kind of address those things as they come up. And when I had last talked about it on the podcast, I was really excited because it was a bit of a different way of working. I felt like it was very novel to be, you know, have a lot of different projects and domains to be getting into. And knowing that I was working on this team, like, short-term and, you know, it may not be me in the future continuing what I might have started during my rotation, I thought it was really interesting to be optimizing towards, like, completion of a task. And that had kind of changed my workflow a bit and my process. JOËL: So, now that you've been doing work on the support and maintenance team for a while and you've kind of maybe gotten more comfortable with it, how are you generally feeling about this idea of sort of jumping into new codebases all the time? STEPHANIE: It is both fun and more challenging than I thought it would be. I tend to actually really enjoy that period of joining a new team or a project and exploring, you know, a codebase and getting up to speed, and that's something that we do a lot as consultants. But I think I started to realize that it's a bit of a tricky balance to figure out how much time should I be spending understanding what this codebase is doing? Like, how much of the application do I need to be understanding, and how much poking around should I be doing before just trying to get started on my first task, the first starter ticket that I'm given? There's a bit of a balance there because, on one hand, you could just immediately start on the task and kind of just, you know, have your blinders [chuckles] on and not really care too much about what the rest of the code is doing outside of the change that you're trying to make. But that also means that you don't have that context of why certain things are the way they are. Maybe, like, the way that you want to be building something actually won't work because of some unexpected complexity with the app. So, I think there, you know, needs to be time spent digging around a little bit, but then you could also be digging around for a long time [chuckles] before you feel like, okay, I finally have enough understanding of this new codebase to, like, build a feature exactly how a seasoned developer on the team might. JOËL: I imagine that probably varies a little bit based on the task that you're doing. So, something like, oh, we want to upgrade this codebase to Ruby 3.3, probably requires you to have a very different understanding of the codebase than there's a bug where submitting a comment double posts it, and you have to dig into that. Both of those require you to understand the application on very different levels and kind of understand different mental models of what the app is doing. STEPHANIE: Yeah, absolutely. That's a really good point that it can depend on what you are first asked to work on. And, in fact, I actually think that is a good guidepost for where you should be looking because you could develop a mental model that is just completely unrelated [chuckles] to what you're asked to do. And so, I suppose that is, you know, usually a good place to start, at least is like, okay, I have this first task, and there's some understanding and acceptance that, like, the more you work on this codebase, the more you'll explore and discover other parts of it, and that can be on a need to know kind of basis. JOËL: So, I'm thinking that if you are doing something like a Ruby upgrade or even a Rails upgrade, a lot of what you care about the app is going to be on a more mechanical level. So, you want to know what gems you're using. You want to know what different patterns are being used, maybe how callbacks are happening, any particular features that are version-specific that are being used, things like that. Whereas if you're, you know, say, fixing a bug, you might care a lot more about some of the product-level concerns. What are we actually trying to do here? What is the expected user experience? How does this deviate from that? What were the underlying mental models of the developers? So, there's almost, like, two lenses you can look at the code. Now, I almost want to make this a two-dimensional thing, where you can look at it either from, like, a very kind of mechanical lens or a product lens in one axis. And then, on the other axis, you could look at it from a very high-level 10,000-foot view and maybe zoom in a little bit where you need, versus a very localized view; here's where the bug is happening on this page, and then sort of zoom out as necessary. And I could see different sorts of tasks falling in different quadrants there of, do I need a more mechanical view? Do I need a more product-focused view? And do I need to be looking locally versus globally? STEPHANIE: Wow. I can't believe you just created a Cartesian graph [laughs] for this problem on the fly. But I love it because I do think that actually lines up with different strategies I've taken before. It's like, how much do you even look at the code before deciding that you can't really get a good picture of it, of what the product is, without just poking around from the app itself? I actually think that I tend to start from the code. Like, maybe I'll see a screenshot that someone has shared of the app, you know, like a bug or something that they want me to fix, and then looking for that text in the code first, and then trying to kind of follow that path, whereas it's also, you know, perfectly viable to try to see the app being used in production, or staging, or something first to get a better understanding of some of the business problems it's trying to solve. JOËL: When you jump into a new codebase, do you sort of consciously take the time to plan your approach or sort of think about, like, how much knowledge of this new codebase do I need before I can, like, actually look at the problem at hand? STEPHANIE: Ooh, that's kind of a hard question to answer because I think my experience has told me enough times that it's never what I think it's going to [laughs] be, not never, but it frequently surprises me. It has surprised me enough times that it's kind of hard to know off the bat because it's not...as much as we work in frameworks that have opinions and conventions, a lot of the work that happens is understanding how this particular codebase and team does things and then having to maybe shift or adjust from there. So, I think I don't do a lot of planning. I don't really have an idea about how much time it'll take me because I can't really know until I dive in a little bit. So, that is usually my first instinct, even if someone is wanting to, like, talk to me about an approach or be, like, "Hey, like, how long do you think this might take based on your experience as a consultant?" This is my first task. Oftentimes, I really can't say until I've had a little bit of downtime to, in some ways, like, acquire the knowledge [chuckles] to figure that out or answer that question. JOËL: How much knowledge do you like to get upfront about an app before you dive into actually doing the task at hand? Are there any things, like, when you get access to a new codebase, that you'll always want to look at to get a sense of the project before you look at any tickets? STEPHANIE: I actually start at the model level. Usually, I am curious about what kinds of objects we're working with. In fact, I think that is really helpful for me. They're like building blocks, in order for me to, like, conceptually understand this world that's being represented by a codebase. And I kind of either go outwards or inwards from there. Usually, if there's a model that is, like, calling to me as like, oh, I'll probably need to interact with, then I'll go and seek out, like, where that model is created, maybe through controllers, maybe through background jobs, or something like that, and start to piece together entry points into the application. I find that helpful because a lot of the times, it can be hard to know whether certain pages or routes are even used at all anymore. They could just be dead code and could be a bit misleading. I've certainly been misled [chuckles] more than once. And so, I think if I'm able to pull out the main domain objects that I notice in a ticket or just hear people talk about on the team, that's usually where I gravitate towards first. What about you? Do you have a place you like to start when it comes to exploring a new codebase like that? JOËL: The routes file is always a good sort of overview of, like, what is going on in the app. Scanning the models directory is also a great start in a Rails app to get a sense of what is this app about? What are the core nouns in our vocabulary? Another thing that's good to look for in a codebase is what are the big types of patterns that they tend to use? The Rails ecosystem goes through fads, and, over time, different patterns will be more popular than others. And so, it's often useful to see, oh, is this an app where everything happens in service objects, or is this an app that likes to rely on view components to render their views? Things like that. Once you get a sense of that, you get a little bit of a better sense of how things are architected beyond just the basic MVC. STEPHANIE: I like that you mentioned fads because I think I can definitely tell, you know, how modern an app is or kind of where it might be stuck in time [chuckles] a little bit based on those patterns and libraries that it's heavily utilizing, which I actually find to be an interesting and kind of challenging position to be in because how do you approach making changes to a codebase that is using a lot of patterns or styles from back in the day? Would you continue following those same patterns, or do you feel motivated to introduce something new or kind of what might be trendy now? JOËL: This is the boring answer, but it's almost never worth it to, like, rewrite the codebase just to use a new pattern. Just introducing the new pattern in some of the new things means there are now two patterns. That's also not a great outcome for the team. So, without some other compelling reason, I default to using the established patterns. STEPHANIE: Even if it's something you don't like? JOËL: Yes. I'm not a huge fan of service objects, but I work in plenty of codebases that have them, and so where it makes sense, I will use service objects there. Service objects are not mutually exclusive with other things, and so sometimes it might make sense to say, look, I don't feel like I can justify a service object here. I'll do this logic in a view, or maybe I'll pull this out into some other object that's not a service object and that can live alongside nicely. But I'm not necessarily introducing a new pattern. I'm just deciding that this particular extraction might not necessarily need a service object. STEPHANIE: That's an interesting way to describe it, not as a pattern, but as kind of, like, choosing not to use the existing [chuckles] pattern. But that doesn't mean, like, totally shifting the architecture or even how you're asking other people to understand the codebase. And I think I'm in agreement. I'm actually a bit of a follower, too, [laughs], where I want to, I don't know, just make things match a little bit with what's already been created, follow that style. That becomes pretty important to me when integrating with a team in a codebase. But I actually think that, you know, when you are calibrating to a codebase, you're in a position where you don't have all that baggage and history about how things need to be. And maybe you might be empowered to have a little bit more freedom to question existing patterns or bring some new ideas to the team to, hopefully, like, help the code evolve. I think that's something that I struggle with sometimes is feeling compelled to follow what came before me and also wanting to introduce some new things just to see what the team might think about them. JOËL: A lot of that can vary depending on what is the pattern you want to introduce and sort of what your role is going to be on that team. But that is something that's nice about someone new coming onto a project. They haven't just sort of accepted that things are the way they are, especially for things that the team already doesn't like but doesn't feel like they have the energy to do anything better about it. So, maybe you're in a codebase where there's a ton of Ruby code in your ERB templates, and it's not really a pattern that you're following. It's just a thing that's there. It's been sort of the path of least resistance for a long time, and it's easier to add more lines in there, but nobody likes it. New person joins the team, and their naive exuberance is just like, "We can fix it. We can make it better." And maybe that's, you know, going back and rewriting all of your views. That's probably not the best use of their time. But it could be maybe the first time they have to touch one of these views, cleaning up that one and starting a conversation among the team. "Hey, here are some patterns that we might like to clean up some of these views instead," or "Here are maybe some guidelines for anything new that we write that we want to do to keep our views clean," and sort of start moving the needle in a positive direction. STEPHANIE: I like the idea of moving the needle. Even though I tend to not want to stir the pot with any big changes, one thing that I do find myself doing is in a couple of places in the specs, just trying to refactor a bit away from using lets. There were some kind of forward-thinking decisions made before when RSpec was basically going to deprecate using the describe block without prepending it with their module, so just kind of throwing that in there whenever I would touch a spec and asking other people to do the same. And then, recently, one kind of, like, small syntax thing that I hadn't seen before, and maybe this is just because of the age of the codebases in which I'm working, the argument forwarding syntax in Ruby that has been new, I mean, it's like not totally new anymore [laughs], but throwing that in there a little every now and then to just kind of shift away from this, you know, dated version of the code kind of towards things that other people are seeing and in newer projects. JOËL: I love harnessing that energy of being new on a project and wanting to make things better. How do you avoid just being, you know, that developer, though, that's new, comes in, and just wants to change everything for the sake of change or for your own personal opinions and just kind of moves things around, stirs the pot, but doesn't really contribute anything net positive to the team? Because I've definitely seen that as well, and that's not a good first contribution or, you know, contribution in general as a newer team member. How do we avoid being that person while still capitalizing on that energy of being someone new and wanting to make a positive impact? STEPHANIE: Yeah, that's a great point, and I kind of alluded to this earlier when I asked, like, oh, like, even if you don't like an existing syntax or pattern you'll still follow it? And I think liking something a different way is not a good enough reason [chuckles]. But if you are able to have a good reason, like I mentioned with the RSpec prepending, you know, it didn't need to happen now, but if we would hope to upgrade that gem eventually, then yeah, that was a good reason to make that change as opposed to just purely aesthetic [laughs]. JOËL: That's one where there is pretty much a single right answer to. If you plan to keep staying up to date with versions of RSpec, you will eventually need to do all these code changes because, you know, they're deprecating the old way. Getting ahead of that gradually as we touch spec files, there's kind of no downside to it. STEPHANIE: That's true, though maybe there is a person who exists out there who's like, "I love this old version of RSpec, and I will die on this hill that we have to stay on [laughs] it." But I also think that I have preferences, but I'm not so attached to them. Ideally, you know, what I would love to receive is just, like, curiosity about like, "Oh, like, why did you make this change?" And just kind of share my reasoning. And sometimes in that process, I realize, you know, I don't have a great reason, and I'll just say, "I don't have a great reason. This is just the way I like it. But if it doesn't work for you, like, tell me, and I'll consider changing it back. [chuckles]" JOËL: Maybe that's where there's a lot of benefit is the sort of curiosity on the part of the existing team and sort of openness to both learn about existing practices but also share about different practices from the new teammate. And maybe that's you're coming in, and you have a different style where you like to write tests, maybe without using RSpec's let syntax; the team is using it. Maybe you can have a conversation with the team. It's almost certainly not worth it for you to go and rewrite the entire test suite to not use let and be like, "Hey, first PR. I made your test better." STEPHANIE: Hundreds of files changed, thousands [laughs] of lines of code. I think that's actually a good segue into the question of how can a team support a new hire or a new developer who is still calibrating to a codebase? I think I'm curious about this being different from onboarding because, you know, there are a lot of things that we already kind of expect to give some extra time and leeway for someone who's new coming in. But what might be some ways to support a new developer that are less well known? JOËL: One that I really like is getting them involved as early as possible in code review because then they get to see the patterns that are coming in, and they can be involved in conversations on those. The first PR you're reviewing, and you see a bunch of tests leaning heavily on let, and maybe you ask a question, "Is this a pattern that we're following in this codebase? Did we have a particular motivation for why we chose this?" And, you know, and you don't want to do it in a sort of, like, passive-aggressive way because you're trying to push something else. It has to come from a place of genuine curiosity, but you're allowing the new teammate to both see a lot of the existing patterns kind of in very quick succession because you see a pretty good cross-section of those when you review code. And also, to have conversations about them, to ask anything like, "Oh, that's unusual. I didn't know we were doing that." Or, "Hey, is this a pattern that we're doing kind of just local to this subsystem, or is this something that's happening all the way? Is this a pattern that we're using and liking? Is this a thing that we were doing five years ago that we're phasing out, but there's still a few of them left?" Those are all, I think, great questions to ask when you're getting started. STEPHANIE: That makes a lot of sense. It's different from saying, "This is how we do things here," and expecting them to adapt or, you know, change to fit into that style or culture, and being open to letting it evolve based on the new team, the new people on the team and what they might be bringing to the table. I like to ask the question, "What do you need to know?" Or "What do you need to be successful?" as opposed to telling them what I think they need [laughs]. I think that is something that I actually kind of recently, not regret exactly, but I was kind of helping out some folks who were going to be joining the team and just trying to, like, shove all this information down their throats and be like, "Oh, and watch out for these gotchas. And this app uses a lot of callbacks, and they're really complex." And I think I was maybe coloring their [chuckles] experience a little bit and expecting them to be able to drink from the fire hose, as opposed to trusting that they can see for themselves, you know, like, what is going on, and form opinions about it, and ask questions that will support them in whatever they are looking to do. When we talked earlier about the four different quadrants, like, the kind of information they need to know will differ based off of their task, based off of their experience. So, that's one way that I am thinking about to, like, make space for a new developer to help shape that culture, rather than insisting that things are the way they are. JOËL: It can be a fine balance where you want to be open to change while also you have to remain kind of ruthlessly pragmatic about the fact that change can be expensive. And so, a lot of changes you need to be justified, and you don't want to just be rewriting your patterns for every new employee or, you know, just to follow the latest trends because we've seen a lot of trends come and go in the Rails ecosystem, and getting on all of them is just not worth our time. STEPHANIE: And that's the hard truth of there's always trade-offs [laughs] in software development, isn't that right? JOËL: It sure is. You can't always chase the newest shiny, as fun as that is. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Robby has a conversation with Jemma Issroff, a Senior Software Engineer, speaker and the author of the book, “Ruby Garbage Collection in Under Two Hours” They delve into the intricacies of well-maintained software, and Jemma brings her wealth of experience, particularly from her involvement in Prism, a notable rewrite of the Ruby parser. The duo explores the contrasting dynamics of maintaining software in C versus Ruby, shedding light on the nuanced challenges and advantages each presents. As the conversation unfolds, they draw intriguing parallels between their approaches to utilizing advanced tools like ChatGPT and CoPilot in their respective workflows. Jemma also offers a sneak peek into her upcoming transition into the realm of artificial intelligence, adding a fascinating layer to the dialogue. Beyond the tech talk, the episode takes an unexpected turn as the two bond over their shared affection for running in the rain and Jemma recounts her enriching experience at Recurse, a unique software programmers retreat. This episode is a captivating blend of technical expertise and personal anecdotes where rain-soaked runs and programming retreats add unexpected flavors to the conversation. Tune in for a unique exploration of the tech landscape that will definitely leave you inspired and informed.Book Recommendations:Thinking Fast and Slow by Daniel KahnemanHelpful Links:Prism, a Ruby parserShopifyAnthropcJemma.devRecurse CenterThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Robby engages in a captivating conversation with the CEO at Mirdin and UpToSpeed, Jimmy Koppel. They delve into the transformative power of evolvable code, shedding light on its myriad benefits and how it contributes to an enriching coding experience. Drawing inspiration from Jimmy's insightful blog post, "The 11 Aspects of Good Code," the discussion unfolds to explore the external qualities of code and the profound impact of crafting code that is not just functional, but a joy to work with. Jimmy shares his vision for UpToSpeed, a platform aiming to revolutionize the onboarding process for software engineers through the strategic use of AI tools, offering a glimpse into the future of seamless integration for new team members. From the nuances of recovering the programmer's intent through well-crafted code to intriguing references to "Zen and the Art of Motorcycles," this episode is a must-listen for anyone passionate about the art and science of coding. Unlock the secrets of creating code that not only meets technical requirements but also enhances the human experience of programming. Discover the unique blend of philosophy and practicality as Jimmy and Robby explore the fascinating world of code evolution, drawing on diverse insights from literature, AI, and the shared wisdom of seasoned developers. Whether you're a coding enthusiast, a seasoned developer, or someone intrigued by the intersection of technology and human expression, this episode promises to be an engaging journey through the nuances of software craftsmanship and the quest for code that stands the test of time. Tune in to gain a fresh perspective on the intricate dance between programmers and their creations, and learn how the pursuit of excellence in coding can truly be a pleasurable and rewarding endeavor.Book Recommendations:Make It StickHow Learning WorksHelpful Links:The 11 Aspects of Good CodeThe Secret History of Information Hiding by David ParnasThe Advanced Software Design Course by MirdinJimmy's BlogJimmy's WebsiteThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Robby has a chat with Senior DevOps Engineer, Hila Fish. They start off by discussing the key characteristics of maintainable infrastructure code. Hila shared insights on providing software engineering teams with the necessary space for exploration while maintaining essential guardrails to ensure the stability of production environments. The conversation also touched upon the significance of offering engineers useful metrics and dashboards for measuring load and stress tests. Robby and Hila reminisced about the evolution of roles like sysadmins and DBAs over the decades, highlighting the transformative journey of infrastructure management.A focal point of the episode was Hila's experience leading a large migration project from Bitbucket Cloud to a self-hosted Gitlab within a tight six-week timeframe. She emphasized the importance of rigorous testing in both development and production environments, effective communication with stakeholders and the team, and other critical aspects of successful project management. The discussion extended to personal and professional development, with Hila underlining the importance of regularly evaluating one's values against those of the employer and the value of self-retrospectives. The challenges in hiring for potential versus expertise in an industry that demands a combination of both were explored. The episode also featured insights into DevOpsDays TLV, Hila's involvement in tech events, and valuable tips for overcoming the initial fear of speaking at such events, accompanied by her own unconventional journey to delivering her first talk. It's going to be an interesting episode, so don't miss out.Helpful Links:Hila on LinkedInOpen-Source - Open ChoiceTechnical Documentation - How Can I Write Them Better and Why Should I Care? By Hila FishTerraformHelmGitLabBitbucketDBAsDevOpsDays TLVThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.