It sounds like you have a process problem as well as a communications problem - for one thing, you really should not be updating the software you have in production without anyone else know what you have changed and will be updating.
There are several things that can help here. Apologies if you've got or have done these already:
Version control software
This tool is ready made for communicating code changes as it records those changes as they're made. Got is the most popular these days - you can use GitHub (private repositories are allowed) or there others like GitLab which you can even run internally. These come with additional communications channels where code changes can be discussed before merging.
Peer programming
This is good for two reasons - two people will learn from each other, and two people will see a problem from slightly different angles. In the long run, this leads to better code and knowledge transfer in the team.
Code reviews
Stuff should not be pushed into master or out to production without being reviewed by a peer. This gives some of the advantages of peer programming - having a second pair of eyes go over code, looking for edge cases and side effects, can drastically reduce the number of bugs introduced into production.
One thing to remember - the output of a peer programming session should still be reviewed by a third team member.
Get a testing environment
We have a sequence at our place:
- Development
- Build
- Review (deployment test)
- Production
Changes don't get into build until there has been a code review. Changes don't get into review until the build has been checked by the Product Owner. Changes don't get into production until QA approves the review.
This may be a bit overkill for small organisations, but you should have at least one layer between development and production.
In fact, at one early point in development we had another phase between build and review called staging - as the development stabilised we were able to remove this step.
Issue tracking software
We use Jira - there are many others.
Again, it allows discussions of issues (before or after making code changes) and you can set up workflow to integrate with version control, or to simply assist in tracking.
Bugs and features are described, discussed, and tracked through creation, development, testing and release. Estimates on effort (or time) can be made to help with project planning.
Daily standups
Even if you are not doing agile style project management, these can still be useful within a development team.
These meetings are designed to be quick. Even in a large team this doesn't need to take long. I've heard of 20 man teams getting their standups done in 10 minutes.
Each developer answers three (unspoken) questions:
- What did I complete yesterday?
- What will I complete today?
- What obstacle is blocking my progress?
Save discussion and advice until after the stand up and let people get back to work quickly.
Keep a diary
Get a notebook and keep a very succinct diary. What you're working on, what problems you had, what solutions you tried/succeeded with. It doesn't need to be massively detailed (details belong in code and documentation), but it will help with the stand ups or just when your boss asks for some progress report.
