System design interviews and theoretical frameworks often paint a picture of distributed systems, microservices, and complex architectures as the default path forward. But what does system design look like in practice at one of the world's largest software platforms?
Basam Daidi, a Senior Software Engineer at GitHub, offers a refreshing perspective that challenges conventional wisdom. His key message: engineers frequently over-engineer solutions for status rather than business needs, and simplicity should be your default.
The Trap of Premature Optimization
One of the most common mistakes Basam observes is what he calls "resume-driven development"—adopting complex architectures like Kubernetes not because they're needed, but because they look impressive on a resume.
Many startups fail or struggle because they adopt complex cloud-native solutions too early. This leads to higher costs, slower feature delivery, and technical debt that provides no actual value.
The reality is that vertical scaling—simply getting a bigger server—can handle massive loads and is often dramatically underestimated. Modern VMs with 120 cores and terabytes of RAM can take you incredibly far before you need to consider horizontal scaling or database sharding.
When to Actually Scale Horizontally
Before reaching for distributed systems:
- Max out your single server first - Modern hardware is incredibly powerful
- Optimize your queries and indexes - Often the bottleneck is inefficient code, not infrastructure
- Measure actual usage patterns - Most systems never approach the scale that requires complex architectures
- Consider the maintenance cost - Every additional system component is something that can fail
Design for the Next Order of Magnitude
Rather than building a system meant to last 10-20 years, Basam advocates for a more pragmatic approach: design for the next 10x growth.
If you have 0 users, build for 100. If you have 100 users, build for 1,000. Don't try to support millions from day one—technology changes too fast to design for decades into the future.
This philosophy acknowledges several truths about software development:
- Requirements change - What you build today may not be what's needed tomorrow
- Technology evolves - Better tools and patterns emerge constantly
- You learn as you grow - Real usage patterns reveal optimization opportunities you couldn't have predicted
- Rewrites aren't failures - They're natural evolution as you understand your problem space better
The Right Amount of Planning
Instead of trying to anticipate every possible future scenario:
- Focus on solving today's specific problems
- Make trade-offs based on current constraints
- Build systems that are easy to modify and extend
- Accept that some components will need to be rewritten
Business Context is King
Professional software engineering isn't a hobby or an art form—it's fundamentally about solving business problems. Engineers who understand this distinction become dramatically more effective.
Basam shares a compelling example from the container terminal industry: technical latency directly equated to financial loss. Every millisecond of delay in their systems translated to real money lost by operators. This context completely changed how engineers approached optimization decisions.
In big tech, rewards and bonuses are tied to "landed impact" on the business—not the technical complexity of the code written. The simplest solution that solves the business problem is often the best solution.
Questions Every Engineer Should Ask
Before diving into technical solutions:
- What's the budget? - Financial constraints shape what's possible
- What's the deadline? - Time pressure affects architecture decisions
- Who are the users? - Understanding their needs guides priorities
- What's the cost of failure? - This determines how much redundancy you need
- What's the actual scale? - Real numbers, not hypothetical future growth
Simplicity Over Abstraction
"Simple is complicated enough." This phrase captures one of the most important lessons in software engineering. Complex abstractions and "clever" code often become technical debt that's difficult to maintain.
Basam specifically praises Go for its emphasis on simplicity and readability. When code is written in the "dumbest, most simple way possible," it becomes:
- Easier to debug - Problems are obvious, not hidden in abstraction layers
- Easier to modify - New team members can understand and contribute quickly
- More reliable - Fewer moving parts means fewer things that can break
- Better performing - Simple code often scales better than clever code
Signs You're Over-Engineering
Watch out for these red flags:
- Creating abstractions for problems that don't exist yet
- Building configuration systems for options no one uses
- Adding layers of indirection "for flexibility"
- Choosing technologies because they're "industry standard" rather than appropriate
- Spending more time on infrastructure than features
The Shifting Role of Engineers in the AI Era
With AI tools like GitHub Copilot and coding agents becoming increasingly capable, the engineer's role is evolving. Basam notes that 90% of his code is now written by agents, freeing him to focus on higher-level concerns.
As AI handles more of the coding, engineers should pivot to focusing on operational excellence, reliability, and architectural decisions—the areas where human judgment and business context remain essential.
This shift means different skills become more valuable:
- System design thinking - Understanding how components fit together
- Operational expertise - Keeping systems running reliably
- Business acumen - Knowing what to build and why
- Code review skills - Evaluating AI-generated code for correctness and security
- Debugging complex issues - Tracing problems across distributed systems
Advice for Engineering Growth
To move from good to great, Basam recommends focusing on "breadth" and becoming a perpetual learner. While depth is important early in your career, increasing your breadth of knowledge unlocks new capabilities.
The Power of Breadth
Being a generalist with learning ability offers unique advantages:
- Cross-pollination of ideas - Solutions from one domain often apply to others
- Better communication - You can understand different team perspectives
- Faster adaptation - New technologies feel less foreign
- Strategic thinking - You see opportunities others miss
Practical Steps for Growth
- Read widely - Don't limit yourself to your specific technology stack
- Talk to other teams - Understand how different parts of your organization work
- Learn the business - Understand revenue, costs, and customer needs
- Study failures - Post-mortems teach more than success stories
- Embrace discomfort - Growth happens outside your comfort zone
Key Takeaways
System design in practice differs significantly from theoretical frameworks:
- Start simple - Vertical scaling and monoliths can take you further than you think
- Build for 10x, not 1000x - Design for the next order of magnitude, not decades ahead
- Understand the business - Technical decisions should serve business goals
- Avoid resume-driven development - Choose technologies because they're appropriate, not impressive
- Write boring code - Simple, readable code beats clever abstractions
- Embrace AI tools - Let them handle coding while you focus on architecture and reliability
- Keep learning - Breadth of knowledge becomes increasingly valuable over time
The most effective engineers aren't those who build the most complex systems—they're the ones who solve business problems with the minimum necessary complexity. In a world obsessed with scale and sophistication, simplicity is a competitive advantage.