Software engineering and choir rehearsals probably don’t look particularly similar from the outside.
One involves pull requests, APIs and the occasional argument with a build pipeline. The other involves sheet music, breathing and trying not to confidently sing the wrong note.
But the longer I do both, the more overlap I notice.
Your part matters, but it isn’t the whole thing
In a choir, singing your own notes perfectly isn’t enough. You have to listen sideways. You need to know when another part has the melody, when to support it and when you are overpowering the sound around you.
Engineering teams are similar. You can write excellent code and still make the team worse if you never listen, never share context or treat every discussion as something you need to win.
Some of the best technical conversations I’ve been part of have worked because people were willing to leave space for each other. Someone spots a risk, somebody else brings domain knowledge, another person sees the product consequence. The answer gets better because no single person is trying to own all of it.
Confidence isn’t the same as volume
One of the things singing has taught me is that confidence often comes from preparation and trust rather than being the loudest person in the room.
I think that applies to engineering too. Asking a good question can be more valuable than immediately having an answer. Challenging an approach can be useful without turning the conversation into a contest.
That matters more as your influence grows. Leadership isn’t only about being the person with the answer; often it’s about making it easier for the team to reach a better answer together. I’m increasingly interested in that part of engineering — creating clarity, sharing context and being confident enough to challenge something without needing to dominate the room.
Everyone affects the final result
When a choir performance works, nobody in the audience is thinking about one baritone note in isolation. They experience the whole thing.
Users experience software in much the same way. They don’t care which team owned the API or who wrote the component. They care whether the thing they came to do works.
That is probably my favourite connection between music and engineering: both reward people who care about their own contribution while staying aware of the bigger thing they are creating together.