Dualistic nature of APIOps activities

I’ve been obsessed with community building for the past 10 years or so. I like the phase when new community is emerging, there’s a lot we don’t know yet, battling for the attention of the target group, findig ways to satisfy their needs and to balance it financially. It resembles (even vaguely) startup life.

The same applies to APIOps community as well. The term was invented already 2015 and yet the activities really started to emerge beginning of 2017. That was mostly due to the reason that suitable person with passion towards the subject field was not available before Feb 2017.

Dualistic nature of activities

For the past 6 months or so I’ve been ramping up the community. Based on those experiences it looks now that we might need to have at least two kind of activities: meetups and live coding. Both modes have different purpose:

  • Meetups feed our group cohesion, knowledge and social needs
  • Live API related coding (APIOpsLive) feed our practical skills

So far APIOpsLive has been tested out once, but results seem promising. In the first session we had 49 participants (peak).

That is more than we have had participants in any of the physical meetups so far even though meetups are broadcasted to Youtube. Online factor does not explain the difference completely. After giving some thought on the second activity mode, I’ve come to conclusion that both are needed.

Meetups — social events

  • We are social creatures anyway. We want to meet people with same interests. APIOps meetups are social events for API enthusiasts.
  • Gathering physically together enables us to meet other people, get familiar with them.
  • After meeting physically, we people tend to cooperate more easily in digital form.
  • Meetups are about stories — stories feed our knowledge about technology selection and reasoning behind it, selected paths in implementing or consumsing APIs.
  • Stories are simplified descriptions of experiments, learning experiences and failures as well as success — stories appeal us humans.
  • Events are like camp fires — relaxed and fun.
  • Giving a presentation in meetup is low barrier activity. Details are most often not discussed and mistakes not so easily pinpointed. Presentations are forgiving compared to live coding.

APIOpsLive — entertaining learning experiences

  • Live API coding (consumption, design, building or managing related) is about practical skills.
  • Developers speak and think code. This is possibly the reason live coding sessions intrigue developers.
  • Live coding requires gutts and skills as well as confidence. Novice is not likely to do live coding in front of dozens of participants. Our intention is not to pressure presenters but to offer them a chance to enjoy and have fun in relaxed atmosphere. Thus we encourage developers of all skill levels to be bold and have courage to be “on stage”.
  • Live coding is learning experience for both, the audience and the person doing the live coding. During the session, a lot of mistakes are done, problem situations occur and those have to be solved right away.
  • APIOpsLive sessions always contain interaction. Platforms used contain chatting window for interaction. Live coding without interaction would be less intriguing. We people also want to participate, contribute to the process and result.
  • In a way, APIOpsLive contains familiar elements of Pair Programming, where one is writing the code and the other is reviewing it and providing feedback. In this case difference is that we have multiple eyes and comments coming from several spectators.

We’ve seen only the beginning

APIOpsLive as a concept is evolving still and most likely has not found the final form yet. That will take some more rounds. Even after that it will most likely change at least slightly over time.

One change has been suggested for APIOpsLive by the first guru on stage last Sunday. Viljami suggested that in the future when building API from scratch it would always contain two roles: the one implementing API and the one consuming the API. In other words some of the participants would try out the API while implementing it. That might happen for example with Postman or even inside own code written on local machine. Not a bad idea! That would raise the level of interaction to the next level and would help API developer to focus on Developer eXperience too.