After a decades worth of working in non-tech enterprise and small companies. Which means I’ve worked on major projects, minor projects, as an advisor and later

After a decades worth of working in non-tech enterprise and small companies. Which means I’ve worked on major projects, minor projects, as an advisor and later implementation guide to external developers and so on, I’m not sure I’ve seen a good recipe that doesn’t involve making sure that people work together on the same things ever so often and to keep things as simple as possible. 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.