In the past few years, there has been an explosion in the availability of various tools, database, frameworks, libraries, and so on, all of which are supposed to help you write software better and faster. For someone who is starting to learn programming, all these noise can be very confusing. Even for an experienced programmer, all these stuff can be very distracting as well. The much discussed Javascript fatigue is a symptom of the problem. Unfortunately, I’m not here to offer an anwer on how to deal with all that. I simply would like to point out some of the things that you should be aware of while wading through all these noise.

The content of this post is inspired by this talk by Ross Tuck below, which you should definitely check out. He talked about a lot of the things that I have been thinking, and he was able to present those ideas more eloquently than I could.

So, here is the thing; no one really knows what is the “best” tools or framework out there is. Like most things in software engineering, the answer to such question is, and has always been “it depends”. The best tools for the job depends on what the problem you need to solve, the constraints you face, what you already know, and so on, and any claims of “The One True Way” should be faced with a generous amount of scepticism.

For better or worse, the startup booms that has been going on in the past few years has made the field of software very lucrative, and there are money to be made in selling the tools that supports the making of software. One side effect of that is, like what Ross said in his talk, developers are becoming more of both the target and the source of marketing. The problem is, many developers (myself included) like to think of themselves as being immune to marketing, and that all their decisions are made based on objective evaluations of strengths and weaknesses of the available options. “Meritocracy” definitely ranks pretty high up there among programmers' favorite words.

There are many factors that come into consideration when you’re trying to make a decision on which tools/framework to use for a project. What you already know, what are the requirements of the project, and of course, the popularity of the tool. That last one is becoming more and more of a deciding factor nowadays, which may sounds a little weird. Shouldn’t a tool be picked for what it is able to provide? Why does it matter how popular it is? The fact is, the popularity of a tool does matter. More popular tools would have more libraries written around it, and there will also be more resources that can help you learn it.

What makes a software popular though? And what does it mean for a software tool to be popular?

It is not necessarily by being the “best”. Not necessarily by being the choice of many software developers to build their projects with. It is because there are people who want them to be popular, and they put the effort to make them so. So, yes, marketing. Not that marketing is bad thing, just that this means that just because something is popular, doesn’t mean it is also good.

Once a software reach a certain level of popularity, much of the marketing for the tool comes from the users (the programmers) themselves. Most are doing this because they have benefitted from the tool and would like to promote the software because they truly believe these tools would help other people write better software faster and easier. Some though, may simply jumped on the bandwagon because it can be profitable. Being positioned as an expert on a popular software tool can be lucrative. From speaking engagement, workshops opportunity, knowledge product sales, or job offers are some of the things that can come from such position. Which is one of the driver of the hypes surrounding software tools.

So, how does one wade through all these hype-driven software development resources? Unfortunately, I don’t have an answer. I am still trying to figure it out myself. But that is something that you need to keep in mind while consuming all these abundance of learning resources. If someone often speaks of a software tool in absolute term, being overly critical of any criticism of the tool, or dismissing the value of learning and taking ideas from alternative tools, you should assume that person may have objectives other than sharing knowldge and promote good software engineering ideas.

Learn the basics, and know your tools well. Try not to get distracted by all the hype-noise because that is all there is; noise. All that noise aren’t necessarily the gospel of the software development that you must learn. People often have their own incentives for driving up the hype, and you won’t be missing out on anything important by ignoring them.