It is best to try and coordinate and sequence your changes to minimize challenges. 

But to answer your questions, it is important to understand how check in and publish operations work. Check in does make a change available to another SBM developer. So, if you can, just don't check in changes that aren't ready. Next, Publish publishes the contents of the local cache and does not care about what is checked in. So, if you are a developer that does not want someone else's changes, you can just choose not to get the latest and only publish and deploy based on what is in your local cache - just understand you run the risk of undeploying a change of another developer.

Making use of one or more lower SBM environments also helps. You can for example both developers work in Dev, promote desired changes to Test, and promote successful changes to Prod. You will need to keep a close eye on versions of process apps and be prepared to rollback to an older tested version if for example the latest version is not desired or successfully tested. It is also important that you do thorough unit testing, and maybe even testing in Composer (such as Previewing forms), to avoid problems later.

If you version/publish your process apps more frequently, making smaller more testable changes, then this will also help in the overall situation.

Composer also has a Compare/Merge feature - this may help you apply or rollback changes on a more granular scale within a process app as well.

I have successfully worked on teams of 3 or more SBM developers. I have used the approaches above as well as techniques in planning the work in terms of Sprints, and trying to assign developers changes to separate process apps when possible, or at least separate objects, to make it all easier and avoid conflicts. But ultimately, if everyone is aware of everyone else's planned changes, you can coordinate as a team. Smaller, less risky changes should be applied before more complex changes, and published separately, so that it is easier to keep them separate.