When I bought my house a few years ago, I set up a small fire pit in my backyard. One of my favorite things to have friends and family over for a "fire night." I'll crank up the fire, set up the chairs, and people trickle in and out one by one.

Hosting these events (along with my love for camping) has helped me get good at building fires. I might not be ready to tackle Alone, but I’m a pretty decent fire builder.

And one key to building a great fire is patience.

You can’t build a fire by holding a small lighter or match to a huge log and expect it to be roaring a few minutes later. You also can’t rush an already burning fire and dump everything all at once, or you’ll smother it.

No, to build a good fire, you need to practice patience. You prepare your kindling and set up your wood before ever lighting a match or making a spark.
​
You’ll build a fire faster by being methodical and patient rather than hopelessly trying to light a log with flint and steel.

Sadly, the software industry has forgotten patience. We want to ship things too quickly, make large assumptions about our users and force paradigms that are poor at best and broken at worst. We are trying to light a log with a small lighter.

Here are some ways in which software engineers can practice patience in their craft (beyond being patient with one another, which is valuable in its own right).
​

Team-Building Exercise

Be honest: does your team sometimes get impatient in shipping work? I'm not talking about working hard and focusing on fixing an urgent issue. I'm talking about moments when the team is clumsy, hasty, or unwilling to collaborate.
​
This week's Team-Building Exercise is about reflecting and working to add more patience into your development lifecycle.

If you think your team needs to improve its patience, your work is cut out for you. It's a challenging task. There is a tool I think can help:

Create a rule that every comment or suggestion in a code review or a design proposal needs a response.
​
If you read the article, you'll notice that I said you don't need to do that all the time. And that is true. This isn't for the rest of the time, but just for a short time of maybe a month or two. It will naturally decline and go away once you stop enforcing it.

By requiring every comment, question, or suggestion to have a response, you'll force authors to slow down and not ignore them. You might not need a full sentence as a new comment in a thread; you can batch a few together and address it all at once. Even using emojis to signal the acceptance of an idea or praise for a suggestion can count.
​
You'll even find that reviewers and comments will be more thoughtful in their suggestions. If they know someone needs to respond (and they'll need to respond back!), they will also be more patient in their feedback.
​
Of course, there is a risk of a bad actor here. Someone could add a ridiculous number of comments and make it difficult for the other side. If this does happen, I'd imagine this person is already not getting along with the team, which will simply escalate an existing conflict. It might even force the conversation about how the team ideally works together (which is a plus in my book).

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

Other Creators I Recommend

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. Subscribe​

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. Subscribe​

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

​

​