In this session from DevRelCon London 2019, Max Kahan talks about the importance of play in developer education.
Max: I am going to be talking about engaging 9-year-old software developers. So, quick show of hands. If that’s okay with you guys.
Audience member: Whose 9-year-old is it?
Max: I will tell you very shortly. Okay, can you raise your hand if you have ever used a bank card, or if you have booked a flight or a train, or if you have ever seen a doctor, or if you have taken out some kind of insurance in your life? I think that’s everybody. Okay. Keep your hand up if you have heard of an API. I’m in the right room that’s great. Okay, keep your hand up if you know what asynchronous messaging is. We’re doing well today, guys, well done! Thank you very much that’s awesome.
When I ask this of developers, they’re not so clued in on the whole asynchronous messaging thing. I’m attached to a product; I’m attached to a messaging product at IBM. Generally, when we ask developers to use our product, they look something like this. [Picture of a sad child appears onscreen] That’s a problem, I hope that’s pretty clear.
I want to change that perception. So what’s going on here? First of all, I do want to say that the product that work on is 26-years-old. I am 25-years-old. This product does not feel intuitive. When I first started using this I was not quite sure how this whole thing should be going. It doesn’t feel intuitive and natural. The way I learned to code is not the way this thing is written. This thing was really aimed at SysAdmins and people who would organize infrastructure, not at the app developers themselves. It can feel hard to use, it can feel like, “Oh this thing, feels clunky. It feels, it’s very powerful, but it’s hard to get to understand why that value is there”. Finally, it’s not the coolest thing in the world. It’s not flavor of the month anymore. As such, it is totally not hip. What can I say? We decided that we needed to do something about that.
Why should we care is the other question. So if I said to you, messaging is very powerful, it powers the things we talked about earlier. You know all of the stuff, about the bank card. Those are all done through asynchronous messaging. “But why should I care?” some people have said to me. I have gone and talked to developers and they would say, “Why don’t I just write an API?”, “Why don’t I just use REST to do this?”
There are some properties that you really need that REST doesn’t really cater for. Asynchronous is a really key property, and transactionality as well. These sort of things that are much harder to, you can do it, but it’s much harder to do that with REST. Whereas this stuff is built into messaging. It’s baked into how messaging operates. So we want to change this perception.
How can we help them? First of all, we need to make it easier to see the value, easier for us to understand, and show developers why they should be using messaging and why they should care. We also need to make it easy to try out. We need to give people opportunities to play because right now, it’s pretty hard to get going, so we want to give them that chance.
What we really wanted to do is let people play. We want people to be curious and have a go because that really is how people learn. So we decided we wanted to make something that would appeal to everybody. We decided we wanted to make something that anybody would be able to use or have a look at and understand the value of messaging. So we decided to target the most difficult demographic of all I think that we were able to target, children.
Children are very discerning customers. As a result, we wanted to really make sure that we would appeal to them. So we decided to use Scratch. For anybody that doesn’t know, Scratch is an open source project developed at MIT. Basically, it’s a visual programming style. It lets people click and drag things together like little blocks, and that shows the syntax of the program without worrying about the syntax of the program. I decided to go away and try to make some things so that we could use messaging with Scratch. I wrote these blocks.These are an extension onto Scratch that I was able to make and plug into Scratch’s extension site, ScratchX. So we had some way of doing messaging now through Scratch. We were actually able to try this out.
I was asked a little bit earlier, “Where does my 9-year-old come in?” Well we wanted the kids to be able to see the value. We decided to find a real test subject. My team lead has a 9 year old son. Using this and using this program, he was actually able to create a little game in Scratch. But he was also able to save his score by putting it onto a messaging queue. He was able to understand why he was doing that and why he was able to see his high scores again. I saw that and thought well, that’s awesome. And if he can get that much from that, developers should really be able to get something from that.
I went away and I wrote this application here. It is a little weird, but essentially what it’s doing is it’s sending you a series of messages through a messaging server into this box of flashy lights that I am holding in my hand right now. So what basically is happening is in this program, this runs in a browser and this communicates with a Raspberry Pi which is inside this. You guys know what a Raspberry Pi is? It’s a very small computer. Basically, we’re allowing that to actually send it messages and give it instructions. Then, we’re taking the score from here and we’re putting it back to the program. What this lets you do is give a sequence of lights to be played on here, and the user then has to try and remember that sequence and play it back. It’s been likened to another game that was quite popular a while back. For legal reasons, I can’t mention what the game is but it’s to do with memory and repetition of colors.
This has allowed us to actually go and talk to developers. We’ve been able to actually get to developer conferences. Historically, as a messaging product, we have only really talked to infrastructure people and talked at messaging conferences. We’ve not talked to developers out in the wild before. This really gives us space to go in and do that, go man a booth and actually talk to people. It meant that we can actually now have a conversation with our developers, and with people who maybe want to understand why they should use messaging and what the value is. We found that they can see that value now. We found that they really do understand what’s going on here. But most importantly, I think that you would agree, that people actually get to have a play with something and they get to have some fun. And that really is kind of the key thing here, is that people really like to be able to exploit that.
People have said some really nice things about what we have been doing, but really this hit home towards as something that we as a product really do need and really do value. It’s helped us as a department, it’s helped us as a product to really get to people and explore with them. I think that whatever your product is, whatever kind of thing you are working on, if you want people to see that value, it’s really important to get it to a way that people can explore and be curious and let them play and be creative.
That’s all I really have to say. I have these details and I’ll be around all of tomorrow and tonight if you want to have a chat with me. Otherwise, Thank you very much.
All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech, if you serve them well.
Are dev rel teams just here to make everyone feel good about using a technology or is there a deeper responsibility?