5 ms·

It's true. I don't know how many times I've watched eager hackers get lambasted for "reinventing the wheel," or "don't bother doing it yourself, you'll just scr

It's true. I don't know how many times I've watched eager hackers get lambasted for "reinventing the wheel," or "don't bother doing it yourself, you'll just screw it up -- someone has probably done it already and did it better than you could." This happens most often at the intersection of technology and entrepreneurship. The business advice is that it's cheaper to buy it than build it. The engineer's perspective is that a square peg isn't going to fit in every hole. "Geeks," are harsh. I mean that in the very broad, general, and discriminatory sense. We have to work with bad code all day written by bad programmers. Some of us make a career out of saving businesses from bad technology decisions and poorly written programs (it is NOT good work, btw. Just pays well). So when yet another new-comer comes on board with bright, eager enthusiasm to revolutionize the Internet (yet again) we do tend to be rather cynical. I agree w/ the poster that the cynicism is a bad thing. We could be more constructive. Don't stop them from writing their own web server... show them where to look up the RFCs, reference implementations, etc. Encourage them to learn. We could all benefit from having more knowledgeable people around.

dexen 16y ago
There is reinventing the wheel and reinventing the wheel. It's cute when a person, learning as she goes, comes up with something that's been already invented. Only goes to show she understands the field. [1] It's unbelievably irritating when something that was widely implemented 10 or 20 or 30 years ago (and then even improved significantly) is now asserted as the next big thing. C'mon, be serious -_-' [2] [1] a nice guy thinks of swap (in userspace) just to hold strings of arbitrary length, calls it ``backed by file storage'': http://9fans.net/archive/2011/02/94 http://9fans.net/archive/2011/02/94 [2] no example I can think of ATM; but perhaps the above one could fit?
- amalcon 16y ago
  For [2], I'd normally suggest the thin client... except that it's got enough momentum that it may actually be the next big thing.
  - dexen 16y ago
    Heh, perhaps Sun's demise helped thin client in a way? ;-)
- bartonfink 16y ago
  Garbage collection back in the 90's. Java really ran with that one.
  - dexen 16y ago
    "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." - Guy Steele, Java spec co-author http://www.paulgraham.com/quotes.html http://www.paulgraham.com/quotes.html
- Jach 16y ago
  There are lots of examples for [2], but we should avoid listing them as they'll lead to arguments. In fact, we should also avoid listings for [1] since that can lead to anger venting.
- zasz 16y ago
  For [2]--NoSQL.
  - dexen 16y ago
    Well yes and no. On one hand, NoSQL as ``let's ditch relational'' is [2] squared; especially as ditching relational because of SQL is ditching the only thing good about SQL. On the other hand, if NoSQL would mean ``let's have relational language better than SQL'', they hey, that's good! It's been tried [a] even before the SQL and tried [b] since then. It's not easy for something new to get traction with all the SQL code out there. But we will arrive there some day. -- [a] http://en.wikipedia.org/wiki/ISBL http://en.wikipedia.org/wiki/ISBL [b] http://en.wikipedia.org/wiki/Third_manifesto http://en.wikipedia.org/wiki/Third_manifesto NB., if you attack a hot & popular topic, you better provide some argumentation, or you will be downvoted to the ground :-(
- hardy263 16y ago
  [2]http://care.diabetesjournals.org/content/17/2/152.abstract http://care.diabetesjournals.org/content/17/2/152.abstract Well, not really 10 or 20 or 30 years ago. More like 400 years ago.
ZeroMinx 16y ago
> I don't know how many times I've watched eager hackers get lambasted for "reinventing the wheel," Depends on context.. If it's someone learning, or hacking on some personal project, go ahead! It's a great way to learn. However, if we're talking about a programmer in a commercial company, it's a different story. Your purpose is not to produce the most amount of your own code, your task is to produce a service of some sort. Unless the software/service you're working on a is a database, I expect you would use an existing database (assuming you need one). If the code you're creating needs to manipulate dates, I expect you use an existing library for such things. It will be available, it will be tested, it will handle all edge cases. Why would it be acceptable to spend a lot of time on reinventing that particular wheel, fixing bugs as they arise, etc?
- agentultra 16y ago
  I don't think it's entirely unreasonable to expect someone to use an available library for parsing dates. It's not a terribly good example. There are cases where "reinventing the wheel," is simply an ignorant statement. Perhaps the system in question has developed semantics for working with date-based data that the grammar of the existing date-parsing library's API doesn't match well with. This extremely contrived example may force the developers to write a lot of code for working around those inconsistencies which themselves can lead to bugs and maintenence headaches in the future. What if your lack-wit developer who wrote his own date-parsing library saw these problems and wrote a library whose API resolved them? Or perhaps in another scenario the existing libraries are simply inefficient for some metric of acceptable performance in your system. Maybe this ignorant developer simply writes a better library that allows you to do more. Either way, there is reason to believe that either scenario is valid. It is likely that writing a date parsing library is not going to be terribly useful. That doesn't mean it's impossible and so one must be willing to evaluate evidence and draw conclusions rather than hide behind blanket statements. What I'm really talking about is the attitude people have when they think someone is "reinventing the wheel." While some people are helpful and will politely point out that there are existing date-parsing libraries, there are a great many more it seems who will assume that the person who is "reinventing the wheel" is a clueless loser who wouldn't make such a "stupid mistake" if they were worth their salt. That kind of reaction isn't helpful at all.
