Beyond Coding

Most senior engineers don't realize they're stuck until it's too late. The longer you stay, the more people around you have already decided who you are and what you're for. Ian Miell, CTO at Container Solutions, breaks down why this happens and how understanding the system around you is the first step to growing beyond it.
In this episode, we cover:
Why staying too long gets you put in a box (and how to escape it)
How your software architecture is shaped by money flows
The 30% rule: why you should feel uncomfortable at work and what it means if you don't
How to pitch to senior leadership and actually get buy-in
Why AI makes distribution the real challenge, not building
If you're a senior engineer trying to grow beyond your current ceiling, this one is worth your time.

Timestamps:
00:00:00 - Intro
00:00:42 - How to Pitch to Senior Leadership and Get Buy-In
00:03:26 - Why You Should Feel Uncomfortable 30% of the Time
00:06:33 - How to Break Through a Seniority Ceiling
00:08:24 - The Burden of Context: Why Being the Go-To Person Traps You
00:10:16 - How Ian Became CTO Without Trying To
00:13:40 - Why a CTO's Job Is Mostly Coaching Now
00:18:20 - Understanding Incentives: The Key to Navigating Any Org
00:23:08 - Startups vs. Large Companies: Completely Different Rules
00:25:00 - Why AI Makes Distribution the Real Problem, Not Building
00:28:16 - The Hidden Maintenance Risk of Vibe-Coded Software
00:30:13 - Security and Compliance: More Nuanced Than Engineers Think
00:36:54 - Where "Architecture Follows the Money" Came From
00:42:36 - The Wrong Number of Customers: A Systems Thinking Story
00:47:23 - Why Engineers Think Individually Instead of Systemically
00:51:53 - How to Start Thinking in Systems
00:57:50 - How to Create Cross-Pollination in Consulting Teams
00:59:39 - What CTOs Actually Look for When Hiring
01:00:34 - Outro

#softwareengineering #systemsthinking #careergrowth

Most architects stop coding... and that's exactly where they lose their edge. Dennis Doomen has been a hands-on coding architect for 30 years, and his take is blunt: if you're not in the code, you can't make good architectural decisions. Period.

In this episode, we get into the real causes of codebase rot, why dogmatic pattern-following destroys teams, how Dennis uses AI tools to build open source projects without compromising his standards, and why documentation and decision records might be the most underrated investment a software team can make.

This one is for software engineers and architects who want to stay sharp, stay relevant, and build systems that actually last.

00:00:00 - Intro
00:01:05 - Why Dennis Refuses to Stop Coding (After 30 Years)
00:02:54 - The Only Way to Be an Effective Software Architect
00:04:43 - What Happens When Teams Copy Patterns Without Understanding Them
00:06:23 - Software Engineering Is About Battling Complexity
00:08:20 - When to Break Consistency to Reduce Complexity
00:09:24 - The Problem with Overzealous SOLID Principles
00:11:06 - The Future Where We Don't Care About Code Anymore
00:12:07 - How Dennis Built an Open Source Library with GitHub Copilot
00:14:18 - Accepting AI-Generated Code That Doesn't Meet Your Standards
00:16:39 - How to Use AI Without Losing Code Quality
00:17:41 - The Execution Is Accelerating — What Actually Matters Now
00:20:19 - Why Tests Are Your Safety Net in an AI-First World
00:23:44 - Lessons Learned from Letting AI Run Unsupervised
00:26:46 - Should Teams Standardize Which AI Tool They Use?
00:27:32 - Junior Devs and AI: Learning Skills vs. Speed
00:29:21 - How to Stay Curious and Critical in an AI-Assisted Team
00:33:43 - How to Build a Software Engineer from Scratch Today
00:34:38 - Dennis's Emoji-Based Pull Request Review System
00:36:45 - What AI Still Can't Do: Holistic Architectural Thinking
00:38:38 - Why Your Git History Is More Valuable Than You Think
00:40:44 - Decision Records: The Architecture Investment That Pays Off
00:43:16 - When Documentation Saved Dennis from a Bad Management Decision
00:44:47 - The Tailwind Layoffs and the Open Source Business Model Crisis
00:46:27 - Guidelines for Consuming Open Source Responsibly
00:49:51 - Why You Should Open Source Your Own Projects

Guest: Dennis Doomen - Microsoft MVP, open source creator (FluentAssertions and more), and coding architect at Aviva Solutions.

#softwaredevelopment #softwarearchitecture #softwareengineering

Sendil Nellaiyapen, Engineering Manager at Uber, has built systems that scale to millions of users. In this episode he shares what most engineers get wrong about both system design and the move into engineering management

In this episode, we cover:
Ingredients for designing systems that scale to millions of users
How to know when to compromise on architecture
The trade-offs of going from IC to engineering manager and why the role is harder than it looks
How to handle opinionated engineers, set team guardrails, and build high-performing engineering culture

Whether you're a senior engineer weighing the move into management, or already leading teams and looking to sharpen your system design thinking, this one's for you.

