The Courage to git push --force on a Friday: The Art of Writing Non-Fragile Code

Are you still dreading Friday deployments? Does the thought of a critical bug appearing in production on a weekend send shivers down your spine? This talk challenges the conventional wisdom that shipping code on a Friday is an act of recklessness. Instead, we'll explore how true courage in software development is born not from blind optimism, but from meticulously crafted engineering discipline.

We'll dive deep into five fundamental pillars for building non-fragile code: establishing robust test automation (your ultimate safety net), implementing efficient CI/CD pipelines (letting robots handle the mundane), mastering the art of observability (knowing what's happening after deployment), developing the ability to roll back quickly (your reliable parachute), and embracing the magic of small, incremental steps. Beyond the technical, we'll also examine the crucial role of team culture in fostering an environment where failure is a learning opportunity, not a cause for blame.

Join me to learn how to transform fear-driven development into a state of unwavering confidence, allowing you to deliver value continuously, reliably, and yes, even on a Friday afternoon, without a second thought.

Transcript

1. The Courage to git push --force on a Friday: The Art of Writing Non-Fragile Code Evren Tan
2. Who am I? https://evrentan.com
3. Really? No Push To Production on Friday
4. Does This Scene Look Familiar? Generated by Google Gemini
5. But What If It Doesn't Have to Be This Way? • This talk is not about recklessness or being careless • It's about building an engineering discipline so solid that the 'risk' factor is virtually eliminated from the equation • True courage in software development is born from meticulous preparation, robust processes, and unwavering confidence • Our Ultimate Goal: Writing Truly Non- Fragile Code Generated by Google Gemini
6. The Anatomy of Fear: What is Fragile Code? • It's the code you're afraid to touch or modify • It's when fixing one thing unexpectedly breaks three other things • It's code that is untestable, difficult to understand, and unpredictable in its behavior • It leads to technical debt, slowing down future development • In short, it's code you cannot trust – creating a constant source of anxiety Generated by Google Gemini
7. Anti-Patterns: The Road to Fragility • The Hero Developer: All critical knowledge is in one person's head. If they leave or are on vacation, the system is at risk. (Bus factor of 1) • The Ice Cream Cone : Lots of slow, manual UI tests at the top, very few fast, automated unit/integration tests at the bottom. It's brittle and melts under pressure • Fear-Driven Development: "If it ain't broke, don't touch it." This mindset prevents necessary refactoring and leads to code rot • Merge Conflict Hell: Working on massive, long-lived feature branches for weeks, leading to painful and risky merges
8. The Art of Courage: The 5 Pillars • Tests as a Safety Net • By the Power of Automation! (CI/CD) • The Art of Observation (Monitoring) • The Ability to Roll Back Quickly • The Magic of Small Steps
9. Tests as a Safety Net • Tests prove that your code works as expected • More importantly, they guarantee it STILL works as expected after a refactor or adding a new feature • They give you the freedom to improve and refactor code without fear • Acts as living documentation: Tests describe what the code should do, not just how it does it • Improves code design: Testable code is often well-structured code (decoupled, single-responsibility) • The Test Pyramid: A balanced strategy of Unit, Integration, and E2E Tests Generated by Google Gemini
10. By the Power of Automation! (CI/CD) • CI (Continuous Integration): Every commit automatically triggers a build and runs your entire test suite (the safety net) • CD (Continuous Deployment): If CI passes, the code is automatically deployed to production • It eliminates the classic "It works on my machine!" problem by providing a consistent, predictable process • Automation turns deployment from a scary, manual ritual into a boring, everyday event • This frees developers to focus on what they do best: building great features
11. The Art of Observation (Monitoring) • Deploying without monitoring is like flying a plane with no instruments. You're moving, but you have no idea where you're going or what's about to happen • Key Tools: Logging (What happened?), Metrics (What's the status?), and Tracing (Where's the bottleneck?) • It allows you to shift from a reactive ("Wait for users to report bugs") mindset... • ...to a proactive ("We know about problems before our users do") mindset. • True confidence comes from knowing how your system is performing in the real world Generated by Google Gemini
12. The Ability to Roll Back Quickly • Let's be realistic: Even with perfect preparation, failures can and will happen • The goal isn't to never fail; it's to minimize the "Time to Restore Service" (TTRS) • Key Techniques: Automated Rollbacks and the game-changing power of Feature Flags • Feature Flags separate deployment from release: Ship your code anytime, and activate it for users only when you're ready • This is your ultimate safety parachute. It gives you the courage to innovate, knowing you have a reliable escape plan
13. The Magic of Small Steps • "Big Bang" Releases = "Big Bang" Risks • Small, incremental changes are far easier to understand, review, test, and roll back • This promotes a continuous flow of value, not a stressful "release crunch." • Faster feedback loops: Get features to users sooner and validate ideas before investing months of work • Pinpoint bugs with ease: When a problem occurs, you know it was in the last small change, not somewhere in a 10,000-line release • This isn't just a tactic; it's a fundamental principle that makes all the other pillars more effective Generated by Google Gemini
14. Putting It All Together: A Tale of Two Deployments The Old Way The New Way Thursday, 10 PM release Friday, 3 PM release Manual 20-step checklist Fully automated pipeline "Deploy and Pray" "Deploy and Verify" with dashboards A critical bug is found by users A bug is found internally with a feature flag Frantic debugging on Friday and during all weekend The feature is disabled in 5 seconds git blame to find the culprit A blameless meeting on Monday to improve the process
15. Culture: It's Not Just a Technical Issue • The best tools and processes are useless in a culture of fear and blame • In a Blame Culture, the main question after a failure is: "WHO did this?" • This leads to hiding mistakes, avoiding risks, and slow progress • In a Learning Culture, the main question is: "HOW can our system improve so this doesn't happen again?" • Psychological Safety is the foundation: The belief that you won't be punished for speaking up with ideas, questions, concerns, or mistakes Photo by @suhacanuluer
16. Your First Steps: Where to Begin on Monday • You don't need to boil the ocean. Start small and build momentum • For your next bug fix: Write just one automated test that proves the bug exists, then watch it pass when you fix it • Improve one log message: Before you close your next task, add or clarify a log entry that would have helped you debug it faster • For your next code review: Make your Pull Request 10% smaller than your last one • Add a linter to your build: Introduce a simple, automated code style check. It’s an easy win for consistency and a great first step into automation • Share something you learned: Send a message to your team channel about a cool command, a tricky bug, or a useful article. Break down knowledge silos • Be the change: Pick one principle and be its champion on your team. Consistency is key
17. Conclusion: Where Does Real Courage Come From? • The Formula for Fearlessness: Courage = (Tests + Automation + Observation + Small Steps + Fast Recovery) x Culture • The goal is not to recklessly git push --force on a Friday • The true goal is to build systems and teams so robust that the day of the week becomes irrelevant • Real courage isn't the absence of fear; it's the presence of preparation, process, and trust
18. Q&A