10 posts tagged with "best-practices"

You're about to deploy to production and your PM asks for "just a clean copy of the code without all that Git history stuff." Or maybe you need to package a specific release for a client who shouldn't see your development branches. Enter git archive — the Git command that's criminally underused despite solving these exact problems elegantly.

Welcome to Surprise Driven Development (SDD) — the revolutionary methodology where uncertainty isn't a bug, it's a feature. Why plan when you can panic? Why document when you can discover? Join me as we explore the chaotic art of building software where every deployment is Christmas morning and every bug is a delightful present from your past self.

Your git commit history could be telling an epic tale of how your codebase evolved, or it could be a cryptic collection of "fixed stuff" and "updated things." The difference isn't just aesthetic—it's the line between a repository that teaches and one that confuses. Well-crafted commits don't just track changes; they document your code's journey in a way that helps your team and future you.

Have you ever stared at a Git diff that looks like it was generated by a cat walking across your keyboard? You're not alone. While Git's default diff algorithm works well enough most days, there are times when it produces cryptic, unusable output that leaves you scratching your head.

I stumbled across Git Notes during a late-night debugging session last week, and honestly, I'm slightly annoyed that I hadn't been using this feature for years. If you've ever wanted to attach persistent metadata to commits without changing commit hashes (and who hasn't?), this hidden gem deserves your attention. And while we're exploring Git's underappreciated features, let's also look at Git trailers - another powerful tool for managing metadata in your repositories.

As a Scrum Master with years of experience facilitating retrospectives for development teams, I've discovered that the success of a retro hinges on thoughtful preparation. The right format, the right questions, and the right energy can transform a session from a routine meeting into a powerful tool for team growth and improvement.

In this post, I'll share the key questions I ask myself when planning a sprint retrospective that delivers real value and fosters meaningful change.

Version control with Git offers developers multiple ways to integrate changes across branches, with merge and rebase standing as the two primary approaches. While both accomplish the same fundamental goal—incorporating changes from one branch into another—they do so through fundamentally different mechanisms, resulting in distinct commit histories and team workflows. Understanding when to use each strategy can significantly impact your project's history clarity, team collaboration, and conflict resolution process. In this deep dive, we'll explore how each option works under the hood, examine real-world usage patterns, and provide clear guidelines for choosing the right approach for your specific situation.

As a Scrum Master and seasoned software developer, I've come to understand that sprint retrospectives are pivotal moments for fostering growth, enhancing team cohesion, and driving continuous improvement. In this guide, I'll walk you through my tried-and-true approach to conducting retrospectives that not only keep teams engaged but also catalyze meaningful change. By integrating these strategies, you can transform your retrospectives into powerful tools for team development and project success.

While this article focuses on facilitating effective retrospectives, the preparation phase is equally crucial. For a deep dive into planning retrospectives that address your team's specific needs, check out Crafting the Perfect Sprint Retrospective.

I was reviewing a pull request last week when I noticed something that made me pause. The developer had carefully implemented proper semantic HTML, added ARIA labels where needed, and ensured keyboard navigation worked perfectly. But every alt text attribute ended abruptly without punctuation, like a conversation that just stops mid-sentence.

It's a tiny detail that most developers miss, and it reveals something important about how we approach accessibility. We often focus on the technical compliance checkboxes while overlooking the human experience details that actually matter to the people using assistive technology.

Here's the thing: accessibility isn't just about meeting WCAG guidelines. It's about creating digital experiences that feel natural and respectful for everyone, including the estimated 285 million people worldwide who rely on screen readers.

You've just finished that React tutorial you've been putting off for weeks. The instructor's voice still echoes in your head as you stare at the completed todo app on your screen. You feel accomplished, maybe even a little proud. But then reality hits: without the step-by-step guidance, you're not entirely sure you could build this again from scratch.

Sound familiar?

Here's the uncomfortable truth about tutorials - they're fantastic for introducing concepts, but terrible for building real competence. The knowledge feels solid when you're following along, but it's actually more fragile than you realize. The real learning happens in what you do next.