Around a decade ago, a big part of coding culture changed.
What had often been a solitary pursuit, or one where collaboration happened with a defined set of colleagues within a company or open source project, burst open into a much more intrinsically social experience. Everything from how we share code to how we find answers to how we discover new technologies became far more linked to the attitudes and actions of other programmers.
In short, the people who make software got networked just like their computers had been in the preceding decades.
The impact of network effects on coding culture has manifested itself in many ways, but some of the most visible are worth examining:
- For knowledge about coding issues, and answers to common questions, Stack Overflow rose and quickly became a dominant source of reliable information about programming. (Requisite disclaimer: I’m on the board of Stack Overflow, though my experience here is based on being a coder who just relies on it for useful answers.) Though the barriers to participation in the Stack Overflow community are well-known, there’s no doubt that its enabling of a network of knowledge around coding answers amplified the discoverability of programming information, and accelerated the idea of social signal being a strong component of technology adoption. A framework or toolkit that has its own, actively answered tag on Stack Overflow is much more likely to get new adopters.
- A similar pattern followed for collaborating around code: GitHub rose a decade ago as a powerful platform for sharing each commit to a project. Though its value was presented as being about popularizing the then-nascent distributed version control tool Git, the social value of GitHub has extended to being a signal of the value or reliability of software hosted on the platform. Counting the number of stars or forks or watchers on a project acts as a proxy for how much the code can be trusted. GitHub has real barriers, like the difficulty of learning git or the obtuseness of organizing around changes to a project, rather than the project itself, and all of these factors can make it difficult for some users to participate in the network. But despite those barriers, social signals on GitHub deeply shape the adoption of tools and technologies by developers.
- Finally, there are the networked information sources for news and discussion, primary among them being Hacker News. Though it’s notoriously the most hostile of these large, networked coder communities, it inarguably helps promote and elevate new technologies and new ideas around how to create software. Hacker News’ amplification of tools often helps them reach critical mass in adoption, and discussion of a product is another form of social signal that many in the coding world use to judge a particular platform. To a lesser degree, more product-focused communities like Product Hunt also fulfill some of this function. (And Product Hunt does this while being far more welcoming.)
In each of these cases, if we look past the flaws of the communities that enable them, we see a deeper pattern: software being evaluated based on its social success and social merits, rather than just some ostensibly “objective” technical merit.
Technology has always existed in a social context, and evaluations of the risk or reliability of a tech platform have always relied on social indicators. But the acceleration of these patterns, and the extending of the social networks around code to include the majority of working coders, means that institutional indicators (like “which company funds its development?”) now come second to community-based signals.
Similarly, top-down indications of technical maturity like documentation (often an artifact of outside investment in making a technology accessible to a new audience) are complemented, or even eclipsed, by bottoms-up indicators like how many people have bookmarked a framework, or how many people answer comments about a toolkit. Even purely social factors like the number of participants in a Gitter or Slack chat room about a project, or the number of people who follow a project on social media, are all weighed when we look at new technology.
Then There’s The Law
Though nearly everything he shares on social media these days makes me want to smash my head into my desk, longtime software blogger Jeff Atwood has had a number of valuable insights over the years. Perhaps none was more prescient than the insight captured in his eponymous law:
Of course, I work on Glitch all day long, so you know our team has got an opinion on this. Don’t worry: Glitch can run code in almost any common language. We’ve got Python and PHP and Ruby projects happily running in the community.
We also look at the network value of apps, libraries, modules, and code snippets that live in the Glitch ecosystem, and we think focusing our attention will yield dividends as we start to build more tooling for coders and apply newer developments in machine learning to help make coding easier. Picking a domain helps ensure that the things we create are valuable and applicable and immediately useful, instead of diffuse efforts to serve all languages without really picking one to be great at.
The truth is, we’ve never seen one open language become a nearly-universal programming language for coders. We don’t know what kind of benefits might accrue if the majority of coding effort starts to happen in one language, unless there’s a particular reason to use a domain-specific language that insists we do otherwise.
We just might be on the precipice of an era in coding that’s unprecedented, where we might actually see something new in the patterns of adoption and usage of an entire programming language. That potential has us excited, and waiting with bated breath to see how the whole ecosystem plays out. But even more than that, we’re excited that all of these developments will allow the Glitch community to make apps that are even more expressive and meaningful, while being even easier to realize in code.
We can’t wait to see what you create!