My New Favorite Software Pattern


Team-Driven Developer

A newsletter with tips and tools for building software as a team

My New Favorite Coding Pattern

Engineers love patterns.

Why? Patterns help us apply known solutions to novel problems, allowing us to reuse knowledge instead of reinventing the proverbial wheel.

And while I think many engineers lean on patterns more than they ought to, there are patterns worth knowing that can make your life as an engineer much easier.

Today, I'm sharing a new pattern I've been discovering and tinkering with to help write simple and declarative code.


Team Building Exercise

For Team Building this week, let's ask a simple question:

What problems do we seem to solve repeatedly in our code?

I've found this a better question to help determine the patterns needed in a codebase. Don't chase patterns to implement; chase down problems to solve.

Then, think critically about how you might solve those common problems. It might not be that you grab your favorite patterns book or look at Refactoring Guru for hours. Instead, try to think critically about the problems. Make sure you really understand them and make sure they are actually the right problems to solve, too.

Then—and only then!—consider how you might abstract those problems away with the appropriate patterns.

As you do, make sure your team finds value in what you are abstracting and you use the opportunity to teach and share knowledge about why.


Here are some more resources from me to help you build better teams!​

  • 📕 Code Review Champion - My book on code reviews will help you become a world-class code reviewer. From giving kind feedback to navigating conflict, this book can help anyone wanting to sharpen their code review skills.
  • ❓​Questions for Devs - Building a team takes more than catching up about your weekend at standup. I've used these questions to build relationships with my team and push past the same old surface-level conversations.
  • ​📋 Pull Request Template - Maximize your efforts in pull requests by giving context right at the beginning of a new pull request. Copy and paste this template into your repo, and voilà!
  • 📊 ​Code Review Metrics - Start measuring how your team tracks against a few common code review metrics. This python script will pull your GitHub pull requests and generate a CSV you can slice-n-dice to get the data you want. It also has graphs! As this is an open-source project, your contributions and feedback would be great!

Other Creators I Recommend

Image for Build It Better Newsletter

Build It Better Newsletter

by Jonas Fleur-Aime

Creating great software is not just about completing new features faster, submitting more pull requests, or fixing bugs. Every Wednesday I publish tips and tactics to help you meet tough deadlines, tackle tech debt, handle scope creep, manage stakeholders, make sure you're building what customers actually want, and more. I'll draw on what I've learned after spending 15 yrs as a software developer, Engineering Manager, CTO, and startup advisor.

113 Cherry St #92768, Seattle, WA 98104
Unsubscribe · Preferences

Dan Goslen | The Team-Driven Developer

Learn the tips and tools for building software as a team! Every other week, I send a long-form article, a team-building exercise, and resources to help you build better software teams so you can build better software.

Read more from Dan Goslen | The Team-Driven Developer

Team-Driven Developer A newsletter with tips and tools for building software as a team We've recently started a group at Webflow to enhance our existing code review process.And it made me think of an older article I wrote all about the point of pull requests. In a nutshell, pull requests aren't the same as a code review, but they are a common channel to help code reviews run smoothly. I rewrote and added some parts of the article based on the discussions we were having as a group, and wanted...

Team-Driven Developer A newsletter with tips and tools for building software as a team If you’ve ever joined a new team, tackled a legacy codebase, or stepped into an unfamiliar domain, the feeling can be overwhelming. There’s too much to know—and not enough time to learn it all. That’s why I use a model I call traversing the knowledge graph. It helps me orient quickly, pull in the most relevant context, and start contributing with confidence. In this post, I’ll describe: How I think and...

Team-Driven Developer A newsletter with tips and tools for building software as a team You’re staring at your editor. The code should work, but you’ve been fighting an error for a full day. You can’t figure out the problem no matter what you try. Or you’ve been staring at an empty file, wondering what code to write. You’ve got a vague Jira ticket, a lack of context, and a codebase that is difficult to understand. You’re blocked. Now, what do you do? It’s tempting—easy, even—to ping someone...