Interview Intro

‍

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started. 

‍

Today I'm speaking to Steve DeveloperSteve Coochin. And yes, that is his real name. This is a man whose devolution to developer relations means that he's refactored his own name, and it only gets better from there. In this episode, we talk about the two generations of developer advocates, and how our experiences as part of the first generation are different from those of this new generation that can go straight into developer relations as a career. 

‍

We also talk about the difference between working for companies where developers are the customer base versus the companies where developers simply work for the customers. This I was a really fun chat. All right, let's get started. [0:00:58]

‍

Main Interview

Steve Coochin

‍

Richard Rodger:  [0:00:59] Welcome to the Fireside with Voxgig Podcast. Today, we have DeveloperSteve. Hello, DeveloperSteve, how are you? [0:01:04]

‍

Steve Coochin:  [0:01:06] Hello, I am well, thank you. And hello to everyone listening? [0:01:08]

‍

Richard Rodger:  [0:01:09]  Fabulous. So, DeveloperSteve is actually your real name on your passport; isn't that right? [0:01:15]

‍

Steve Coochin:  [0:01:17] It is; it is actually my legal middle name. [0:01:19]

‍

Richard Rodger:  [0:01:21] This, folks, is dedication to the art of developer advocacy. Respect, Steve, respect. [0:01:27]

‍

Steve Coochin:  [0:01:30] Thank you. It was a – I've been an advocate or an evangelist – same thing really – but yeah, I've been a developer advocate for so many years now, coming up to 10 years, which does not make me feel old one bit. But just through my travels over the years, being able to work with so many amazing communities. 

‍

People started calling me DeveloperSteve, so when I got married in 2018, we combined – me and my wife combined our surnames. So, Cooper plus Howchin became Coochin, which is my married name. So, when I legally changed that, I thought, I'm going to make it my middle name. My actual legal middle name is – or my legal name, is Steven DeveloperSteve Coochin. [0:02:10]

‍

Richard Rodger:  [0:02:11] Wow. So, let me get this straight. You refactored your name. [0:02:15]

‍

Steve Coochin:  [0:02:17] I did. I've never thought of it like that, but yes, I did. [0:02:20]

‍

Richard Rodger:  [0:02:22] Naming is one of the most important things in computer science, right? [0:02:24]

‍

Steve Coochin:  [0:02:26] This is true. And that still plagues me today, is what am I going to call this function variable, this thing? What am I going to call it? Because someone's going to see it at some point in time. [0:02:34]

‍

Richard Rodger:  [0:02:35] It's an excuse to take a 15-minute coffee break to think about the design of your code. Naming, very important. [0:02:45]

‍

Steve Coochin:  [0:02:45] Exactly, yeah. [0:02:47]

‍

Richard Rodger:  [0:02:47] Okay, so the reason we are talking is because you're totally awesome developer advocate and you saved my life with a specific technical problem that I had with a client, which is really awesome. So, what happened was – you work for Lumigo and there was a Lumigo error message being generated by a third-party library. And my client was feeling a little nervous about all the error messages; it seemed to be non-fatal. 

‍

And I got in touch with you, because I was following you on Twitter because of your advocacy work. And you guys in Lumigo went off; you figured out what was wrong in somebody else's library, which was awesome. You I think had some interactions with a third party and it's eventually fixed. But the experience for me as a developer using your system was totally awesome. So, is this by design; did it just happen?  Is it Lumigo's policy or is it just stuff that – ways that you've learned to work with people over the years? Why was it such a good experience for me? [0:03:57]

‍

Steve Coochin:  [0:04:00] First of all, that was very amazing to hear, very amazing to hear; that was great to hear. So, to answer you, I guess to answer all those questions in one go, yes. It's always been part of the way that I engage in dev rel. It's how I would always like to be engaged as a developer, coming from a developer background, so it's always been something that's been important to me. If I don't know the answer or I can't pull something apart using my developer powers and figure out why, where and when and how, then I'll just figure out a way to be able to find those answers that I need. 

‍