generalk 16y ago
You're right. Sometimes. A hacker writing a quickie web server for the experience of doing so is laudable. This applies to lots of types of projects: toy OSes, social networking protocols, web frameworks, what have you. Exploration is fun, and key to the hacker spirit. The difficulty comes from knowing the limitations of your skills. I got my web programming chops by reading a bunch of PHP tutorials back in 1998 and throwing together some dummy pages that could read/write to a mysql database. Not long after I built a website for a good friend's business that was riddled with SQL injection and XSS holes. Luckily, we never got exploited, and years later on a rainy Sunday night I revisited the code and patched it up. Had we been hit, I don't know how badly that would have affected the company. The same goes for home-grown crypto: sure, you might be able to apply a function you wrote and get something that looks like cyphertext, and maybe it's a fun project to learn about crypto. But when you don't know any better, you think you've done it right and you might unintentionally swindle some folks into paying for completely insecure crypto.
- count 16y ago
  Here, here! Learning someething, and selling (for money, or otherwise) the not-acceptable-for-use side effect of your learning something as a 'finished' product can be dangerous to the end customer. Not being able to skateboard well means you're going to fall and bust your knees or elbows or face. It's dangerous to you, and potentially comedic to your compatriots. Publishing a website full of XSS/SQLI problems and storing passwords and credit card numbers in plain text is dangerous to every person using your site, the business it's backing, and countless others in a 'could cost them real money and personal harm' fashion. It's also hilarious to some people (see HBGary / Valve / etc. hacks). Compare software engineering to physical engineering - you don't let the kid out of highschool who's good with Lego Kinnects build a bridge or skyscraper. He goes through years of formal training, and then years more of on the job training, working his way up from Bus Stop Shelters to Sheds to Houses, etc. before he gets to that point. THAT is the reason I'm highly critical of the efforts of people I know (or don't know in some instances). This shit ACTUALLY MATTERS beyond 'hey isn't that neat?'. If you're doing some project on your laptop to learn a technology - Awesome, can I help you with questions/guidance? If you've published something or sold something as a product and it's full of issues that could be serious problems to people down the line, What the fuck is your problem? Unlike real engineers, who have a formal body of governance and redress for customers of shitty engineers, software engineering is the wild wild west. Many people just blame the computer, without realizing there was a person unqualified for the job sitting behind the computer making it work improperly. Until that changes (if ever), then I think it's the DUTY of geeks and nerds to challenge each other as harshly as possible, in an effort to prevent certain disaster.
dunstad 16y ago
"Every once in a while we need to reinvent the wheel. Not because we need more wheels, but because we need more inventors."

dexen 16y ago

There is reinventing the wheel and reinventing the wheel. It's cute when a person, learning as she goes, comes up with something that's been already invented. Only goes to show she understands the field. [1] It's unbelievably irritating when something that was widely implemented 10 or 20 or 30 years ago (and then even improved significantly) is now asserted as the next big thing. C'mon, be serious -_-' [2] [1] a nice guy thinks of swap (in userspace) just to hold strings of arbitrary length, calls it ``backed by file storage'': http://9fans.net/archive/2011/02/94 http://9fans.net/archive/2011/02/94 [2] no example I can think of ATM; but perhaps the above one could fit?

amalcon 16y ago
For [2], I'd normally suggest the thin client... except that it's got enough momentum that it may actually be the next big thing.
- dexen 16y ago
  Heh, perhaps Sun's demise helped thin client in a way? ;-)
bartonfink 16y ago
Garbage collection back in the 90's. Java really ran with that one.
- dexen 16y ago
  "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." - Guy Steele, Java spec co-author http://www.paulgraham.com/quotes.html http://www.paulgraham.com/quotes.html
Jach 16y ago
There are lots of examples for [2], but we should avoid listing them as they'll lead to arguments. In fact, we should also avoid listings for [1] since that can lead to anger venting.
zasz 16y ago
For [2]--NoSQL.
- dexen 16y ago
  Well yes and no. On one hand, NoSQL as ``let's ditch relational'' is [2] squared; especially as ditching relational because of SQL is ditching the only thing good about SQL. On the other hand, if NoSQL would mean ``let's have relational language better than SQL'', they hey, that's good! It's been tried [a] even before the SQL and tried [b] since then. It's not easy for something new to get traction with all the SQL code out there. But we will arrive there some day. -- [a] http://en.wikipedia.org/wiki/ISBL http://en.wikipedia.org/wiki/ISBL [b] http://en.wikipedia.org/wiki/Third_manifesto http://en.wikipedia.org/wiki/Third_manifesto NB., if you attack a hot & popular topic, you better provide some argumentation, or you will be downvoted to the ground :-(
