Psychology (psychiatry?) of the True IT Professional

It's easy to spot the True IT Professional (TITP, capital T is on purpose) among a bunch of fake ones.

First of all, the TITP will never lose an occasion to talk about technology: you mention a language? The TITP already knows it, and in one of his previous professional experiences he has successfully used it to solve almost impossible problems. Or has just written a book about it, or an article in a authoritative website, or there's a post in his blog about it. At least, he has attended a conference about it, or he has read something about it. The same applies for any frameworks, technologies, methods/methodologies of software development you can possibly imagine, even if you try with the most abstruse buzzwords: the TITP already knows it, not in a superficial way but with a deep and thorough understanding, and can probably show to you an entry in his Curriculum Vitae which documents his rock-solid expertise in the field.
Furthermore, he will very often express an opinion about it, which is in 90% of cases extremely negative, in 10% of cases extremely positive and enthusiastic, but never neutral: "Technology X? It's a mess, and leads to messy code", "Framework Y? Mmh, no doubt: Z is much better, and I can tell you because I worked for many years with this kind of frameworks", "Method(ology) H? Brilliant, the best thing I've ever tried in my professional life. But unfortunately I know many IT guys that are not skilled enough to understand this and keep on using obsolete and ineffective ways to blablabla...".
Expressing an opinion about a technology is a subtle, indirect way to convey to your audience the following message: "I know that!".

The art of indirect messages is a technique that every TITP effortlessly masters, and it is the foundation of the second basic TITP behavioral pattern: the "All other IT guys are professionally inferior to me" one. The TITP will never say "I am the best around". That would be arrogant. But, still, he would really like to say it, because he actually thinks so or, in some cases, simply likes to think so. Instead, he will adopt an indirect strategy and start painting a world full of mistakes committed by other developers and other working teams; he will never run short of criticisms directed to other IT guys, primarily about their technical skills, but not neglecting their "political" skills, their ability to work in team, and even their lack of sense of humor. The subtle strategy behind this pattern is the following: if I can convey the idea that other people around are professionally less skilled and effective than me, de facto I am successfully conveying the idea that I am the best around (quod erat demonstrandum). Without looking arrogant. Clever.
Ten TITP's out of ten talking with you will imply with their words the message "I am the best around".
And you can bet they (we?) all are :-)!

Post Scriptum
A TITP has a blog, and he uses it to show technical proficiency, brilliant sense of humor and some knowledge of Latin

Simplicity is the ultimate form of sophistication..

After some years of CVS and SVN experience, it's good to have some relief from a painful world of branches and merges: GIT makes everything simpler. You can alter a repository history rebasing your commits, for example. With the "onto" option it is easy to transplant a line of development from one branch to a completely different one. You can reset your repository with the reset option in three different ways (--hard, --soft and.. mixed!),  depending whether you need to change your working tree, or only the git index (thus affecting the staged/cached content ready to be committed), or the reference to the HEAD of the current branch. The extra layer represented by the cached (or staged; two different words for the same concept, as - more generally - there are always multiple ways to the same truth) content of the index is beautifully managed by these three options (but be careful, do not make confusion between "reset" and "revert", the later being the dark side, so to speak, of the exotic "cherry-pick" command). Life is much easier now that a symmetrical diff is supported with the intuitive notation "git diff commit1...commit2" (did you notice the THREE dots?).  Merges are very easy to perform now: you just need to be careful that your working tree is in sync with your index before starting the job (it's not good to start a merge with a dirty working dir!), and run the merge command. Oh, be aware of criss-cross merges, and choose carefully your merging strategy among the following: resolve, recursive, ours, subtree and the powerful octopus merge. And now when working with remote repositories, there's no more room for useless complications since your local repository contains tracking branches which are mapped to remote branches in the original repository, and these tracking branches (in which you should never run commit or push commands, don't forget it!) are mapped with local development branches using simple and intuitive refspecs configurations available in the .git/config file, which will be used by git whenever issueing a fetch, merge or push command. Anyway, the proliferating of branches and repositories will never add unnecessary complexity to the management of your git-version-controlled projects or your Continuous Integration environments, since it is a commonly adopted best practice in GIT projects to use a depot directory including an authoritative repository which all developers should clone/fetch/pull from and push to (don't call it master repository, or central repository: GIT is a DISTRIBUTED Version Control System!). GIT definitely recalls to me the beautiful declination of the Okkam's Razor by Leonardo da Vinci: simplicity is the ultimate form of sophistication :-).