Hacker News new | comments | show | ask | jobs | submit login

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.

The little HN/Twitter/Reddit "awesome programmer" bubble is just that... a bubble. It's easy for us to forget that lots of people write lots of bad, untested code all day long. As much as it frustrates me, lots of people code who don't care about code - it's just their job.

"People just starting out."

Ha, you give them too much credit.

This code is from a 10-year veteran "consultant," probably charging over $200/hour, brought on by the Global Services company hired by the Consulting Agency that Comcast brought in to assist in completing the critical time-sensitive project as quickly as possible.

It was also deemed a great success, and presentations were made about how effective it was, how smart the manager who hired the consulting agency is, and how skilled the global services contractors were who implemented it were, all only 2 weeks behind schedule—a new record for a project of this scope.

That manager got a promotion and is now VP of something or other. He sleeps like a baby and makes 100 times more than you.

This is exactly who wrote this code. I nearly accepted a job with one of Comcast's major consulting partners. My first hint should have been 2 technical interviews in which they were impressed that I used linux... and couldn't tell me a thing about what their day to day looked like. "Oh it's always different"

When I was issued my company laptop, the software had been installed by hand (OS and all). I offered to setup an imaging system for them... but the "IT guy" from the "IT consulting firm" wasnt exactly sure what that was and needed to find out who to get approval from first...

Hey, hey, now. I did include people who never moved on from copy-and-paste too.

They understand that "good code" is code that delivers a lot of value to the person who needs it. Why hate on them for that? You just sound jealous that they make more than you do.

"Good code" that delivers a lot of value and is high quality and maintainable is still better!

I'm not jealous. They don't make more than me. I said they make more than you. And I'm not hating—I'm just telling it exactly like it is, because I understand it, and it's insane, like the truth tends to be when you have huge amounts of power and money being controlled by puny incompetent humans.

Maybe he has had the pleasure of being someone that gets to maintain that "good" code. I know I have.. and at Comcast no less.

That's the whole point. Code is not meant to serve the people who maintain it. Maintainability is only a concern once lack of such starts impacting your actual customers. If writing ugly code and fixing it up later is necessary in order to get shit out the door, why is that bad?

So because it satisfies the suits, he should reserve passing judgement? Try again; he is a programmer, not a suit. Hint: there exist many seperate but equally valid systems for judging worth/merit/quality.

Also, even for a suit, "Maintainability is only a concern once lack of such starts impacting your actual customers." is only true if by "actual customers" you mean shareholders. If you really want to get down to it and make an obnoxious out of place point, you can technically fuck over the customers all you want so long as doing so does not actually hurt the business (meaning: hurt the shareholders). Bonus points for figuring out how this could be done by a consulting company.

If you are a money-chasing robot, perhaps. Most businesses care at least a little about making a good product/satisfying their customers. That's good. Making life easy for your employees at the expense of your customers? That's bad.

Because if you want to be a software developer in the long term, you need to prefer the long term alternative in most cases.

A typical example is, "If we don't get something out the door, we'll be out of business. 'Shit' is something that can be shipped quickly, therefore we must ship 'shit'."

But companies that ship 'shit' generally go out of business anyway. Either their customers find it unappealing and leave, or ongoing maintenance quickly becomes so difficult and expensive that the product can not improve except by being rewritten under new management.

With something like a secure website (or script injected into arbitrary websites by a large ISP) the severity of the security vulnerabilities that tend to result from "shipping shit" often you only get one or two chances as a company.

How is that relevant? Comcast is not a software company. Shipping something that works and then never touching it again is exactly what they want.

>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.

The code on your GitHub, for the most part, seems fine.

One thing I can say is don't use exec[1] if you can avoid it:

    $string = 'rm /var/www/Giftest/*.gif';
While there's nothing * technically* wrong, it's platform specific and I think it would be better to use PHP's unlink[2] 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[3] - it may be an easier way to accomplish what your doing? You can use it with json_decode[4] to get an object.

[1] https://github.com/Machtap/GiffyTube/blob/master/download.ph...

[2] http://php.net/manual/en/function.unlink.php

[3] http://apiblog.youtube.com/2009/10/oembed-support.html

[4] http://php.net/manual/en/function.json-decode.php

would you be willing to discuss this further? No contact in your profile.

Sorry for the delay in getting back to you. Check your emails.

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.

You should be scared... what's with the hardcoded login info exposed on github?


The database doesn't accept external connections, out of curiosity, what is the proper way to pass connection credentials?

at a minimum:

- keep config variables in a separate file that is in your .gitignore and won't get pushed to github.

- keep config file outside of any web accessible directory in case the file renders in plaintext for some reason.

Regardless of db only accepting local connections - an attacker is one step closer to dumping the db.

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.

Keep it up - keep moving up and learning more stuff. Be awesome. Don't worry too much about what other people think of your code, worry just enough that it pushes you to write better code. :)

I agree, they're everywhere - but it doesn't explain this well-written RFC[1] to accompany the code.

[1] http://tools.ietf.org/html/rfc6108

From the RFC:

> R3.1.1. Must Only Be Used for Critical Service Notifications Additional Background: The system must only provide critical notifications, rather than trivial notifications. An example of a critical, non-trivial notification, which is also the primary motivation of this system, is to advise the user that their computer is infected with malware, that their security is at severe risk and/or has already been compromised, and that it is recommended that they take immediate, corrective action NOW.

So much for that.

Probably written by a different person.

You know, there is nothing wrong in picking up code from stack overflow. If you are very efficient in picking up good, well written snippets that fit the style of the project and work without debugging and any time waste - more power to you.

Personally, I consider google search (and stack overflow) as an extension of my development environment and I'd recommend using it and melding your dev env with google search as much as possible. It really helps and speeds things up.

I agree - there's nothing wrong with picking up code from SO if you trust it and understand it. But that takes experience .

I've come across lots of situations where the accepted answer isn't the best answer.

So I'm talking about knowing vs. cargo-culting.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact