End of my 3.2 years contract on a OSB integration project.... lesson learned.

1) from day 1, get a wiki. NOTHING should simply be documented in emails. Just write all technical info in a wiki and distribute the link to the wiki. We used Confluence wiki: it's simply fantastic. Same goes for documents: just attach them to a wiki page and circulate the link.

2) from day 1, store all configuration in a CMDB. Forget stinky property files or yaml or xml: you need a real relational DB. I had countless discussion on this topic with people who wanted all into property files... forget it, real life is different.

3) enforce the rule that ALL code should be subject to code reviews. Some people were allowed to run loose on the ground and work separately from the rest of the team, and their work turned into a maintenance nightmare, because it was not adhering to the standards. It cost us a fortune to fix the issues once in production.

4) use GIT (we were using stash) rather than SVN: the learning curve is steeper, but you get so much more out of it

5) have fun in the project. Fun really helps making everybody life better. Avoid being harsh with people - it generally only makes things worse. Just talk to people calmly, try to understand the underlying issues. Of course there are a few bastards - usually they are only a tiny minority - who simply don't want to work: either ignore them, or ask management to fire them, but don't get mad.

6) don't do the work that other people are supposed to do. You will get exhausted, and finally you will not do the work that YOU are supposed to do. And eventually management will not even notice your extra effort. Just flag issues, assign tasks and carry on.

7) automation is excellent, but some things are simply too intrinsically complex or variable to be automated. Learn to accept that some stuff will simply HAVE to be done manually. Automation comes with a cost, so learn to balance cost and benefits.

8) keep it simple. Some tools like Java allow you to make complex things in a reliable way, some others (like Puppet) not. If you use primitive tools, do primitive stuff.

9) JIRA is great. Use it. Don't abuse it. JIRA is a tool, not an end in itself. You are paid to make things work in Production, that's all what matters.

10) there are a hundred different methodologies to slaughter post-it against a wall and inebriate yourself with SCRUM ideology. Usually none of all this actually solves a problem. If you are unlucky enough to fall in an Agile-fanatic community, just smile and say yes.

11) avoid by all means MEETINGS. 99% of the issues can be solved with a phone call. If a meeting is still REALLY required, send an invite with an agenda of points to discuss, a link to a wiki, and after the meeting circulate the minutes. Any discussion who is not strictly on the agenda should be vigorously quelched.

12) a limited amount of technical books (electronic format) can be beneficial, to create a common culture and promote continuous education.