The previous list is here.

1.) If you have a small number of valuable employees and have a surplus budget, there is no need to provide funds which will encourage them to remain. Instead, as a manager, it’s better to increase your number of subordinates and just hire a new employee (or two) who will slow down the whole team and who will sow discontent into your ranks.

2.) If one of your fellow developers leaves your company and goes on to take a superior position elsewhere (especially if it dwarfs the power of your current boss), it’s important to never speak of it at work. Ever.

3.) If a manager gets a promotion, the whole company is informed of his/her miraculous ascension within the corporate ranks via email, his/her name is written into the sky with smoke by a plane, and the day becomes a corporate holiday. However, if you’re a developer who sweated for the company and who was the primary catalyst to a project’s success, you will get a toy from a Crackerjack box and your name scrawled in the bathroom…because, let’s face it: nobody gives a shit about you.

4.) If you have a devops department which refuses to update their tools and/or platform, you should remember their ultimate goal: to preserve old software for all posterity. Even though it may reduce productivity for all developers within the company, it’s a small sacrifice to keep old software alive for generations to come. Otherwise, much like the eventual demise of trees, one day a child might look up at you and ask “What was PVCS?”

5.) When designing the architecture for a department’s platform, complexity is never to be trusted. Instead, overreaching simplicity is always a preference. For example, a dozen bash scripts (each being over 20,000 lines), a PowerBuilder app, and several unsecured FTP servers constitute a valid architecture.

6.) In order to promote egalitarianism, everyone on a team should be regarded with the same amount of respect when it comes to technical prowess. It’s all about teamwork. Even if you have decades of experience with writing scalable C++ applications on an intense trading platform, you should remember that you are no better than that one dude who can write a killer SQL query.

7.) As for your database, it is better to create tables and then ask questions later. Leave it to the next generation of hired employees to determine which dozen of them are necessary and which of the remaining thousands need to be deleted.

8.) Communication between established departments is completely optional. If there is a problem with networking but the DBAs should be involved to help resolve the problem, the two groups should only communicate if they happen to feel like it that day. On a really good day, they will talk to each other via an elongated cord and two soup cans.

9.) Forking a code base is an opportunity to optimize the performance and reliability of software in a company. More importantly, merging that code into the original trunk should be at your own leisure, with the option being of never.

10.) In order to follow Darwin’s tenets of evolutionary theory, it’s best to create a diversified population. So, it’s a mark for progress if the developers eliminate any homogeny in their collective toolset. When each developer uses a different language, IDE, and platform, we will have created true environmental harmony.

Peter Bolton is the author of Blowing the Bridge: A Software Story and has also been known to be a grumpy bastard on occasion.