OUTLINE:
00:00:00 - Intro
00:01:05 - The Ingredients for Building Systems at Scale
00:02:23 - When to Compromise on Your Foundation
00:03:42 - Scaling from 2,000 to 5 Million Users
00:06:37 - Why Clarity Beats Seniority Every Time
00:08:27 - The Danger of Muscle Memory in Engineering
00:10:25 - MVP Mindset: What You Can and Can't Compromise
00:13:22 - How High-Performing Teams Handle Growing Complexity
00:15:04 - Who Owns the Assumptions? Shared Team Responsibility
00:17:04 - Building Open Frameworks Instead of Closed Rules
00:19:53 - Latency Is Overrated (Here's Why)
00:22:52 - Recipes for Disaster: The Biggest System Design Pitfalls
00:24:17 - The Scala Horror Story: When Elegance Kills Velocity
00:26:52 - How to Handle Opinionated Engineers on Your Team
00:29:03 - Setting Guardrails: The Manager's Design Responsibility
00:32:01 - The Hardest Trade-Off Going from IC to Engineering Manager
00:34:35 - Should Great Engineers Stay IC or Go into Management?
00:37:11 - BFS vs DFS Engineers: Which Type Makes a Better Manager?
00:39:05 - The Real Cost of Becoming a Manager (And Why It's Worth It)
00:41:52 - Outro

#systemdesign #engineeringmanager #softwareengineering

Are you over-engineering for a future that might never come? In this episode, we explore why "future-proofing" often leads to wasted time and sunk costs, and how shifting your mindset from opinions to hypotheses can drastically improve your Developer Experience (DevEx).

In this episode, we cover:
The trap of complex architecture decisions like Hexagonal Architecture too early
How to identify and remove friction points in the software development lifecycle
The reality of using AI agents in production and who is actually responsible for the code

If you are a software engineer or tech lead tired of the "Sacred Cloud Committee" and slow processes, this deep dive into DevEx is for you.

Connect with Bas de Groot:
https://www.linkedin.com/in/bas-de-groot-635013100

Timestamps:
00:00:00 - Intro
00:01:00 - The Danger of "Future-Proofing" Your Architecture
00:03:18 - Why You Should Use Hypotheses Over Opinions
00:05:32 - "Shift Left Until There's Only Sh*t Left"
00:08:19 - At What Size Do You Need a DevEx Team?
00:11:02 - How to Measure Developer Friction Effectively
00:15:43 - Using Data to Fix Slow CI/CD Pipelines
00:17:26 - Why Surveys Beat DORA Metrics for Context
00:19:52 - The "Sacred Cloud Committee" Blocking Deployments
00:24:51 - How to Get Buy-In for DevEx Initiatives
00:28:56 - The Role of Hands-On Coding in DevEx
00:31:47 - Will AI Agents Fix Bad Processes?
00:34:44 - You Are Still Responsible for AI-Generated Code

#developerexperience #softwarearchitecture #techlead

The difference between a junior and a senior engineer isn't coding speed, it's knowing when to say "no."

"The best code you can write is the code you don't write." In this episode, I sit down with Alessandro Mautone (Senior Software Engineer at Aquablu, ex-WeTransfer) to discuss the reality of engineering at a scale-up: how do you maintain technical excellence when the business demands speed?

We break down why delivering features "fast" pays your salary, but how to negotiate deadlines so you don't drown in technical debt later. If you want to move from writing code to owning product decisions, this conversation is for you.

In this episode, we cover:

- How to push back on features and negotiate deadlines without upsetting stakeholders
- Why chasing "perfect code" can hurt a company in growth mode
- The Generalist vs. Specialist career path: Which one is right for you?
- The potential pitfalls of using AI for unit tests without proper oversight

Timestamps:
00:00:00 - Intro
00:01:06 - Balancing Technical Excellence With Delivery Speed
00:04:11 - Why Delivering Features Pays Your Salary
00:06:51 - The Importance of Ownership and "Skin in the Game"
00:08:59 - Leaving WeTransfer: When Company Direction Shifts
00:11:49 - The Generalist vs. Specialist Career Path Debate
00:16:46 - How to Attract Top Engineering Talent to Your Team
00:18:50 - Is LeetCode the Right Way to Hire for Scale-Ups?
00:23:16 - Learning to "Say No" is a Sign of Seniority
00:25:17 - Negotiating Scope Without Burning Bridges
00:26:02 - When AI Generates Bad Unit Tests
00:28:14 - Never Compromise on Tests, Even in "Code Red"
00:33:59 - Communicating Technical Concepts to Non-Tech Stakeholders
00:35:35 - The Never-Ending Battle Against Complexity
00:37:26 - When to Build for the Future vs. Ship Now
00:42:30 - A Real-World Example of Refactoring for Simplicity
00:46:48 - The Skill That Will Be Make or Break for Engineers

#SoftwareEngineering #ScaleUp #TechnicalDebt