When programmers are working together, like most things in life, it isn't really about the finer details, it is about people trusting each other.
There are layers of trust.
At a fundamental level I trust that my compiler works. I trust that the the standard library is going to work as expected.
At a higher level, up in userland, I trust that libraries or modules that are used in a lot of places or that were written by respected members of the community. If I don't know them I can look at other things, like tests, demos, and documentation.
Only when there is no other information, when you don't know of the person or their work, when you see no tests and no documentation, will you need to actually go in and look at the code.
I take two things away from this.
One is that in organizations where this is happening there are fundamental problems with co-developer trust.
The other is that monolithic code bases where an organization owns the code rather than individual authors owning the code can lead to an atmosphere where no one and everyone feel that they have the say over specific implementation details.
We can design systems and workflows that can implement and support developers trusting one another. If a team is building a system, components could be authored and published under individual author ownership, and then stitched together by the team to build a product.
Of course this is fundamentally a transcendent problem. The issues aren't with the details of the system, the issues are outside of the system and with how the PEOPLE relate to one another.
This is very true. I think it's also probably true that it gets harder to trust code as you get closer to the coalface, much the same way as when collaboratively working on a document, one may become frustrated by another person's grammar or style - yet a third party reading the document would not be able to tell the difference. This I suspect also applies to chefs, plumbers, architects, and many other professions.
There are layers of trust.
At a fundamental level I trust that my compiler works. I trust that the the standard library is going to work as expected.
At a higher level, up in userland, I trust that libraries or modules that are used in a lot of places or that were written by respected members of the community. If I don't know them I can look at other things, like tests, demos, and documentation.
Only when there is no other information, when you don't know of the person or their work, when you see no tests and no documentation, will you need to actually go in and look at the code.
I take two things away from this.
One is that in organizations where this is happening there are fundamental problems with co-developer trust.
The other is that monolithic code bases where an organization owns the code rather than individual authors owning the code can lead to an atmosphere where no one and everyone feel that they have the say over specific implementation details.
We can design systems and workflows that can implement and support developers trusting one another. If a team is building a system, components could be authored and published under individual author ownership, and then stitched together by the team to build a product.
Of course this is fundamentally a transcendent problem. The issues aren't with the details of the system, the issues are outside of the system and with how the PEOPLE relate to one another.