Hacker News Reader

Comment by aphextron | Hacker News Reader

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

View on HN

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.

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

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.

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.

I've got that same feeling when I started using zapier. The amount of tasks you can automate without modifying nor writing any code is incredible. Since last year, I added webhooks to every action in every system I make, and then I use both zapier and huginn to send analytics, add users to mail groups, notify me when something goes wrong, and even make systems that write everything to Google sheets.

When do you use Zapier, and when do you use Hugin, and when both? Thanks (:

Piping together the other programs is certainly practical and efficient...but spending a whole ton of time writing complex code is fun. I tend to take the practical route at work, an the impractical route when I'm writing something for fun.

In my perfect world, I'd be writing something for which there are no existing libraries to lean on.

Reply on news.ycombinator.com