hardy263 16y ago
[2]http://care.diabetesjournals.org/content/17/2/152.abstract http://care.diabetesjournals.org/content/17/2/152.abstract Well, not really 10 or 20 or 30 years ago. More like 400 years ago.

ZeroMinx 16y ago

> I don't know how many times I've watched eager hackers get lambasted for "reinventing the wheel," Depends on context.. If it's someone learning, or hacking on some personal project, go ahead! It's a great way to learn. However, if we're talking about a programmer in a commercial company, it's a different story. Your purpose is not to produce the most amount of your own code, your task is to produce a service of some sort. Unless the software/service you're working on a is a database, I expect you would use an existing database (assuming you need one). If the code you're creating needs to manipulate dates, I expect you use an existing library for such things. It will be available, it will be tested, it will handle all edge cases. Why would it be acceptable to spend a lot of time on reinventing that particular wheel, fixing bugs as they arise, etc?

agentultra 16y ago
I don't think it's entirely unreasonable to expect someone to use an available library for parsing dates. It's not a terribly good example. There are cases where "reinventing the wheel," is simply an ignorant statement. Perhaps the system in question has developed semantics for working with date-based data that the grammar of the existing date-parsing library's API doesn't match well with. This extremely contrived example may force the developers to write a lot of code for working around those inconsistencies which themselves can lead to bugs and maintenence headaches in the future. What if your lack-wit developer who wrote his own date-parsing library saw these problems and wrote a library whose API resolved them? Or perhaps in another scenario the existing libraries are simply inefficient for some metric of acceptable performance in your system. Maybe this ignorant developer simply writes a better library that allows you to do more. Either way, there is reason to believe that either scenario is valid. It is likely that writing a date parsing library is not going to be terribly useful. That doesn't mean it's impossible and so one must be willing to evaluate evidence and draw conclusions rather than hide behind blanket statements. What I'm really talking about is the attitude people have when they think someone is "reinventing the wheel." While some people are helpful and will politely point out that there are existing date-parsing libraries, there are a great many more it seems who will assume that the person who is "reinventing the wheel" is a clueless loser who wouldn't make such a "stupid mistake" if they were worth their salt. That kind of reaction isn't helpful at all.

generalk 16y ago

You're right. Sometimes. A hacker writing a quickie web server for the experience of doing so is laudable. This applies to lots of types of projects: toy OSes, social networking protocols, web frameworks, what have you. Exploration is fun, and key to the hacker spirit. The difficulty comes from knowing the limitations of your skills. I got my web programming chops by reading a bunch of PHP tutorials back in 1998 and throwing together some dummy pages that could read/write to a mysql database. Not long after I built a website for a good friend's business that was riddled with SQL injection and XSS holes. Luckily, we never got exploited, and years later on a rainy Sunday night I revisited the code and patched it up. Had we been hit, I don't know how badly that would have affected the company. The same goes for home-grown crypto: sure, you might be able to apply a function you wrote and get something that looks like cyphertext, and maybe it's a fun project to learn about crypto. But when you don't know any better, you think you've done it right and you might unintentionally swindle some folks into paying for completely insecure crypto.

count 16y ago
Here, here! Learning someething, and selling (for money, or otherwise) the not-acceptable-for-use side effect of your learning something as a 'finished' product can be dangerous to the end customer. Not being able to skateboard well means you're going to fall and bust your knees or elbows or face. It's dangerous to you, and potentially comedic to your compatriots. Publishing a website full of XSS/SQLI problems and storing passwords and credit card numbers in plain text is dangerous to every person using your site, the business it's backing, and countless others in a 'could cost them real money and personal harm' fashion. It's also hilarious to some people (see HBGary / Valve / etc. hacks). Compare software engineering to physical engineering - you don't let the kid out of highschool who's good with Lego Kinnects build a bridge or skyscraper. He goes through years of formal training, and then years more of on the job training, working his way up from Bus Stop Shelters to Sheds to Houses, etc. before he gets to that point. THAT is the reason I'm highly critical of the efforts of people I know (or don't know in some instances). This shit ACTUALLY MATTERS beyond 'hey isn't that neat?'. If you're doing some project on your laptop to learn a technology - Awesome, can I help you with questions/guidance? If you've published something or sold something as a product and it's full of issues that could be serious problems to people down the line, What the fuck is your problem? Unlike real engineers, who have a formal body of governance and redress for customers of shitty engineers, software engineering is the wild wild west. Many people just blame the computer, without realizing there was a person unqualified for the job sitting behind the computer making it work improperly. Until that changes (if ever), then I think it's the DUTY of geeks and nerds to challenge each other as harshly as possible, in an effort to prevent certain disaster.

dunstad 16y ago

"Every once in a while we need to reinvent the wheel. Not because we need more wheels, but because we need more inventors."