I’m not saying that you shouldn’t build generic things for code-reuse and easier maintaining. Because you should, just be aware that as soon as you build a generic something, you’re likely stepping into the land of someone’s headspace, and other people might take a while to understand that. Which is where working on each others projects, or doing code reviews help in my experience.
I still encourage good and clean documentation. Something that quickly tells the reader what X does and why it does it.
I also encourage everyone to draw what connects to where and how it does so. Not in any form of detail, just so that you don’t end up in a situation where you have to doable a SQL user to find out who screams about it.
I’m also personally a fan of writing to-do-lists containing all the steps I took to make something work. I recently wrote one for how to connect sequelize to an instance msSQL server in azure. It wasn’t trivial, and because it involved a lot of trial and error, it’s something I couldn’t repeat again in two weeks if I hadn’t written down the steps that worked.
Good question though. It’s something we should all work on.