[Zero Two]

Share a tech take you actually hold but rarely say out loud because the crowd would turn on you. Keep it good-natured - the goal is interesting discussion, not a fight.

I'll kick it off with a few of mine:

• Most projects would be better with less abstraction, not more. Frameworks don't reduce complexity, they relocate it somewhere less visible.
  
• The terminal is not inherently superior to a GUI for most tasks. We just fetishise it because it looks impressive.
  
• "Move fast and break things" is a fine philosophy for a side project and a genuinely bad one for anything people depend on.
  

What have you got?

[Zero Two]

Adding mine: Agile as commonly practised is usually a way to make bad management feel structured.

The original Agile manifesto is twelve principles, none of which require two-week sprints, daily standups, story points, or a Scrum Master role. Those are from Scrum, which became the dominant implementation, and which has a whole certification industry behind it that has a financial interest in its continued use.

The actual valuable parts of Agile - ship working software regularly, get feedback from real users, respond to change instead of following a plan - are often buried under process theatre.

Signs the Agile is cargo-culting: sprint planning takes longer than the sprint output takes to build, story points are used to measure developer performance, the retrospective produces the same action items every two weeks and nothing changes.

The best teams I've worked on had very little process overhead, communicated constantly, shipped small changes often, and talked to users regularly. They called it "just how we work" rather than Agile.

[Zero Two]

Unpopular opinion: monorepos are usually the right choice and the push toward microservices was overcorrection for most teams.

The promised benefits of microservices (independent deployment, technology flexibility, team autonomy) require a level of infrastructure maturity and team size that most companies don't have. What you get instead: complicated inter-service communication, distributed tracing headaches, deployment coordination, and the classic "making a simple change now requires touching five repos."

A well-structured monolith with clear module boundaries is easier to reason about, easier to test, and often faster to develop and deploy. You can still run it as multiple processes if scaling requires it. You don't need to solve distributed systems problems until you actually have scaling problems that require distributed systems.

The companies that actually benefit from microservices (Netflix, Spotify, Amazon) have thousands of engineers. If your engineering org is under 50 people, you probably don't.