title: Popularity-driven development
I wanted to tell you about that (even though it’s a tl;dr version of my online presence written from a certain perspective) to set a historical context for this article, because now after almost ten years it still happens – I mean it’s relatively easy to influence other developers by what you write or say. And people love to have an impact on something. Today we have way more communication channels than we had in 2005. A decade ago our online creditability was measured by a number of RSS subscribers in Feedburner, now it can be expressed in many ways, for example in how many people follow us on Twitter or how many developers starred our stuff on Github, not to mention number of retweets, likes and shares. Our community is amazingly active and socially engaged, as we love to read and explore new things. And your tool might be the next thing people will talk about. Actually it’s great, because a good work always deserves a great reception. Having a group of people that admire your hard work can be for some also one of the biggest motivational factors to write even more code and share better ideas. However, we tend to forget that „with great power comes great responsibility” and while above websites helped us solve a certain group of problems, they on the other hand introduced new issues as well as redefined the old ones (including our laziness).
Imagine you want to implement charts in your application. What you do? You probably don’t have time and money to write your own library. And it wouldn’t make sense anyway. So you either know a perfect fit from your past projects or have to find one on the web. If latter, you search for it in Google or Github. And what helps you make a decision is most likely information on how many devs have used it in their own projects. In times we live in this knowledge is often expressed by a number of followers/likes the project has gotten. So usually an ordinary developer takes the most popular project and tries to adapt it.
At this point it’s worth to realize that most of developers just can’t keep trying different things for ever or write their own solutions. Our budgets are not infinite and deadlines are tight. We need to make quick decisions. So we often measure the quality of software by a number of watch/stars at Github, while we don’t know why the project gathered so many and who clicked what. We don’t know the marketing efforts behind some of the numbers. And what is most important, how can we trust that let’s say 2000 developers have even used it? Maybe some of them clicked the star button, because they admire author’s efforts and like their blog posts? Whatever concern you’d had, you never know. A number of stars/followers is the most untrustworthy factor you can take under consideration to pick a tool for your project.
In these circumstances other variables matter. For instance, using Github you can always inspect issues reported by other users. It will help you have a better understanding of what is going on and what kind of problems you will face when using a program you consider for your own endeavor. You will also see how fast the bugs are resolved. After all, it’s crucial to know, whether a project I will be using for months is/will be actively maintained by the authors and fellow contributors. Does it have the roadmap? What version is it at? Is the versioning logical?
By the way, do you remember Prototype.js library? Its authors saluted to extending the native objects such as Function.prototype. Today we mark such things as a bad practice. Back then it was like – wow, do you see what we can do? Awesome man!. And there are more things that we appreciated and then abandoned. Not to mention „with” part of the language or advocating for avoiding new keyword as it can mess up with what this references to. Or declaring DOM events directly inside HTML code like <a onclick=””>, which now seems to be a foundation for reactive-dom-like tools. We actually don’t mind history as we are constantly busy with moving forward. We don’t try to understand other perspectives. We get fascinated by new and shiny things, even if they were not tested well yet or proved to be an actual improvement. We are hungry for inventing something for the sake of inventing so we create something, share it and ask for a feedback.
All that is great, however in this pursuit to be an author of something, only a few can acknowledge they can be mistaken. I know people from different industries. No one can argue harder about things than we do. Even when we’re not right. For me, being able to publicly confess that I was wrong was one of the most important events in my life. Having a big number of followers you need to be more responsible for your actions and have to consider different points of view. It can only improve your code and a way you act. This is one of major skills a developer can have. However, it’s in opposite of how we are thinking. We often feel we need to be smarter than others, know better and call Steve Jobs an uncle. It’s not a way to resolve problems. And that Stevie guy wasn’t alone, he had a great team behind.
And this way of thinking is our fault as we allowed to call us Ninja Developers or Rock Star Developers, whatever. It has been a cool terminology for a long time. However, it had negative effects in the community and credited us to be infallible. It gratified developers’ vanity. That brings up another subject of being able to constructively listen as an example of acting pragmatically. I think we are not always aware of importance of this and it doesn’t have to come down only to the code. What I mean is we don’t validate opinions of others. We imply that a developer with 10,000 followers on Twitter is a star and someone who knows programming better than you just because of numbers on Twitter. In the social media world, some of us seem to be under impression that a popular developer always has to be right. I’ve witnessed it several times when people actually took the number of their followers seriously as it would be a way for them to look better in front of other developers. Actually, smart developers and speakers don’t feel like rock stars and they don’t want to be called like that.
This race for a fame is also visible in a conference world. Conferences are often used by speakers as marketing tools. We often trust them just because they have spoken at conferences. Remember that having „speaker” on their business cards doesn’t necessarily mean they are good engineers. Most of them are, but from my organizer perspective there are people that make their PR on top of this which is just unfair.
Why does it all happen? I think the major problem lies in the fact that we became the consumers of high volume of information and we can’t process all of it. There is too much noise and we don’t have time to properly analyze the content we are served and check where it comes from. And our brains work faster, if we feed them with clear numbers. On the other hand, having a big number of followers is just tempting for authors.
Services like Github and Twitter have certainly improved our lives in a lot of areas. Thanks to them we can share gigantic portions of knowledge every day using an outstanding range of social media options like sharing and liking. These tools helped us understand each other better and learn about different perspectives. However, they also have negative implications. We forget that people are still human beings and they are not a number of followers as well as a popularity can be just one of the factors you can measure software with. Despite the social media revolution in our industry, programs still have bugs and people still make mistakes. Github stars definitely won’t fix this.