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.
Here is the bottom line. If the campus system is not to your liking, and you absolutely cannot refrain from criminal activity on your computer, and you cannot get into another school, then buy a wire cellular broadband connection.
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.
Then I see people suggesting \ for a namespace separator, and I wonder what happened to all the people that put so much work into making PHP5 good, and why we can't get them back.
The answer is right there under your nose.
Inability to make up for poor design keeps the good people away. This is just another day in PHP-land.
I personally threw in the towel when I found out how fatally flawed the magic constant __FILE__ is and how unwilling the PHP developers are to do anything about it.
Anyone wanting a different view on this, try Googling "technological debt".
Drawing trend lines like what is done in this article shows that the author has no idea of the underlying theory. The fact that the balls are numbered does not mean that it reveals any useful information by charting as done in the article.
Charting how many times each ball has been drawn against with the corresponding ball number, and then add some kind of trend lines (of #draws against #ball) is misleading and will not reveal any information about future outcomes of the lottery. All the ball labels are interchangeable and since it is very unlikely that they are all drawn an equal number of times, it is most likely that you'll be able to show trends that show higher chances of getting drawn as ball number increases (or decreases or whatever).
Just to explain the point, lets go back to the day where all the balls were labeled. At that time, there was 50 identical balls with no labels and 50 labels with numbers 1 thru 50. At that time, the balls could have been assigned different numbers that - by accident turned out to place the highest label (50) on the most frequent ball, 49 on the second most frequent ball, and so forth. The result would be a much steeper trend line, telling us that we were "lucky" when the labels were assigned, given the results to date. Any future results will still be evenly distributed.
One might argue that this analysis could tell if the balls are not equally likely to be drawn (due to physical defects), but in that case it is necessary to do a plain multivariate test with the hypothesis that all balls are from the same distribution.
But today the market is not growing anymore. At least here in Denmark.
Around 1996/1997 it was possible to open a small café with some 16 seats and get an annual ROI of no less than 50%, but the market has stabilized now. We also have the problem here in Denmark, that the income tax is very high, so any café willing to break the law and employ black labour, can slash 25-30% off their prices and still make (steal) a profit.
The largest, local telephone company around here has started a concept called Boomtown, which is centered around huge (100+ seats) high tech gaming cafés. It seems to be a good business for them, but it has taken millions of dollars to get it up and running. They are planning to take the concept abroad.
It occurs to me that these markets are based more on popularity vs. actual knowledge.
Well, the market seem to sift out players that make more or less arbitrary trades. If you can't identify any valuable traits of the stocks in the market, you will eventually to loose your (virtual) money. From the perspective of the player who looses, one can argue that very few people like to play any game where the results of their actions seem arbitrary (because they don't understand the game) and the loose. From the market perspective, theese players haven't got any noticeable influence on price formation.
At HSX they do adjust the stock value when each movie actually hits the theaters, paying out a bonus to anyone who managed to predict the turnover of the movie during the opening weekend. On the other hand, players who overestimated the price will loose accordingly. This feedback to the players helps them learn what the movies are really worth.
My view of prediction markets is that it is an open challenge to all participants: find any way to assess the value of something, and get paid (in some or other currency) if you get it right. Due to the openness of the problem, solving it can be done in a multitude of ways, which unlocks a lot of creative thinking.
Your "beauty contest" idea is only right, if it also works that way in real life - that it does make the movies more popular. Otherwise any player who follows a "buy only good looks" will loose his/her money.
In the real world, no amount of tips and tricks is going to make up for a bad schedule. We end up doing code reviews while are software is in verification and validation. Is that smart? No.
I agree that many "clever techniques" are just syntactic sugar on top of the language of developing. The results seem to remain the same with small variations. But what I have noticed is that developers (of all shapes and sizes) tend to believe that their job is best done behind the computer. And yes - this is where they have most skill, but it often means that people fail to leave their comfort zones and attack problems using completely different tools, when they ought to do so.
At a small project I managed, I insisted on doing a 100% complete map of the customers requirements, all the way down to having accurate mock up screen shots of every single screen in the system (not just sketches, but with the intended, final layout down to the pixel). It took three sessions lasting about 8 hours each (the designers worked out screen shots in between sessions), and everybody hated it! The customers representatives got grumpy, the designers felt that they were falling short of the requirements and I got really worn out getting everybody through this endavour. But in the end, the result was a product delivered on time and completely without (any known) bugs.
Can a car run purely off of garbage? Or does the fusion process require a more specific substance to begin with, like water or carbon or something?
The reactors that they are testing now runs on either tritium or deuterium. Both are hydrogen isotopes with either one or two extra neutrons. Tritium is supposed to be the substance that will be easies to produce sustained fusion, but it is extremely radioactive and very hard to contain (it is supposed to be able to permeate steel containers).
There is an upper limit of the nucleus size of the atoms that can be used in any fusion process for it to produce and not consume energy. I am not sure where this limit is, but it does mean that just using garbage in a Back to the Future-style car, is probably not viable unless it is somehow possible to decompose the garbage and sift out the matter that can be used.
Why, the ability to say, "Nope, we don't confine our employee's choice of languages." Well that and a morass of code based as much on individual whim as any logical need.
At least it means permanent work for the rest of us. I spent most of 2003 cleaning up a project where every tool had been used in the worst of all possible ways. CVS for local copies of source code at every workstation. Java for procedural programming and plain c for processing... plain text files. Of course.
I felt like one of those guys cleaning sewers, but I also got paid well, so I guess I am in debt to my predecessor who wrote the code.
In other words: keep up the good work and consider using a handful of esoteric languages! (Including Flip.)
I find it ironic that they happily outfit BART with digital equipment, while sitting down proves to be a life threatening exercise, because the seats have not been cleaned since they were first fitted in the trains a couple of decades ago.
When I sat down, it felt exacly like sitting on wet grass. Damp, primordial soup creeping up my back. Every time.
But you can check your email. Almost everywhere now. Gee.
Before programming, thinking has a proven effect on the outcome of your endavour. I have programmed computers for about half my life (started at 15 and turned 31 last year), and thinking seems paramount when considering what to do before actually coding. It is amazing to see how many forget this basic rule of thumb.
Next, read books and standards. Not knowing that your problem has been (partly) solved already or can be solved better is a sure path to theeth-grinding reinventions of the wheel.
Then, when you're really set to start coding (after thinking for half a day, reading a book and three standards), eat. Real food.
Slashdot Mirror
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.
Here is the bottom line. If the campus system is not to your liking, and you absolutely cannot refrain from criminal activity on your computer, and you cannot get into another school, then buy a wire cellular broadband connection.
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.
Then I see people suggesting \ for a namespace separator, and I wonder what happened to all the people that put so much work into making PHP5 good, and why we can't get them back.
The answer is right there under your nose.
Inability to make up for poor design keeps the good people away. This is just another day in PHP-land.
I personally threw in the towel when I found out how fatally flawed the magic constant __FILE__ is and how unwilling the PHP developers are to do anything about it.
Anyone wanting a different view on this, try Googling "technological debt".
...on security, of course. Not much unlike the ongoing war on terror.
Drawing trend lines like what is done in this article shows that the author has no idea of the underlying theory. The fact that the balls are numbered does not mean that it reveals any useful information by charting as done in the article.
Charting how many times each ball has been drawn against with the corresponding ball number, and then add some kind of trend lines (of #draws against #ball) is misleading and will not reveal any information about future outcomes of the lottery. All the ball labels are interchangeable and since it is very unlikely that they are all drawn an equal number of times, it is most likely that you'll be able to show trends that show higher chances of getting drawn as ball number increases (or decreases or whatever).
Just to explain the point, lets go back to the day where all the balls were labeled. At that time, there was 50 identical balls with no labels and 50 labels with numbers 1 thru 50. At that time, the balls could have been assigned different numbers that - by accident turned out to place the highest label (50) on the most frequent ball, 49 on the second most frequent ball, and so forth. The result would be a much steeper trend line, telling us that we were "lucky" when the labels were assigned, given the results to date. Any future results will still be evenly distributed.
One might argue that this analysis could tell if the balls are not equally likely to be drawn (due to physical defects), but in that case it is necessary to do a plain multivariate test with the hypothesis that all balls are from the same distribution.
But today the market is not growing anymore. At least here in Denmark.
Around 1996/1997 it was possible to open a small café with some 16 seats and get an annual ROI of no less than 50%, but the market has stabilized now. We also have the problem here in Denmark, that the income tax is very high, so any café willing to break the law and employ black labour, can slash 25-30% off their prices and still make (steal) a profit.
The largest, local telephone company around here has started a concept called Boomtown, which is centered around huge (100+ seats) high tech gaming cafés. It seems to be a good business for them, but it has taken millions of dollars to get it up and running. They are planning to take the concept abroad.
Well, the market seem to sift out players that make more or less arbitrary trades. If you can't identify any valuable traits of the stocks in the market, you will eventually to loose your (virtual) money. From the perspective of the player who looses, one can argue that very few people like to play any game where the results of their actions seem arbitrary (because they don't understand the game) and the loose. From the market perspective, theese players haven't got any noticeable influence on price formation.
At HSX they do adjust the stock value when each movie actually hits the theaters, paying out a bonus to anyone who managed to predict the turnover of the movie during the opening weekend. On the other hand, players who overestimated the price will loose accordingly. This feedback to the players helps them learn what the movies are really worth.
My view of prediction markets is that it is an open challenge to all participants: find any way to assess the value of something, and get paid (in some or other currency) if you get it right. Due to the openness of the problem, solving it can be done in a multitude of ways, which unlocks a lot of creative thinking.
Your "beauty contest" idea is only right, if it also works that way in real life - that it does make the movies more popular. Otherwise any player who follows a "buy only good looks" will loose his/her money.
I agree that many "clever techniques" are just syntactic sugar on top of the language of developing. The results seem to remain the same with small variations. But what I have noticed is that developers (of all shapes and sizes) tend to believe that their job is best done behind the computer. And yes - this is where they have most skill, but it often means that people fail to leave their comfort zones and attack problems using completely different tools, when they ought to do so.
At a small project I managed, I insisted on doing a 100% complete map of the customers requirements, all the way down to having accurate mock up screen shots of every single screen in the system (not just sketches, but with the intended, final layout down to the pixel). It took three sessions lasting about 8 hours each (the designers worked out screen shots in between sessions), and everybody hated it! The customers representatives got grumpy, the designers felt that they were falling short of the requirements and I got really worn out getting everybody through this endavour. But in the end, the result was a product delivered on time and completely without (any known) bugs.
The reactors that they are testing now runs on either tritium or deuterium. Both are hydrogen isotopes with either one or two extra neutrons. Tritium is supposed to be the substance that will be easies to produce sustained fusion, but it is extremely radioactive and very hard to contain (it is supposed to be able to permeate steel containers).
There is an upper limit of the nucleus size of the atoms that can be used in any fusion process for it to produce and not consume energy. I am not sure where this limit is, but it does mean that just using garbage in a Back to the Future-style car, is probably not viable unless it is somehow possible to decompose the garbage and sift out the matter that can be used.
Take a look at the Wikipedia page about nuclear fusion.
At least it means permanent work for the rest of us. I spent most of 2003 cleaning up a project where every tool had been used in the worst of all possible ways. CVS for local copies of source code at every workstation. Java for procedural programming and plain c for processing... plain text files. Of course.
I felt like one of those guys cleaning sewers, but I also got paid well, so I guess I am in debt to my predecessor who wrote the code.
In other words: keep up the good work and consider using a handful of esoteric languages! (Including Flip.)
I find it ironic that they happily outfit BART with digital equipment, while sitting down proves to be a life threatening exercise, because the seats have not been cleaned since they were first fitted in the trains a couple of decades ago. When I sat down, it felt exacly like sitting on wet grass. Damp, primordial soup creeping up my back. Every time. But you can check your email. Almost everywhere now. Gee.
Before programming, thinking has a proven effect on the outcome of your endavour. I have programmed computers for about half my life (started at 15 and turned 31 last year), and thinking seems paramount when considering what to do before actually coding. It is amazing to see how many forget this basic rule of thumb.
Next, read books and standards . Not knowing that your problem has been (partly) solved already or can be solved better is a sure path to theeth-grinding reinventions of the wheel.
Then, when you're really set to start coding (after thinking for half a day, reading a book and three standards), eat. Real food.