The Balanced Engineer • Issue #27
Today's newsletter brings you articles from Kyle Shevlin, Mike Bifulco, and Martin Fowler.
The Balanced Engineer Newsletter
Week of July 7, 2025 • Issue # 27
🔧 Technical Excellence
Building skills that last beyond any framework
Prefer gaps to margins by Kyle Shevlin (Kyle's blog)
Summary: This article argues that CSS gaps are superior to margins for spacing elements in layouts. Kyle contends that gaps, which are applied by parent containers (flex or grid) to space their children, are more maintainable and flexible than margins, which are applied to individual elements. With margins, developers must manually manage spacing classes on each child element, remember to exclude margins from the last item, and write complex conditional logic when rendering lists dynamically. Gaps eliminate this complexity by letting the parent container handle all spacing automatically, making responsive design changes simpler (just change the container's direction) and avoiding issues like vertical margin collapse.
Why this resonates: Like many software engineers I started learning about CSS by learning about the box model, and so I frequently reach for things like margin and padding to handle most spacing dilemmas. This short article was enough to make me consider an alternate approach, though. I appreciate the clear way the argument was written and the perspective from it. I've been thinking about this article a lot since I read it, and how a more holistic view of CSS for a page taking in all components may be more successful than focusing on individual elements of the page like I typically do. I will be using gaps instead of margins whenever possible from now on.
Tags: CSS
💬 Communication & Collaboration
Because the best code means nothing if you can't work with humans
The Quiet Room Problem by Mike Bifulco (Tiny Improvements Newsletter)
Summary: In "The Quiet Room Problem," Mike Bifulco explores how conformity can kill good decision-making in teams. Drawing from Solomon Asch's famous psychology experiments, he shows how people often stay silent even when they know something is wrong, simply because no one else is speaking up. The result? Teams that mistake silence for agreement and make decisions without proper scrutiny.
Mike argues that thoughtful dissent is actually a superpower for software engineers—but only when wielded strategically. He offers three key principles: pick your moments (not every hill is worth dying on), dissent and commit (voice concerns then support the team's decision), and leave breadcrumbs (document the reasoning behind decisions for future reference). The goal isn't to be the loudest voice in the room, but to ensure the best possible outcomes for users and the team.
Why this resonates: This article hits home because I've definitely been that person who can't keep their mouth shut in meetings—which probably explains why I write so much on the internet! But Mike's framework for "surgical dissent" is brilliant. I've worked with engineers who push back on everything just to push back, and it's absolutely exhausting. The key insight about picking your moments resonates deeply; your dissent loses its power if you use it on every small decision. I also love the concept of leaving breadcrumbs through documentation. Sometimes the best we can do is say "this is the decision we made with the information we have right now" and acknowledge it might not be perfect later—and that's okay! The goal isn't to be right all the time, but to create space for the team to make better decisions together.
Tags: Decision-making
🚀 Career & Growth
Intentional choices for long-term success
Expert Generalists by Unmesh Joshi, Gitanjali Venkatraman, and Martin Fowler (martinfowler.com)
Summary: This article makes the case for "Expert Generalists": engineers who combine deep fundamental knowledge with the ability to quickly learn and adapt across different technologies and domains. The authors argue that the industry's obsession with narrow specialization (requiring "3+ years of Java experience") misses what actually makes developers effective: curiosity to explore new areas, collaboration skills to work with domain experts, customer focus to prioritize learning that delivers value, and mastery of core patterns and principles that transcend specific tools. Rather than hiring for framework expertise that becomes outdated, organizations should look for people who can spot fundamental patterns beneath shifting technologies-like understanding distributed systems concepts that apply whether you're working with Kafka or Kubernetes. The piece challenges the common "T-shaped" model by showing that the best generalists develop multiple deep specialties over time, and suggests practical ways to assess and grow this skill through cross-functional exposure and workshops that focus on building miniature versions of complex systems to understand their core patterns.
Why this resonates: I've been drawn to this article because I consider myself an expert generalist. There are certainly areas where I do particularly well, but the thing that I do the best at is... Just doing the thing. Learning what I need to learn to get the job done, or communicating with the team to get work over the line. I'm obviously a bit biased when it comes to the generalists vs. specialists debate, but being a generalist feels particularly useful in the age of AI.
Tags: Generalist
🎯 Try This
One small thing to practice this week
Practice strategic silence in one meeting this week: Before your next team meeting, identify one topic where you have an opinion but it's not critical to the outcome. Instead of immediately sharing your thoughts, pause and listen to what others say first. Notice: Does someone else raise similar points? Does the discussion naturally evolve in a good direction without your input? Are there moments where your perspective would genuinely add value versus just adding noise?
This isn't about staying silent forever—it's about developing the muscle for picking your moments, just like Mike Bifulco suggests with "surgical dissent." You might discover that some of your best contributions come from listening first and speaking strategically.
What I've Been Building
A quick look at what I've been working on this week
- Overcommitted: Ep. 14 | Mastering pull requests - During this podcast we reviewed some of the tips that I recommended in the June Code Reviews newsletters as well as reviewed our own pull request process.
- Illustration: The Adult Nap Cycle (based on a true story)
- Reading/Learning: Looks Good To Me: The Overcommitted Tech Book Club! We are releasing a new book club that anyone can join. Details are here, and please join us in our new Discord server!
Before You Go
As you start this week, remember that the most valuable engineers aren't necessarily the ones with the deepest expertise in any single area—they're the ones who know when to speak up, when to listen, and how to adapt quickly to whatever challenge comes next. Sometimes the best technical decision is choosing gaps over margins, and sometimes it's choosing silence over noise.
Have comments or questions about this newsletter? Or just want to be internet friends? Send me an email at brittany@balancedengineer.com or reach out on Bluesky or LinkedIn.