The cargo cult
First, I'd like to start with the general processes since they are very well-known.
Cargo cult is a very interesting phenomenon. Almost everyone know or have heard about it and at the same time a many teams have persistent rituals which have become a part of their daily routine.
- Yesterday I was working on the feature X. Attended some meetings with company Y. Today I will continue working on the feature X.
Does this sound familiar? What value did that information bring to a team?
Imagine there are 5+ other team members who follow the same pattern. Now, that's a great way to waste some time which could be put to a good use. Actually, you're not obligated to make every second of your work efficient, yet, following a bad pattern is worse than doing nothing at all. Staying silent is better than telling lies.
Returning to the topic, let's consider, what is the goal of that what I did shares? Why do we need it in the first place? To reflect on the previous working day or to share the results that impact the team's progress and highlight problems preventing them from reaching the goal?
If you had a very important meeting with the client, and it has no direct output which impacts your team, then from the perspective of a team it just does not matter.
If you were working on a task or a feature and achieved no meaningful progress, then the only reason to share that information comes if you have some blockers which affects your progress.
Sometimes tasks consume significant amount of time. That might keep a worker busy for multiple days without a visible progress. People often have an impostor syndrome due to that and tend to fall into planning fallacy. Do your best to avoid it. False promise is the last thing you and your team needs.
Keep your work transparent but not flooded with unnecessary details.
Describing technical complexities of the particular software library is best to be kept among engineering members.
The dead legacy
If I had a dollar for every time someone told me
- We do it this way because we have a codebase which is made that way.
I'd be a mighty rich man.
Software development always leads to the tech debt accumulation.
The requirements change from time to time and the software tries to adapt according those changes. It naturally leads to the situation where solutions are designed either under the time pressure or the limitations of the previous solutions.
More often than not this leads to tech debt. Tech debt is basically a drawback which was introduced by implemented solution.
It is often unnoticeable due to abundance of available resources in the modern era. We push the progress through horizontal scaling by adding more resources. This is why we have, say, simplistic mobile applications which may easily consume 1-2GB of RAM.
Unfortunately this leads to indirect consequences which are very hard to follow from many perspectives. Business and management can't understand why some features take months to be implemented while software engineers struggle to provide bug-free solutions.
The more tech debt you have in your project, the more unstable your tower of solution becomes.
Very similar to Jenga. At some point it requires so many precautions that the business can't afford the feature. This often leads to rewriting the solution, as it is easier to design it anew rather than modifying the existing one.
It is very frustrating for a software engineer to spend a whole month just to move some button in the interface. Don't let it come to this.
Although the codebase may contain poor decisions and remain in a bad state, it doesn't mean it has to be treated as such. Otherwise, it will only worsen, and we know that from broken window theory.
Decreasing the number of problems is a part of engineer's responsibilities. If one understands that what he does is not good and justifies it with "it is bad, and we have to accept it, thus we continue the tradition", then it is an investment into that scope of previous poor decisions.