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

I don't mean to troll, but isn't exploration and figuring things out a huge part of creating software. There are require.js examples apps on github , Q and As on Stackoverflow, and open source code that's available for digging deep. It only took me ~2 Days to get the gist of require.

Is it no longer good enough that the open source community builds great free things for us to use? Do they now have to upload the know how of these tools to the users brains in a Matrix like fashion?




Getting things done in a timely manner and under budget is an even bigger part of it. Having to learn "new" things (this is distinct from "different" things and "better" things) leaves significantly less time to achieve productivity.

In terms of developer time, 2 days is rather expensive.

If this is your own pet project, then by all means spend the time necessary to learn it. Or if you intend to "Move Fast and Break Things", then spending time to learn things is also good. But if you're running a business with "x" which has worked efficiently for years and isn't broken, "y" is not necessary.


> But if you're running a business with "x" which has worked efficiently for years and isn't broken, "y" is not necessary.

You are using words like efficiently and phrases like "isn't broken" without quantification. Having only done things one way, and it doing it's job does not mean it's efficient or not broken. Only that you don't know a more efficient way or it hasn't been proven to break yet.

While getting things out the door is important, it's also just as important to not base assumptions without actually quantifying. And you can't do that if you assume the mantra of "if it ain't broke, don't fix it."

It's a balance that, as a professional, you have to manage.


On the contrary, efficiency is quantifiable. As is determining whether or not something is broken or prone to breaking. I.E. Brittleness becomes obvious under heavy load.

This isn't a "if it ain't broke, don't fix it" either. You push things to the breaking point and see if that's projected in your growth (maybe a bit beyond what's projected), but maintainability and efficiency don't hinge on what's new. It hinges on what works and if what works is what you have, you don't waste time with new things.

But back to the point... You learn "new" things when you figure existing things aren't up to the task or you try to see if amending x will get you further. y Is still not necessary if it will.


> On the contrary, efficiency is quantifiable

Contrary to what? I said as much. The problem is that you need to quantify that efficiency. You can't just say "x is efficient."

> But if you're running a business with "x" which has worked efficiently for years and isn't broken, "y" is not necessary.

So, x has worked efficiently for years? Based on what? How are you quantifying that? And how can you say it's efficient without having some yardstick to measure against? By not looking at other technologies, you can't really say whether it is still efficient or not.

Efficiency is a moving target.


>> but isn't exploration and figuring things out a huge part of creating software

Absolutely, but each developer will make that judgement and require.js shouldn't be victims of those who give up at the first hurdle.

>> There are require.js examples apps on github , Q and As on Stackoverflow, and open source code that's available for digging deep

That's good to hear. I will at some point give it another shot and it's good to know there are examples and support out there. It was a couple of years ago when I did look into it, I remember getting confused and the on site documentation didn't really steer me in the right direction. The documentation doesn't appear to have changed much in that time. It can be hard work and time consuming having to dig deep to solve a problem.

>> Do they now have to upload the know how of these tools to the users brains in a Matrix like fashion?

The OSC are not obliged to provide a better user experience in getting new users to adopt their software. Of course not. But if they want to have as many developers appreciating their hard work, then you know, it doesn't hurt.

>> It only took me ~2 Days to get the gist of require.

2 days to learn how to use it is something I cannot afford for a workflow improvement over a show-stopper problem. If it was something I could do in a hour to get an understanding and start porting my application with the knowledge that I'm not going to be stuck for 2 days, then that would be a different situation.


Learning is one thing, getting frustrated to the point of yelling "Why the hell doesn't this work?" is another. I would say Backbone is an example of the former and requireJS an example of the latter, but that's just me.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: