A solution path is not THE solution path

Feeds. Articles. Conferences. Discussions. Meetups.

We get a lot of inputs from everywhere. If the big players do it, why shouldn't we? Well, my short quick answer is that, we're not them. Does that ring a bell?

We are all aware that there's the condescending behavior towards implementations and languages. If this is so and so, W(hat) W(ould) J(esus.. err, Java) D(o)?

Not that I like Java over Rails or Ruby or PHP or Python but, I do believe that picking one language over the other (wisely) would yield good amplified results. Of course, having said that, the opposite would also be true. If you run your application on the wrong set of premises then the language wouldn't probably do anything good for you.

Each tool and solution path are based on ground assumptions in order for it to work optimally for you. Knowing what your problem is beforehand and seek out the solution is the way to go.

For so long a time, I watched people get awed when presented by a good tool and then start thinking about what problem it can solve. From experience, this wouldn't work because you are matching a shaped tool into a problem it doesn't fit in.

So, my general advise is to study the problem. Get great minds together and pick their brains to think out of the box and see what happens next. When you've identified the damage and size of the problem, then that's the time you start seeking for tools that can solve your problem.

Its okay to keep an open mind at conferences and meetups and discussions to collect ideas. Debate a lot. Debate brings out the conflicts and more ideas presented on the table.

At the end of the day, there would be several solution paths, but only you will know which one is THE solution for you.