And for me, being able to help a dev in need like yourself has always been important, because that's the call of the job; that's why we do this job. It's always – there's always a community to engage with, to share what you know, to encourage and help future developers and current developers – well, all developers really. 

‍

So, to circle back, the answer to all of the above is yes. And so, being the core of Lumigo's developer advocacy program, this is totally important to us, because it's important to me. Plus, I wanted to find out an answer as well. Incidentally – and we're not going to name the third party, but if I could shout out to them, I would say, 'Thank you for fixing that particular thing, because I did raise it as an issue on your open-source library.' But also, one thing that I certainly made sure of was, I had a second set of -- I pulled everything apart to find that particular issue. 

‍

But then I got other people inside the company, some of our engineers, to validate what I'd found was correct. Because as from an engagement point of view, I didn't want to go back and say, 'No, it's not us. It's them,' because I didn't want to be that dev. So, I made sure first and then handled it as best I could. [0:06:08]

‍

Richard Rodger:  [0:06:09] This is a good example of one aspect of developer advocacy that doesn't get discussed too much, but it's not just building example code or speaking at conferences or doing community stuff. In this example, you actually rolled up your sleeves; got deep into the code, to resolve an issue with multiple parties. That's – and that landed on your plate; it's not like planned development. Does Lumigo create the space? It sounds like a really helpful environment. Do you have space and time to dive into those things? [0:06:43]

‍

Steve Coochin:  [0:06:46] I'm going to say no, but I made space and time. That's one of the things; Lumigo does definitely encourage it. In saying that, we'll – like any thriving startup, we're all busy, busy, busy, and lots on. But for that type of thing, it's the type of thing that I'll always make space where I can, particularly if it's something that I can look at directly. 

‍

And then engage with engineering, engage with product as needed, just to say, 'Hey, here's what I found. Here's how I did it.' I can help them; also do the groundwork. And then also for me, my learning as a dev and in dev advocacy, if it's a larger issue, then I can fundamentally understand it and help others with it once I understand it, if that makes sense. [0:07:37]

‍

Richard Rodger:  [0:07:38] Yeah. Tell me about the developer relations structure in Lumigo. Lumigo, developers are a very core constituency for you guys. How is developer relations run? What's the size of the team? Where does it fit into the leadership structure? How do you guys [inaudible, 0:07:56]

‍

Steve Coochin:  [0:07:59] Great question. We've got quite a few people working on the dev rel team. I'm lucky enough to be part of the fundamental core, as it were. And everything – it's a wide gambit of activities from a dev rel point of view, everything from helping create T-shirts, stickers, geeky fun things. 

‍

That's – one of my favorites is always coming up with fun and exciting new stickers. There's a new Kubernetes one about to come out for a couple of Kubernetes conferences we're doing soon. I don't want to give spoilers away, but the D&D is strong with this one. Anyway, and for those that are attending- [0:08:39]

‍

Richard Rodger:  [0:08:39] Good tie in. 

‍

Steve Coochin:   [0:08:42] Sorry, you go. 

‍

Richard Rodger:  [0:08:44] A good tie in, I said. 

‍

Steve Coochin:  [0:08:46] I wanted to mention it, because I did the artwork for it the other day and came up with some wordage for it. Because it was one of those things that just hit me and I was like, 'I really want to see a T-shirt with this on it.' So anyway, we're getting a T-shirt with that on, stitching. [0:09:03]

‍

Richard Rodger:  [0:09:03] I was listening to your other plans; you're an artist as well. You make me sick. [0:09:06]

‍

Steve Coochin:  [0:09:08] I dabble; I do. I'm not going to change my name to DesignerSteve, but yeah, I dabble. I also do video editing stuff as well, but that's a long thing. [0:09:16]

‍

Richard Rodger:  [0:09:17] Okay, so that's an interesting point, because developer advocates often have to do a whole bunch of content creation that includes video editing, slides and all that sort of stuff. Do you think that's an important side skill to develop, basic understanding of design? [0:09:35]

‍

