1.)  Never concede that an employee’s value to the company deserves a hefty increase in salary (as in 25% or higher).  Instead, it is better to wait for the employee to quit, suffer from their absence for months or perhaps years, and then hire them back at twice their original salary (plus six months of vacation).

2.) An annual review is an opportunity to showcase one’s contributions for various software projects during the past year, with the hopes that it will merit a reward. However, since management never records actionable metrics, all claims are treated as hearsay, and you have as much of a chance for a fair trial as a young girl accused of witchcraft in 17th century Salem (or 20th century Arkansas).

3.)  Management will hire vendors and consultants based on:
     a.) honesty and accuracy when it comes to performance metrics and project status.
     b.) proficiency in knowledge of utilized platforms and efficiency in implementations.
     c.) the level of blame and bullshit that they will swallow without choking to death.

4.) The more distant from Computer Science was your college major, the more eligible that you will be as the manager of a software project.  If you majored in gym, you’re a slam dunk.

5.)  If you don’t engage in code reviews with the antisocial programmer of your group, you’re taking a significant risk.  In the best case, he will develop code without being encumbered, and he will beat project deadlines.  In the worst case, he will start to lose his connection with humanity like Colonel Kurtz from Apocalypse Now, and after convincing the maintenance staff of being a deity, he will plot to murder the entire floor from his bamboo-covered cubicle.

6.)  Tolerance is an incredibly important aspect when managing personnel in an IT department.  If a programmer or admin says that their faith precludes them from command-line prompts and that their culture forbids the use of keyboards, you should learn to encourage acceptance within the group and leave them alone…especially since firing pernicious people can lead to punishing litigation.  Instead, it is better to passively wait for a round of layoffs, throw them into the grinder when nobody is looking, and then feign sorrowful surprise to your subordinates at your next Scrum meeting.

7.)  When you first start in IT, you will read and then curse the source from all legacy programs and system scripts.  In order to ameliorate the pain, you will begin to drink at work, and as the years pass, you will develop code through the reddish hue of seething anger and alcoholic stupor.  When you quit or perish from the bamboo spear of a nearby antisocial programmer, a nascent employee will inherit your insane gibberish, and then the cycle will begin anew.

8.)  Typically, as a manager, your assignment of allocated time for a project should be:
    a.)  2% on R&D
    b.)  2% on the original design
    c.)  25% in political strutting and squawking
    d.)  25% in throwing out the original design and debating with upper management about whether the project should exist
    e.)  20% in arguing over the scope of manpower and the cost of the budget
    f.)   15% in replacing those developers and admins who left in disgust
    g.)  10% in impromptu cage fights with HR managers
    h.)  1% on final implementation

9.) When your boss says “I need to understand this from a bird’s point of view”, it is important to take him literally.  You should skip the technical complexity of your explanation, feed him bird seeds, and then paint a bullseye on the whiteboard for him to aim and defecate upon.

10.)  In order to truly learn about the best practices and technology available, it is important to remember that failure is always an option…as long as you’re not the one doing the failing.  When someone does fail, though, it is important that you point and laugh at them. Don’t laugh too hard, though. In defeat, there is still honor in blowing the bridge.

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