Popularity-driven development
The article comes from Damian Wielgosik’s (Functionite’s CEO) blog, ferrante.pl.
For the last ten years I have been publishing various things on the web about JavaScript and front-end development. I also have organized meetups and conferences like Front-Trends or Meet.js Summit. I’ve met a lot of people, worked on exciting projects, got to know different views on certain topics and heard many exciting life stories, either good or bad. Recently, when I looked back at all of these moments I noticed I used social media channels to make them happen. I wasn’t aware though of the responsibility I had.
I was there
Truth be told, I went down the path of yet another teenager enchanted by countless possibilities of web technologies that became a professional front-end developer who is paid for his job. In 2007, at the beginning of my journey I started this blog. I remember the JavaScript tutorial I’ve written which gained a lot of readers, even though I wasn’t the expert in the field. Although I had like 20% of my current JavaScript skills, the entry-level articles I wrote got some nice publicity. People were massively sharing them and positive comments were endless. Shortly I became a recognizable JavaScript developer in the Polish community and people seemed to listen to what I have to say. I got a good creditability. It convinced me to write more things. After some time I realized I influence the choices of other developers. So when I recommended jQuery, some people followed me in this opinion and tried it. Although it was just my personal preference and I didn’t have skills to judge it well, I felt like I helped them make a choice for a good reason. I found myself special. It’s a great position to be for a 18 years old developer, right?
With great power comes great responsibility
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’s even more common — I mean it’s not demanding 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 apps helped us solve some of the problems, they on the other hand introduced new issues as well as redefined the old ones (including our laziness).
Numbers
Imagine you want to add charts to 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 eventually 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 us 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, but 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 while using a program you consider for your next 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?
Responsibility — think before you share
Another thing related to our social media presence is a responsibility for others. Each day the front-end community welcomes a new member who has a little experience and asks questions like how should I start? what library to use? And more. Unfortunately, when answering these questions, we — as more experienced developers — don’t want to leave our comfort zone and understand who asked them and why. Thus, although we want to help, we give answers that are most suitable for ourselves. We simply answer how we would learn JavaScript, if we started today. We don’t consider other people’s background and motivation that comes with a question. Beginners don’t want to hear “learn Angular.js”, because you use it. They look for an answer crafted well for the place they come from. Using a strongly opinionated tool won’t help them learn JavaScript. Instead, it’s worth to look back and see how we used to learn JavaScript and based on that give useful tips that will help somebody grow as a JS developer.
I know better attitude
By the way, do you remember Prototype.js library? Its authors saluted to extending the native objects such as Function.prototype. Today we name such things as bad practices. Back then, it was like — wow, do you see what we can do? Awesome man!. And there are more things that we used to appreciate 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, this is how we invent things, however in this pursuit to become an author of anything, only a few can acknowledge they can be mistaken. 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.
I’m not a ninja
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 that is 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 think on our own. We imply that a developer with 10,000 followers on Twitter is a star and someone who knows how to program better than you just because of the numbers. 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.
Evangelists
Increase in popularity of Twitter and Github also made up a fantastic opportunity for creating positions like Developer Relations Manager/Evengelist. Companies hire those people to talk to other developers and advocate their products. Some of them (yes, mainly browser vendors!) have also a privilege to talk about brand new HTML5 APIs, because their companies work on them. Following developer evangelists is a perfect way to get to know about new technologies and stay up to date with what’s going on in the market. However, when I chat with evangelists or hear about their work, they mostly focus on writing short snippets of code and traveling around the world to give talks. While I appreciate this work, I think it’s actually not as cool as it sounds. These people always complain of too many conferences they have to speak at as they are just tired of traveling here and there every week. Sometimes you feel you deal with tired people who don’t like their jobs. Sadly, they usually don’t code apps anymore because of other duties, while one of their main tasks remains to help us write better applications thanks to technologies they evangelize for. In age of the extremely fast JavaScript growth that doesn’t sound convincing.
People, not numbers!
Why does it all happen? I think the major problem lies in the fact that we became the consumers of an overwhelming piece 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.
Originally published at ferrante.pl.