Steve Coochin:  [0:09:38] Something I – so I have been an advocate/evangelist for nigh on 10 years now. And one of the things I've always enjoyed is – particular to this role is the wide gambit of hats that we wear as advocates. You touched on it at the start. Definitely on the content creation side, there's videos, writing blog posts, building demo apps. 

‍

And for me, all those three things are combined; it's like you build a demo app; you take it out of conference talks. You have some fun with it and make some videos about it; you might do a couple writeups on it. And then you can use it for workshops and whatever else. Being able to reuse content in multiple ways always supercool. 

‍

But then if you can do your own video editing and also do a lot of the bits in between, it speeds up the process a little bit. You have fun on the creative side of things, being able to build that stuff out. But the thing for me is always be learning, always be refining those skills, looking for new ways to adapt. 

‍

There's a whole suite of – some people might be scared at the moment, but there's a whole suite of AI tools that – almost by the hour they're coming out these days. I know Adobe Firefly came out with in-line edits literally yesterday, which was – has been crazy from the player. But bringing out that creative side to make those fun and engaging geeky experiences has always been something I've always been passionate about. Got to keep it fun. [0:11:14]

‍

Richard Rodger:  [0:11:16] Yeah, absolutely. It feels like things like ChatGPT and AI tools are more useful to developer advocates than most developers. So, what I found in some of the stuff that we do is, when you're building examples in languages that you might not be too familiar with it's super handy, or you have to generate Swagger docs or something. 

‍

But day to day coding on large code basis generally not that helpful, because you have to know the whole code base and you're just doing maintenance work. But would it be fair to say that the AI stuff has raised the bar on developer advocacy in terms of what people should be outputting? [0:11:55]

‍

Steve Coochin:  [0:11:57] That's a really interesting – that's a really good question. For me, it's another tool in the suite of tools. When I'm doing video editing for example, I use After Effects and Cantasia and whatever other video tools that I have at my disposal. And for me, that's just another tool in that suite. It's like I can generate an image or a placeholder image or some type of fun image that I'll then maybe have to take into Photoshop to edit or do some stuff to. And no doubt, there's a whole suite of video tools coming out that will do similar things. 

‍

And those tools get close but they don't often hit the mark. And the one thing in particular that I've noticed more recently is that we're setting -- we're using these tools to set the context more. We still set the story; this is just another method to add to that story. It's like, here's some nice images etc. Here's some nice graphics to go alongside that. So, in a way, it's lifted the bar a bit. [0:13:03]

‍

Steve Coochin:  [0:13:05] Yeah. I started playing with it myself and it's both wonderful and utterly frustrating at the same time. So, the other reason I am really – was really keen to get you on is, there's one topic that I'm super interested in discussion which is your experience your previous experiences. Because you have worked for different types of companies that have different consumer bases. 

‍

And specifically, Lumigo for instance right now has a mostly technical customer base, or at least you're interacting with the technical people and the customer. Whereas you previously worked for Zero, let's say, the accounting SaaS. And although there are developers interacting with Zero's APIs, Zero's customers are not technical. 

‍

And I'm sure that has an effect on the culture of the company and the way developer advocacy is done. So, I'm really interested to hear your perspectives, your personal experiences of working for companies that have those two different focuses, and maybe some of the other ones you work for as well. What do you think are the big differences? [0:14:15]

‍

Steve Coochin:  [0:14:16] Yeah, this is – I've found this most interesting. And one thing I meant to mention in one of the earlier questions was, for me this isn't a career. This stopped being a career for me pretty much as soon as I started doing it and started to work out that developer advocacy is one of those many-hat, multi-hatted roles where you're everything to everyone for every reason inside an organization. 

‍

And as such, one thing I've always found is, no-one ever knows where to – inside an org, no-one ever knows where to put dev rel, because it's not quite marketing. You're definitely not sales, because you can't – we're not that, no way we're that. You might support them, might do a couple of joint activities, but you're not sales. You're not really product and you're not really engineering side, but you fit into all those. 

‍

