Thinking in Constraints


Team-Driven Developer

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

👋 Welcome to the first issue of 2025! And a special welcome to all the new subscribers over the holiday!

Let's jump right in.


As I’ve encountered more and more problems as a software engineer, I’ve often found myself having one of two knee-jerk reactions when faced with a new problem:

1) too easy

2) impossible.

Of course, those reactions are extremes. Most problems lie somewhere in the middle.

Additionally, many of the “easy” issues I’ve encountered have some form of complication, while many of my initial reactions to “impossible” problems had reasonably straightforward implementations.

One of the tools I’ve used to reorient my knee-jerk reactions is thinking about constraints.

I don’t mean thinking exclusively about Constraint Satisfaction Problems (though that can help; more on constraints in a moment), but more about how you think about a problem space.

Today, I want to share a bit of how I think about this when solving problems, and I hope it can help you.


Team-Building Exercise

The beginning of a new year always comes with a new set of goals and ambitions. These are found both on a personal level, a team level and a company level (to name a few).

This week's Team-Building Exercise is about learning some of the goals your teammates have for the year. Yes, you have team goals that you should be talking about but don't settle for just those.

Find a few colleagues you are building strong trust and relationships with and ask them, "Do you have any goals for the year?"

These could be professional or could be any arena they want to improve within. The goal of the conversation is to build trust and learn if there is any way you can support them in reaching their goals.

Don't be pushy, of course. They might not have thought about it or aren't comfortable sharing much else. That's fine! But I promise that by asking the question, your teammates will notice that you are taking an interest in them and trying to build a relationship.

For me, I have a goal of climbing more lead routes at my gym and being able to go outdoor climbing at least once in the coming year (tough with a toddler). I also have a goal of improving my knowledge of AWS and potentially (finally) getting an AWS Cloud Practitioner Certificate.

While a few of my teammates likely won't be able to help with the first (remote team), I think I'll likely get some tips and pointers from a few teammates on the AWS one.

The key is sharing and understanding what the goals are first.


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 Daniel Schaefer

Daniel Schaefer

Subscribe if you are a software developer that has the technical skills, but you're looking for opportunities to enhance your soft skills to advance in your career.

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 The first time I hit the proverbial "deploy button" as a software engineer, I was anything but calm. While we were confident in our tests, we always feared, "What if something goes wrong?" or "What if we missed a critical test case?" This first deployment went fine, but over the past decade, I've had my fair share of botched deployments or the need to rollback quickly. It's not a fun place to be in. During...

Team-Driven Developer A newsletter with tips and tools for building software as a team Software engineers are all about principles and patterns. Short acronyms like DRY, YAGNI, KIS, etc., are used everywhere within the industry to try and concisely communicate an axiom of how to write software. One principle that arises within software engineering is that of reusability. We have this idea that we can build software components once and reuse them everywhere. The idea is that by building...

Team-Driven Developer A newsletter with tips and tools for building software as a team A few years ago, my wife and I replaced all the windows in our home. When it came time to install it, I figured it would take the better part of a week (it’s about 22 windows). Instead, the company said, “Oh, it takes about two days.” I was skeptical but guessed they would send a larger crew or something than I had imagined. On installation day, two guys showed up. Two! How were two guys going to replace...