6 ms·

This can be said about plenty of things. Encryption is probably the most obvious; there's a lot of benefit from reading about and implementing various encryptio

This can be said about plenty of things. Encryption is probably the most obvious; there's a lot of benefit from reading about and implementing various encryption methods, and absolutely foolish to use any of that work in a setting where it might actually be attacked. The article is pointing out something that should be obvious; if you're making a widget as part of a larger task, your implementation will probably be lacking compared to one developed by a team solely focused on making the best widget they can. I could write an HTTP server or a threadpool or a database connection layer if I really wanted to, but thousands of talented people have invested millions of hours in those tasks already, and I'm not likely to do better than them on my own. Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. In my day job, I'm working on a (relatively) trivial problem that's never been done before, because there are about ten people in the world that need it. As a hobby I work on a text editor that is completely customized to my personal workflow, and which will probably never be used by anyone else.

aaron-lebo 9y ago
Indeed, but there are a lot of situations where a focused specialized widget made by a small team will be better than a general "best widget" made by a large team. The further you stray from the use cases of the "best widget" the worse it gets. Writing another HTTP server does seem like an inefficient expenditure of time, but we wouldn't have Nginx or smaller tools like Mongrel if the existing "best tools" were good enough. Game engines benefit you even more to be custom because the further your game strays from another Unity game, the further it stands out from the crowd of 100,000 smartphone games.
aphextron 9y ago
>Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. I remember gradually coming to accept this as an intermediate programmer. Once you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna write SOOO much complex code to solve this problem!" to "I bet I can pipe together 5 different CLI programs and not write a single line of code". You learn that it's all about layers of abstraction, and understanding that the human brain is far more useful and efficient at problem sets higher and higher on that scale of abstraction than it is at twiddling bits.
- brianwawok 9y ago
  Except for some of us, it isn't actually that fun to spend 5 minutes gluing together 6 libraries with no documentation, and 4 hours figuring out an undocumented bug deep in the source code. We would rather write someone from scratch :) Not that you can really afford to do that in a paid position, but for a side hobby like making a game? Absolutely. If you are making a game for fun, do what is fun to you.
  - Bartweiss 9y ago
    > 4 hours figuring out an undocumented bug deep in the source code For me at least, this is the real issue. Gluing together random libraries isn't fun, but it's fast and productive and lets me spend my energy and attention building something bigger than I could have solo. Gluing together broken libraries, though... Well, I thought encapsulation and black boxing were genius from the day I learned about them until the day I actually tried to build something nontrivial. Now I just think of Douglas Adams: "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair." Finding myself 5 pages deep in Google trying to fix a fundamentally broken Android API is way less pleasant, and ultimately slower, than working around the API altogether. It's also why all the people I know maintaining long-standing Rails projects have heartburn - using someone else's tools only saves time when those tools are trustworthy.
    - brianwawok 9y ago
      Everything is broken at some level. Your own code will have bugs just like the lib you import will. Usually what is nice is your own code has a lot less lines of code, so you SHOULD be able to find the bug sooner.
      - Bartweiss 9y ago
        Yep, I certainly don't mean to imply my code is right. But it's usually shorter, and it's mine. So when I find the bug, I can make the sane fix on the schedule I need. For particularly good OSS libraries, I guess providing a PR would only be a little slower than fixing internal code. But for anything poorly maintained, or with closed development, discovering those bugs often means writing an enormous workaround or switching libraries entirely - they just won't be fixed any time soon.
lucasime 9y ago
Would you mind sharing your text editor?
octalmage 9y ago
I once wrote an OAuth client library for a language that didn't have one and learned so much. Now any time I do anything OAuth related I feel that I have a better understanding.
anth1988 9y ago
> Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom or it relegates you to never doing an interesting thing.

aaron-lebo 9y ago

Indeed, but there are a lot of situations where a focused specialized widget made by a small team will be better than a general "best widget" made by a large team. The further you stray from the use cases of the "best widget" the worse it gets. Writing another HTTP server does seem like an inefficient expenditure of time, but we wouldn't have Nginx or smaller tools like Mongrel if the existing "best tools" were good enough. Game engines benefit you even more to be custom because the further your game strays from another Unity game, the further it stands out from the crowd of 100,000 smartphone games.

aphextron 9y ago

>Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. I remember gradually coming to accept this as an intermediate programmer. Once you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna write SOOO much complex code to solve this problem!" to "I bet I can pipe together 5 different CLI programs and not write a single line of code". You learn that it's all about layers of abstraction, and understanding that the human brain is far more useful and efficient at problem sets higher and higher on that scale of abstraction than it is at twiddling bits.

brianwawok 9y ago
Except for some of us, it isn't actually that fun to spend 5 minutes gluing together 6 libraries with no documentation, and 4 hours figuring out an undocumented bug deep in the source code. We would rather write someone from scratch :) Not that you can really afford to do that in a paid position, but for a side hobby like making a game? Absolutely. If you are making a game for fun, do what is fun to you.
- Bartweiss 9y ago
  > 4 hours figuring out an undocumented bug deep in the source code For me at least, this is the real issue. Gluing together random libraries isn't fun, but it's fast and productive and lets me spend my energy and attention building something bigger than I could have solo. Gluing together broken libraries, though... Well, I thought encapsulation and black boxing were genius from the day I learned about them until the day I actually tried to build something nontrivial. Now I just think of Douglas Adams: "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair." Finding myself 5 pages deep in Google trying to fix a fundamentally broken Android API is way less pleasant, and ultimately slower, than working around the API altogether. It's also why all the people I know maintaining long-standing Rails projects have heartburn - using someone else's tools only saves time when those tools are trustworthy.
  - brianwawok 9y ago
    Everything is broken at some level. Your own code will have bugs just like the lib you import will. Usually what is nice is your own code has a lot less lines of code, so you SHOULD be able to find the bug sooner.
    - Bartweiss 9y ago
      Yep, I certainly don't mean to imply my code is right. But it's usually shorter, and it's mine. So when I find the bug, I can make the sane fix on the schedule I need. For particularly good OSS libraries, I guess providing a PR would only be a little slower than fixing internal code. But for anything poorly maintained, or with closed development, discovering those bugs often means writing an enormous workaround or switching libraries entirely - they just won't be fixed any time soon.

lucasime 9y ago

Would you mind sharing your text editor?

octalmage 9y ago

I once wrote an OAuth client library for a language that didn't have one and learned so much. Now any time I do anything OAuth related I feel that I have a better understanding.

anth1988 9y ago

> Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom or it relegates you to never doing an interesting thing.