So, no-one's ever worked out where we go. Usually in most orgs, it ends up – it varies depending on what the flavor of the year is, But you end up in the marketing realm because the budgets are maybe a little bit better there, and it's a bit easier to tie your activities to that stuff. But you're still all the other things too, which is the way I've always done it. 

‍

When I first started doing it with – I was developer advocate with PayPal and Braintree for two years, which was my first dev rel gig. And the way that they trained me to do it was, you're a funded startup inside the company, so if you don't know it and there's no-one to bring in to help with the project then you learn it and you're it. Which is what I started to do the video editing and all the many other things. 

‍

The difference in the company's approach, each company's approach that I've been through is interesting. Because as you are aligned to those different areas, through marketing or internet engineering or whatever, the focus of your activities needs to change and this is where the multi-hatted comes into play, the multi-hatted approach. 

‍

Because you're still going to do the full suite of thing; it's just to align with that particular organ, grow as a team and get the funding and stuff you need, the resources you need. You have to align to those activities but at the same time walk that line between engaging with doing the regular dev rel activities, engaging with community and doing the conference stuff and whatever else. So, it's always a lot of juggling – the outcome of that. 

‍

But it is interesting to see the different approaches, particularly strategically, of who's important to that particular organization. So, Zero for example, they've got an amazing ecosystem. Like you said, the APIs, they've got the API platform that people can build their applications into. The end users though are not technical and because of the work and the robustness of their API, they don't need to. 

‍

And that's where the advocacy team would have – when I was there anyway; it was a few years ago now. But that's where I came in, because I can help work with those developers to make sure that they've got that really nice experience. So that in the end, the non-technical end users don't have to worry too much about the technical side of things, because we've been there to guide that whole experience. [0:17:46]

‍

