>They're all over the place. People just starting out. It could've been an intern fresh out of college. It could've been someone who just never graduated beyond copy-and-paste-from-StackOverflow. It could've been written by a person who never did web development before and was just told to make it work.
I'm an intern, just moving past S.O. copy-pasta jobs and generally get scared at what the hacker news crowd might say about my code... seeing this caliber of shit get pushed live by a major ISP is almost comical, if an admitted novice such as myself can see that it should be a sign as to the ineptitude of our current crop of ISPs.
While there's nothing * technically* wrong, it's platform specific and I think it would be better to use PHP's unlink function. Also, sorry if this is wrong, I haven't looked at the regex but it seems your parsing YouTube URLs? Have you looked at oEmbed - it may be an easier way to accomplish what your doing? You can use it with json_decode to get an object.
The type of programmer who writes code like this never wonders whether their code could be better or not. So don't worry, just by being self-aware enough to ask the question you put yourself on a higher level.
One thing I have learned over the years: It is easy to write "this is crap code" over a lot of production code I have seen. But making it better, writing consistently great code in the usual environment is much harder.
Don't let the macho attitude of HN infect you too much - a lot of people here (and elsewhere) are great in criticizing others.
+1. When you have whole pile of pretty bad code to maintain, it is very difficult to make the fixes significantly better within the time you have to make the fix. Usually significant improvements would require extensive refactoring which is feasible or sensible in surprisingly few cases.
Though, I have to admit, bitching about other peoples' code is fun.
Hrm, is there really a problem if the test data on my development server were to get dumped? It's not like those credentials or the accounts stored in the db carry over when this gets deployed to production, nor will the changes for production ever come close to my github.
Still very valuable things to be aware of in future situations where the above might not apply, thank you very much.