I've seen many developers who has fallen behind, and essentially burned out to the point where they were not contributing with anything any longer.

The last thing you want to do with such people is to train them or otherwise try up their skills, because the main cause isn't lack of skills - it's just a symptom.

I work as a consultant, so over the course of my career I've met numerous developers, and every time I ran into a developer who showed signs of burn out, I wondered what caused this. In some management books, the key enabling factors in order to deliver results are people being willing and able. In other words, motivated and skilled. For developers, this isn't really the case. Not being motivated will always - sooner or later - mean not skilled. Developers aren't like factory workers who just do repetetive tasks, it requires a lot of effort to stay current, so not being motivated usually means that you're falling behind.

So I think the key cause is usually lack of motivation. And what caused the lack of motivation can be many things, but thinking that there is a "technical fix" (such as training or other ways of just getting current again) is just not solving the root cause of the problem.

To answer the OP question: check if the motivation is still intact (you may be dealing with plain old incompetence), and if it isn't (which is the category I believe most cases fall into), you can try to figure out what caused it. My experience is that rekindling motivation can be really hard, so the best is to try guiding the coworker to seek out new and more exciting challenges.

I have the same issue and decided on this strategy:

Decide if two files are different by first comparing sizes, then comparing the first four bytes, then comparing a hash of the first 4k of the file, if the file is large, then a hash of the first mb, and then finally a hash of the whole file.

If any of the equality tests fails, the files are different.

Comparing files as caluml suggests below is prohibitive when you want to dedup a very large number of files, since the number of compare operations has complexity n^2, which essentially means that each file will be opened for reading an order of n times. The checksum approach will reduce the number of opens to a maximum of 4 per file. The rest can be done working on the hashes.

The data needed to dedup is in the range of 4 bytes per hash (CRC32), 4 bytes for the size and with some ingenuity, some 4-10 bytes for the path (using a trie to compless the path tree). Thus a total of some 30 bytes per file. Dedupping millions of file using in memory data structures like this shouldn't be a problem.

Digging around in PHPs github repository reveals that yes - they did commit the buggy code mentioned, but it was never part of any official release. The following release - 5.2.4 - had already been fixed. (To the best of my knowledge.) This is not a general defense of PHP. I have my own reason to dislike the language as well as the community.

I am afraid that Perl 6 is becoming more of a social experiment in stead of a useful programming language. Unfortunately, because some of the fundamental ideas are really novel.

Java is fairly common and you should spend some time writing programs in it, but the next step is to learn another programming language. Since Java is object oriented from birth, uses strong typing and is a compiled language (somewhat), try the opposite: a language that does not assume that everything is an object, doesn't impose strong typing and is a script language. Like perl, lua or python.

This is just the classical "only criminals have something to hide", and I flat out don't agree. There are plenty of other reasons to insist not to have your privacy invaded - just one is that your passwords may be abused by some undergraduate dork working in the IT department.

Also, I find your comments regarding freedom and how it must be deserved are patronizing and completely missing the point.