Learning a functional language (and way of thinking) was pretty enlightening to me.
I've also been looking into learning a bit about machine learning and data science via https://www.kaggle.com/. They run contests with some very interesting problems.
I don't know if these are the next 'big things' but i certainly don't regret learning them.
Me too. I found advanced C# expression shenanigans very confusing. Then I learned Haskell. Now I see the C# but think the Haskell and it is a lot easier to deal with even the most hardcore expression jujitsu that I see in the codebase.
If you've got a basic prototype and something you can show people you should be out talking to potential customers seeing if they'll buy it. In talking to a bunch of potential customers you'll find out a ton of actionable info. What your competition doesn't do, why they're not interested in your competition, other closely related services they would pay for.
Longer names don't automatically make it easier to read. Quite the opposite.
In this particular example, probably the function should be eliminated completely. It's easier to read (value x tax / 100) than to hunt for the spec of calculateTaxOverTransfer() to see what it does. (I'm ignoring the weirdness of representing tax in % instead of a float; that's probably another opportunity for a refactor).
Even if there is reasonable business justification to have a specific function to calculate taxes over transfer (maybe multiple callers, the logic is more complex than shown, or there's expectation that the rule might change) something named calc_tax() doesn't reduce the least of your ability to understand what it does.
If there's business ambiguity (like many types of taxes), then yes, you may need to differentiate which tax you're calculating. Even then, I still prefer the C convention and having a single function that receives a parameter indicating the tax to calculate, like calc_tax( tax_type, amount, rate ).
But one could argue that it's a different use case altogether, and you're better off by refactoring your code, and encapsulating the logic in a class that understands different objects passed as parameters for a calc_tax method.
The "what's in it for me" question is a good one. While very unintuitive, we've had no problem signing people up who are simply helpful types. There's a large population out there of talented people who enjoy helping others and this is the most impactful, time efficient way to do it.
At first we were thinking about offering money, but the economics of the model don't really work out. No matter what we do, since we're not guaranteed money, we can't guarantee experts money. Under that situation, we could offer them on average less than $60 an hour... at which point 1) it feels like work and 2) the people who become experts usually make 3x that.
After we worked on this for months, it turned out the best system was simply a volunteer system. Strange, eh?
I've been using bootstrap for a while now too and lately I've been trying out new libraries just to see if anything is better yet. On feel alone I didn't love foundation.
For a project that required pretty heavy customization I ended up using skeleton/react (http://getskeleton.com/) and enjoyed it.
I saw Semantic UI on here the other day and I may end up trying that out on my next project: http://semantic-ui.com
I've also been looking into learning a bit about machine learning and data science via https://www.kaggle.com/. They run contests with some very interesting problems.
I don't know if these are the next 'big things' but i certainly don't regret learning them.