Richard Rodger:  [0:17:49[ And the role of external developers using the APIs and the SDKs in the different companies, is it seen differently? By that I mean is – often developers interacting with the system is the first step in making a sale, because those developers then influence budgetary decision makers to use or not use the system. 

‍

Is that different? Is – even for something like Zero, surely that must be part of it. Because if somebody asks me about accounting systems and then I knew there was going to be an integration, I'd care very much whether the API, the support structures are good or not. That will influence me to make a decision about which accounting SaaS I want to use. Is there an appreciation of that? Is it different? [0:18:39]

‍

Steve Coochin:  [0:18:41] There is, and yes, it is different. So, Zero, for example, amazing product team and engineering team that had very good vision and very good structure about how the APIs needed to work, and the different offerings, the different product suites etc. When you start to get into bigger organizations – so when I was at a – at Telstar for example, the telecommunications company, there was an API team that had multiple product teams feeding APIs into it. 

‍

So, you had a multiple of products, API products inside the API that wasn't directly maintained or controlled by the API team. They were just the public end point, if you will, for all the different product suites. Which, as you can imagine in large orgs can get rather tricky to navigate, particularly – so what I did was – one of the things I always do as a developer, as a hands-on developer advocate – is to be able to pick up any API products for example and get hands on with them before they go out the door. 

‍

Because I have to be not only familiar with those particular product and all that particular product group or end product. But I am the first usability test; if it passes me, then it's good to go. And so, being able to take an API spec for an entire product suite and push out all the SDKs for example was something I just did because it helped make developers' lives easier. And at the same time, it also showed the business that – the wider business that this way to engage with developers helps them be able to build out better experiences with the product. 

‍

It's important to note here that – I want to give a shout out to an amazing open-source community that I use to do it, that particular task, which is Open API Generator. Anyone looking to get involved in open source, I highly recommend them. It lets you take an open API spec or Swagger 2 spec and then generate multiple language SDKs from literally a command line where you can set it up inside containers etc. 

‍

And it very quickly just improved that particular element of the program; worked amazingly well. I started with eight SDKs on one API product and when I left – it's still on the GitHub too. There was 40 – over 40 of them that I was pushing out SDKs for – it was five or six API products from memory. [0:21:19]

‍

Richard Rodger:  [0:21:20] And these were all generated from a spec. [0:21:23]

‍

Steve Coochin:  [0:21:24] Yeah, multiple specs. And so, what I do is, when new specs came in or new versions of the specs came in, I would have to generate all the SDKs and then test everything to make sure they worked. Which, when there was a handful of them, it was really easy. When we ended up with 40; it was a lot of work. 

‍

I broke them one time by not testing them properly, I gotta say. And that was interesting, because we had a load of people of people emailing in saying, 'It's broken. Can you please fix it?' and pointing out and raising issues and stuff, which also let us know that people were using them; that was great. [0:21:56] 

‍

Richard Rodger:  [0:21:58] To know you have – no news sometimes is good news. Sometimes it just means, 'You got no users.' [0:22:03]

‍

Steve Coochin:  [0:22:05] Yeah, exactly. We were wondering there for a while, because it's – you can measure the API calls but you can't measure the SDK usability easily. It was – that answered the question, because there were people using it. [0:22:20]

‍

Richard Rodger:  [0:22:21] It looks fabulous. Let's talk about this – 40 SDKs, multiple teams feeding in their own APIs to a top-level API layer. Were you using some sort of management system? Was this all going through Amazon API Gateway or were you using Kong or something like that? How do you manage an API of that size? Do you have to use systems software to run it? [0:22:47]

‍

Steve Coochin:  [0:22:49] Back then they were – the team was using – what was it? Apogee, they were using Apogee. That's right. I don't know what they use now; that was 2018. I'm not sure what they're using now, but they were using Apogee at the time. [0:23:06]

‍

Richard Rodger:  [0:23:07] What was that experience like? What did Apogee do for you Did you use it? [0:23:12]

‍

Steve Coochin:  [0:23:14] I wasn't directly using it hands-on; I was busy out doing the dev rel thing, so I was more than happy to leave the team with that one. But obviously, I worked pretty close with them for upcoming releases and stuff. One thing I did that was – I'm going to say challenging, but that makes it half the fun, right, but – was when new specs would come down, obviously as I pushed out SDKs and used the APIs and tested everything through that – those activities. 

‍

One thing I did, then I had to work with a variety of different product owners on was changes to the spec. Because there'd be things that I need, either need to change to support the SDK or that were – should be there. So, I was like, 'No, here's some suggested changes and you can send it back.' 

‍

And then they would test it and send it back. And there'd be a little bit of backwards and forwards, but they were generally really open to changes, particularly if it was – there were flow and downstream effects in the workflow that could help make things smoother and more streamlined. [0:24:20]

‍

Richard Rodger:  [0:24:23] Moving onto a slightly different topic, one thing I've noticed, having interviewed quite a few people on this podcast is, we seem to have – I'd be curious if you've seen this as well. We seem to have two generations now of developer advocates. When I started doing it 10-plus years ago by accident it wasn't – it was – it wasn't even really a recognized thing as such. 

‍

You might have had evangelists and ambassadors, but that was mostly Microsoft and big companies. It wasn't a huge thing that smaller companies did. And a lot of people of that generation – and I believe yourself and myself included sort of fell into it. But there seems to be a newer generation now, a second generation, where it's a defined career choice, and there's an awful lot of material and guides and role models and all that sort of stuff. 

‍

Do you think if you were entering – if you were starting work now, you would choose it as a career straight off? And what's – has it been – has the prior experience of not being a developer advocate and having worked in the trenches – is that necessary? [0:25:36]

‍

Steve Coochin:  [0:25:39] This is a good question, because yes, this is something I have also noticed over the years. I feel so old. [0:25:43]

‍

Richard Rodger:  [0:25:44] I know. 

‍

Steve Coochin:  [0:25:45] I'm inexperienced; that's the – let's go with, I feel so experienced. This is something I've noticed as well. And it's interesting because going back, 2014-ish, it seemed like most people ended up in it by accident, and I was – by all means, I was totally one of those. It was literally someone going, 'You already do stuff with us as an ambassador. Why don't you come and do dev rel, be an evangelist?' It's like, 'Cool, that sounds fun.'

‍

You know the most daunting thing for me, going from sales before becoming – going down the advocacy path, I was a full-time tech lead for an agency in Sydney. And the hardest thing – not even hardest. The most adaptive part of making that transition was the whole, we don't expect you to be anywhere, but you be where you need to be, approach to the role. 

‍

Because my first week, I went to the office day in, day out, like I normally would. And then after the first week, my manager, who wasn't even in the same hemisphere was like, 'You don't have to go to the office all the time, and by the way, you've got all this budget. Go to a conference and sponsor some stuff.' And I was like, okay. And from there on in it was – it's literally been an amazingly wild, crazy ride.  

‍

For me though, and something I figured out early on is, this isn't a career more. It was really early in my dev rel origin story, where I worked out that this isn't a career; this is what I do; this is who I am. And stepped away from the traditional career path a little bit. But it has been interesting seeing the five, 4-5 years, particularly with the Web 3 emergence is, you now see people wanting to do it with a career. 

‍

Whether or not – so, I've been a bit conflicted thinking about whether being a dev, being a full-time dev in the seat helped or not. And I've seen some amazing dev rel folks come through, emergent in the dev rel world that haven't had that traditional dev background, but still being really good at what they do, and I really admire them as industry peers. 

‍

But then coming from having that experience myself has been really handy, because it helps me sit in the same seat, if that makes sense, as a dev. I've walked in their shoes and I still do it constantly, because I run my own infrastructure and stuff. So, having that experience is important, but I don't think it's necessary. [0:28:32]

‍

Richard Rodger:  [0:28:33] Yeah, and one of the downsides to our type of journey is the lack of emphasis in the early years on community and community engagement. If I compare myself to the second generation – to use a cringey term, they're digital natives, but they get community in a way that I still struggle with. [0:28:58]

‍

Steve Coochin:  [0:29:02] Yeah, and one thing I really liked – I – 2015 – I've done a lot of travelling and been fortunate enough to meet amazing communities all over the world through conferences and hackathons and meetups etc. One thing I always love is seeing the communities come together in those different locations and seeing – RubyKaigi for example, which is the Ruby conference in Japan – actually, it just happened recently, about two weeks ago. 

‍

But seeing that community come together even after the event and Matt, the creative of Ruby, will turn up at one of the after dinners, just random gathering of people. And they'll all – everyone will start talking code or whatever else they want to talk about. It's a really informal exchange of ideas and geeking it up. 

‍

And for me as a dev, that's always been amazing to see, and it's something I've seen all over the world from Aukland to places in North America who – I don't know why I couldn't come up with any names. Florida, let's go with Florida. But yeah, no matter where it is, you always see these communities; everyone's able to geek out and what they know and learn what they can. [0:30:22]

‍

Richard Rodger:  [0:30:24] It is something that's a little bit special about our industry, and I speak to friends in different industries and there doesn't seem to be quite the same community vibe. I don't know what it is about developers. Maybe we're just so far down the nerd spectrum, we can spend hours talking about code. Let's finish with one final question, which is, are you travelling the same now as you did before COVID or has the travel – the level of travel changed permanently? [0:30:54]

‍

Steve Coochin:  [0:30:57] That is a really good question. I am not travelling. I've done one event; I've done one IRL event this year, but otherwise, all set up for streaming and video recording and blogging now. The thing that everyone realized with the onset of – the changing times of the pandemic – my last international flight was February of 2020, where I got to work with the United Nations when I was with IBM, on the Call for Code program. Which I think has kicked off again, so if anyone's interested in that, totally check it out. 

‍

But since then, everything went online, and I know some events – everything's opened up again obviously. And some events have started to go IRL again. But not travelling as much these days, which I'm okay with. So, 2015, I did the bulk of my travel; I travelled up to 2020 when the world changed a little bit. But my record – and I'm really keen not to beat it – was 2015. I did 310 days on the road, which hurts. I got a bunch of frequent flyer points, but didn't want to fly anywhere. [0:32:15]

‍

Richard Rodger:  [0:32:17] That's the way it goes. And you have kept every single conference badge, haven't you? [0:32:22]

‍

Steve Coochin:  [0:32:23] I have; I have. And each one, I still look at now and I still have fond memories of, we went and did this; we – I spoke about that. But I actually did my – I don't know what my current conference talk count is, but 2016, I did my 100th conference talk in New Zealand at API Days New Zealand, when I was with – funnily enough when I was with Zero. But I haven't kept track beyond hitting 100. [0:32:51]

‍

Richard Rodger:  [0:32:54] Wow, that's got to be a pretty big spreadsheet of all your talks that you've ever given. Amazing. [0:32:59]

‍

Steve Coochin:  [0:33:02] No. Actually, I have a question for you. This is my favorite question to ask, just as we wrap up. This is my favorite question I always ask, just because - from a geek – developer geek, and I just always love hearing the answer is – what was your first computer? [0:33:21]

‍

Richard Rodger:  [0:33:24] A Spectrum ZX 48K, and it is literally about three feet away from me as we speak. [0:33:35] 

‍

Steve Coochin:  [0:33:36] You've still got it! And it still works? [0:33:42] 

‍

Richard Rodger:  [0:33:43] I haven't plugged int into anything in a while, because it has – you have to put it into an old TV that can take – or axial cables. But it should still work. Why wouldn't it? Volt DC. [0:33:57]

‍

Steve Coochin:  [0:33:57] That's so cool. [0:33:58]

‍

Richard Rodger:  [0:33:58] You got it. 

‍

Steve Coochin:  [0:33:59] I wish I'd kept mine now. 

‍

Richard Rodger:  [0:34:01] I – and the interesting thing about that is, the person who taught me – took me to the next level – so I was just doing rinky dinky stuff with BASIC and I hadn't developed any proper mental models. And I really wanted to do – to animate sprites, to make little games, and I couldn't figure out how to do it. Now I was eight years old or something; I couldn't figure out how to do it. But my aunt was a coder, COBOL mainframes. And she showed me how to do it. [0:34:35]

‍

Steve Coochin:  [0:34:38] That's so cool. Incidentally, my first computer was an Atari 800 Excel, where I'd learned – I also learned BASIC on as well, so good times. [0:34:47]

‍

Richard Rodger:  [0:34:48] Yeah. Mine had squishy keys though, with all the squishy keys. [0:34:53]

‍

Steve Coochin:  [0:34:53] The little bubble keyboard, the bubble keys? [0:34:58]

‍

Richard Rodger:  [0:34:58] Yes. And actually, I remember the way it worked was, you had all these key cords. So, instead of typing in the words, the basic keywords, you could have these shortcuts, where you would – you press the – I don't know; it was a control key or something. And you wouldn't have to type the word Print. [0:35:13]

‍

Steve Coochin:  [0:35:17] That's more or less-

‍

Richard Rodger:  [0:35:18] I'm an EMAX user; now I know; I've seen the light. I was – I have a little keycording thing hotwired into my brain from being a kid. That explains it. [0:35:30]

‍

Steve Coochin:  [0:35:31] You know something I realized recently? I went – tried to go back and do basic things. And one thing I learned from that was – in hindsight is, there's no libraries. You have to build everything yourself and then call it all. Whereas now we have these libraries that we can pull into anything we need; it's so much easier. Open source for the win. [0:35:52]

‍

Richard Rodger:  [0:35:54] Yes, yeah, and that's the fundamental difference; that is a really big way that things have changed. DeveloperSteve, thank you so much. This has been fascinating and really wonderful. Thank you for joining us all the way on the other side of the planet; been great to have you. [0:36:12]

‍

Steve Coochin:  [0:36:13] Amazing, thank you for having me. [0:36:14]

‍

Richard Rodger:  [0:36:15] Awesome. Take care. Bye-bye. [0:36:16]

‍

Endnote

‍

Richard Rodger:  [0:36:17] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:36:44]

‍