For the foreseeable future, people (or "developers") are writing the world's software. In 2020, there were ~56M+ developers on Github with a predicted 100M+ by 2025 (almost doubling in 5 years!!). Many more people are writing software than ever before.
As more developers collaborate, complexity is a natural outcome. As complexity rises, it’s easy for technical matters to consume all our attention. We have to stay focused on insight and, frankly, thinking. Are we asking the right questions? Is this the right data to be looking at? What are we trying to understand? And if there are more of us now, how do we shift our behavior in order to find answers together?
The power of "yes, and"
Back in high school, I took some drama classes and was in a couple of plays (even acting as Hamlet). As an introvert, it was a stretch for me to overcome the overwhelming intimidation of performing. I mean, who was I to play characters in Shakespeare or Gilbert and Sullivan?
To help, my drama teacher used to make us do improv exercises.
People talk about the magic of being in flow. You could feel it in great improv exercises. As I performed, I learned that we as a drama group could create new incredible moments together. The power of creativity, positivity and fun helped me realize: I don't need to be Shakespeare every time - and if I do, I'm not going it alone. Anyone can come up with something that had an impact on people - made them cry, made them laugh.You could literally create something out of nothing with another person just by working together. All that creativity can come to life if you got over your own intimidation, and tapped into creativity with other people.
The soloist approach (my early missteps)
As I started my career in software development, I took the soloist approach. I felt I had to do it all on my own. The stress and pressure of having to figure it all out myself was exhausting. I know it was influenced by toxicity and lack of inclusion in the industry. So I fell back into the pattern of going it alone. While we might work on a pull request (PR) solo, our teammates helped with reviews. I soon realized the people who were working together moved much faster and were less stressed.
When I started pair programming, my world opened up. Suddenly my colleagues could bring so much to my work - iteration, additive thinking, acknowledgement of my work.However, pairing and real-time collaboration can also be intimidating. You make mistakes in the presence of someone else. There is so much vulnerability in creating with someone else.
Improvising with code
But whether in go it alone or pair program, we're more dependent on code written by other people. We are more likely to share code we've written. That is true in open source software (OSS) and in proprietary software. The open source way of developing has greatly influenced our interactions as software developers. There is too much software to write for any one person to do it on their own.OSS models the principles of Improv - to build software, share it with the world, others "add to it" and it evolves into something new - bigger and better through contributions.
Observable: a new stage
At Observable, we’ve been inspired by the transformative power of open source: code sharing and open collaboration are now the norm for great software. Those same principles guide the core experience of building visualizations on our platform, creating a community where people can build on and learn from each other.
Observable is a place where people work together with data, where insights are not just discovered but shared. People are diverse and complex so are the projects and companies they work for. On Observable, we believe collaboration leads to sharing and communication between people. Collaboration permeates everything we do.
And so here I am in 2021 considering how we can empower even greater creativity and collaboration as we create dataviz and write more software.
Even though we may pair program on occasion, we are often/mostly working by ourselves on a PR. You see what what your teammate proposes only after editing. You might have conflicts that you have to merge after the fact. You might even overwrite each other's unevaluated edits.
I want us to change the frequency and way in which people connect and create.We quickly forget the countless iterations and ugliness that led to the software we use day to day. We often have completely unrealistic expectations of perfection for our own software.
One of the biggest differences between software developers is our tolerance for mistakes as part of the creative process. Good software developers will keep iterating and trying to make it better.At Observable, we want to normalize the iterative and collaborative process. Let's replace our fear of mistakes and blame with our love of sharing knowledge and learning together. Let's truly co-create.
Check out this example of several developers working together in a multi-player environment.
// twitch vid import
- Maria to work with Preston to add this vid //
For example, Observable gives you true multi-player editing. As soon as you type new characters in a cell, your changes will be immediately reflected to all your collaborators currently viewing the notebook. No more worrying about staying out of each other's way. No more stepping on each other's toes. Watch as your teammates create.
You can see your teammates while they type. It's like an instant mindmeld.
All of the previous benefits of Observable are still there — your changes to cells are immediately visible, as shown in this next example.
To make the power of data available to all, we must help each other, share techniques, tools, and insights with the world. We must enable everyone to collaborate, not just the experts or the coders.
At Observable, we are motivated by the belief in the power of collaboration. Creativity and innovation happens by working together. If we can make collaboration more accessible, approachable, and inclusive — if we can improve how people learn from each other and share insights — it's like making the world just a little bit more informed. We believe this will make us all a little bit better equipped to understand and solve the problems around us.
I learned suffering is not required. There is always a more painful way to do things. The painful way may have accomplished a lot, built a lot of code, but it's not the only way, and the experience of improv, of collaborating, of software as a team sport, is the experience of Observable.
Over the coming months, we’re going to share more about collaboration in Observable. I think you’ll see that it allows you to iterate faster, improves your communication and collaboration with others, and helps you make better decisions. We'll provide blog posts, example notebooks, and even some meetups. If you’re interested in following along with this series, you can subscribe here.
And, if you have used Observable in a way that you think would help other developers, we’d love to hear from you. You can reach out at email@example.com or DM on Twitter.
Join us as we collaborate. Let's have some fun along the way.