- Formation — Becoming Who We Are Meant to Be
- The Potter and the Clay (Isa 64:8)
- How Practice Shapes Expertise
- Patterns That Form Our Hearts
- Building Habits That Make Better Engineers
- Spiritual Rhythms for Real Life
- Choosing Tools That Form Good Thinking
- Growing in Grace (2 Pet 3:18)
- Formation Through Collaboration
No engineer develops alone.
Even when we work independently, our thinking has been shaped by other people: teachers, documentation authors, maintainers, reviewers, colleagues and countless developers whose code we have studied.
Collaboration does more than help teams finish projects.
It forms the people within them.
Other People Expose Our Blind Spots
Working alone makes it easy to believe our preferred approach is obvious.
Then another person asks a simple question.
Why is this abstraction necessary?
What happens for this user?
Could this fail under load?
Why was this permission granted here?
The question reveals an assumption we had stopped noticing.
Collaboration expands the field of view.
Code Review Forms Judgement
A good code review improves more than the current pull request.
The author learns what another engineer notices. The reviewer learns how somebody else approached the problem. Both refine their understanding of the team’s standards.
Over time, review creates shared judgement.
This only works when review remains respectful. Comments designed to demonstrate superiority may improve a line of code while damaging the team’s willingness to collaborate.
The goal is not to win the review.
It is to make the work and the people stronger.
Pairing Makes Thinking Visible
Pair programming can feel inefficient because two people appear to be doing one task.
But pairing reveals something ordinary code review cannot: the process of thinking.
Why did you search there first?
Why did you reject that approach?
How did you recognise that pattern?
Experienced engineers often carry tacit knowledge they struggle to document. Working alongside someone makes that knowledge visible.
The junior engineer learns. The experienced engineer is forced to explain assumptions and often discovers gaps of their own.
Diverse Teams Challenge Defaults
People bring different professional histories, cultures, abilities and experiences to software.
That diversity matters because users are diverse too.
A team in which everyone has similar experiences can unknowingly design for themselves.
Collaboration with people who encounter the world differently can reveal accessibility problems, confusing assumptions and risks that homogeneous teams overlook.
Inclusion is therefore not separate from technical quality. It can improve the questions a team is capable of asking.
Disagreement Can Be Formative
Healthy collaboration does not mean constant agreement.
Some of the most valuable learning occurs when two thoughtful people reach different conclusions.
The challenge is learning to disagree without making the disagreement personal.
Explain reasoning.
Ask what evidence would change the decision.
Distinguish preference from requirement.
Be willing to change your mind.
These practices form intellectual humility.
Documentation Is Collaboration Across Time
We also collaborate with people we may never meet.
A useful README, architecture decision record or clear commit message is communication with the future.
The person maintaining our code in three years may know nothing about the conversation that shaped it.
Writing down context is an act of professional generosity.
Teaching Prevents Knowledge Hoarding
Teams become fragile when one person knows how everything works.
Being indispensable can feel valuable, but it creates risk for both the organisation and the individual.
Share knowledge.
Rotate responsibilities.
Document recurring processes.
Invite others into areas you normally own.
The strongest expert is not the person without whom the team cannot function. It is often the person whose presence makes everyone else more capable.
Collaboration Requires Psychological Safety
People cannot contribute fully if every mistake is punished or every question mocked.
A healthy technical culture allows someone to say:
“I don’t understand.”
“I think we may have a problem.”
“I made a mistake.”
“I disagree.”
Safety does not mean avoiding standards or difficult feedback. It means people can engage honestly with those standards without protecting themselves through silence.
Tools Should Support, Not Replace, Relationships
Issue trackers, chat platforms, repositories and AI tools can make collaboration more efficient.
But communication can become fragmented across systems.
Sometimes the best technical tool is a conversation.
If a thread has become increasingly confused, speak to the person. If review comments are becoming defensive, discuss the reasoning together. If requirements remain ambiguous, bring the relevant people into the same conversation.
Efficiency should serve understanding.
Formation Through Community
September has explored formation through practice, habits, tools and repeated attention.
Collaboration brings these themes together.
Other people shape how we work.
They teach us techniques, expose assumptions, challenge habits and model ways of responding to difficulty.
We do the same for them.
Every team is therefore forming its members, whether intentionally or not.
The question is what kind of engineers its culture is producing.
The Invitation
Look at the people with whom you work.
Who has made you a better engineer?
What did they teach you beyond technical knowledge?
Now reverse the question.
What habits are other people learning from working with you?
Do you make questions safer?
Do you share knowledge?
Can you receive correction?
Do your reviews build capability as well as code quality?
Expertise grows through practice, but practice rarely happens in isolation.
We learn with others, from others and sometimes because others are willing to challenge us.
Good collaboration does more than build better software.
It helps form better engineers.
