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.
We have a special one today. Martin Woodward is the developer who registered Microsoft's first GitHub account. And he's been helping first Microsoft and then GitHub build, sustain and support their respective open-source communities. Of course, GitHub, where he now works, is the great-grandaddy of developer relations, because that was their business.
We talk about practical things, like what recording systems to use for preparing your content. We talk about the impact of AI, especially for coding, and how it will improve tooling rather than take over the world. And we talk about the impact you can have in developer relations, and how satisfying it can be to provide a ladder for those following you to climb in their careers. I found Martin, despite his high position, to be remarkably humble and very approachable. He'll probably regret me saying this, but if you see him at a conference, go up and say hi. All righty, let's chat. [0:01:28]
Richard Rodger: [0:01:29] Martin, it's great to have you here on the Fireside with Voxgig podcast. How are you doing? [0:01:36]
Martin Woodward: [0:01:37] Good. I'm literally just in the door; I've just done a rather, epic tour, it feels like nowadays. I was in Brussels for FOSDEM, went to Amsterdam, then over to Brussels, and then the train over to London for a different conference, for the State of Open conference, and then did that. And then flew over tonight, back to my home just outside of sunny Belfast, in a field in the middle of rural Northern Ireland, so yeah, that's where I am. [0:02:05]
Richard Rodger: [0:02:05] Wonderful. Take it that all the rain calmed down a little bit. [0:02:08]
Martin Woodward: [0:02:08] It's actually sunny outside at the time of recording; it won't be by the time of listening. [0:02:12]
Richard Rodger: [0:02:14] Well, I'm at the other end, the other end of the country, and it's sunny here as well. [0:02:17]
Martin Woodward: [0:02:20] That's great.
Richard Rodger: [0:02:20] This is the world of developer relations, a lot of conferences. What's your average conferences per week? [0:02:25]
Martin Woodward: [0:02:27] I don't do that many anymore in person, so that last week was fairly unusual. Couple a week in terms of what the advocates would do, and mixing things up. But we – on our team, we try and limit the advocates to one or two a month ideally, in person, so that they're not spending all the time on the road. So, they're able to do time with content creation, time with video and time talking to the product managers in the business.
Because the whole point of dev rel isn't about talking; that's marketing. And then dev rel is about creating connections between the developers that use the products and then the people that make the products better. And if we're not doing that, if we're not spending as equal time on that side, on building the channels, it's no good how big our networks are and how good our networks are if we can't connect them back to make the product better. So, we try and keep the focus and we don't want to burn people out as well; it's very hard work. [0:03:45]
Richard Rodger: [0:03:46] Do you guys do much – many virtual meetings? [0:03:48]
Martin Woodward: [0:03:49] Yes. We slot those in a lot. Whenever people need them, we can slot a virtual one in. Again, that's one of the interesting things as well. I'm a great believer in growing advocates as well as hiring people. And so – as you're trying to – the advocates we've been growing over the last couple of years, they haven't done in person before.
It's quite interesting. You've got an experienced advocate who's amazing, and then you realize, oh, right, this is – you put them on the keynote stage in front of thousands of people, and then you're – No this is your first in-person conference. Sorry about that. Let me show you how you deal with stage fright and let me"- [0:04:34]
Richard Rodger: [Inaudible] Time: 0:04:34. You're meant to start with meetups of 10 people. [0:04:37]
Martin Woodward: [0:04:37] Exactly, yeah, but also, it's – so, there's the basics of that sort of thing, but also the understanding that when you are doing an in-person conference, you need to be there. The whole point is being there and making the connections and networking and getting to know people and understanding people's pain points.
And if you've just done virtuals, you're just in and out quite often; you can back to back them almost. But with an in-person conference, you need to make sure you block a time out in your diary to actually be there and not have to run to a place to go record something or whatever. So, it's interesting; it's interesting to talk to people who've learned to dev rel during a pandemic, helping them adjust to how it used to be a little bit more. [0:05:27]
Richard Rodger: [0:05:29] Yeah, and it is going back that way. I want to talk about something before we get into the meat of the discussion. We are using something called Riverside.fm to record this, on your recommendation; it's pretty cool. It's a little bit different from my usual tooling. This is – the tooling around screen recording, doing demos, doing virtual meetups, that type of stuff, what are your experiences with that? How did you end up with Riverside? What have you- [0:06:02]
Martin Woodward: [0:06:03] We use a bunch of tools. Riverside's great. Not sponsored by Riverside or whatever. [0:06:10]
Richard Rodger: [The processes?] 0:06:10.
Martin Woodward: [0:06:11] Yeah, exactly.
Richard Rodger: [Inaudible?] 0:06:12 this year.
Martin Woodward: [0:06:13] Yeah, exactly. But – so, they're great. It's from a – it's a personal point of view anyway. It's a great product. They – it's used by lots of – you see it used a lot in broadcast TV and things like that now. Because it can record video and audio; give you separate channels, and then if you're doing a screenshare as well, it'll give you that as a separate channel. We're recording this as a double header. It's being recorded locally on both sides and- [0:06:45]
Richard Rodger: [0:06:44] Yeah. Zencastr does that as well, right? [0:06:46]
Martin Woodward: [0:06:46] Yeah, and then uploads it up. So, that's – but Riverside is – if you've done podcasts, then Zencastr's an amazing product. I should – I'm an investor in Zencastr on a personal level, so again, disclosure. But Zencastr is an amazing product as well for the audio side.
And Riverside is the audio/video version of Zencastr, if you like. Zencastr again records a double header in a browser and then allows you to edit them together as you get there. So, both great tools. As I say, the Riverside allows you to do video, but you can do audio too, which is cool, and screensharing.
And then the other tool we use a lot is probably StreamYard. StreamYard allows you to do live switching in the browser and then send it to Twitch; send it to YouTube; send it to LinkedIn. And you can figure – or any random RMSTP – I think that's the protocol – end points, video streaming end point. It allows somebody without a ton of video training, without a ton of video knowledge, to be able to switch and control a stream, without having to have a full OBS setup and all that stuff. [0:08:07]
Richard Rodger: [0:08:08] Yeah. That's the – and OBS is the full-on hardcore. [0:08:11]
Martin Woodward: [0:08:11] Yeah. Plus quality can be variable depending on your connection bandwidth. Whereas if you're doing it in a browser, it's the – you don't have to worry about that so much, because you're acting as a controller for the switcher, rather than being together where all the streams are and then coming back out again.
So, they're also these – and then putting these – because that's great for capturing this for the raw footage. And I know you keep yours as nice, informal chats and so there's minimal editing. But there's times where you need to take a 45-minute rambling conversation with some dude from Northern Ireland and turn it into a story that you've got four minutes to tell maybe, or two minutes to tell.
And so, to do that kind of editing, to get to what a video editor will call a papercut, I use -- quite often use a tool called Descript. There's some missing vowels in there somewhere. But it's – that's an amazing product that uses AI. So, it does audio to text; gives you a transcript of your video, and then you edit by moving the text around.
So, you cut and copy blocks of text; moves them where you need them. And it creates you a video; it edits the video. And it even does the dissolve very quickly; it'll even duct the audio properly. It's amazing; it does a really good papercut. It's not as good as what a professional editor can do, but it's great for quick, boom-boom-boom content that you want to get out the door. [0:09:51]
Richard Rodger: [0:09:52] Which you need as a dev rel, right? [0:09:53]
Martin Woodward: [0:09:53] Which you need as a dev rel. But then if you're also using it for doing the fancy – when you see our keynote videos or when you see customer case study videos and those sorts of things, where you pay a professional editor to edit them, you can export form Descript an Adobe Premiere Timeline. Send that to your video editor and they can take the raw footage in the timeline and your papercut.
And they've got the cut that they then can use and splice in some stock footage, splicing some B roll. And before you know it you've got movie grade stuff, and you're able to take a 45-minute conversation down to 2-3 minutes in a few hours rather than a few days, which is what it can take normally. It takes a long time to shrink something down. [0:10:40]
Richard Rodger: [0:10:41] I know. That – most people don't realize how expensive professional video editing is, if you get quoted. It's not cheap. It is a specific – okay, marvelous; we'll put in some links to those. [0:10:56]
Martin Woodward: [0:10:57] There we go.
Richard Rodger: [0:10:58] That's-
Martin Woodward: [0:10:58] I should get some commission in all that. It's just – we've used every tool out there. We use – because it's all about enabling content creation, not just for ourselves. Because as a dev advocacy team, we've all have been on Adobe Premiere training; we can do that sort of thing because we've got time to.
But if you're trying to capture content with a PM on the team or with an engineer, you don't want them faffing on, installing video capture stuff. You just want to give them the browser link and get the story out of them, and then be able to tell. Or if you're getting – talking to a customer, and again, you want to turn that into a story, you want easy for them to use. And then StreamYard's great because even a non-video professional can use it to get a decent stream out. So, it's good for user groups and remote user groups, that sort of thing. [0:11:45]
Richard Rodger: [0:11:46] Well, it's particularly useful for startups that are trying to do dev rel, because they can't pay for Adobe training, so- [0:11:53]
Martin Woodward: [0:11:54] Yeah, and it's tools that we can – which are accessible to all of us. These are the tools that – like Riverside or whatever. I'm pretty sure I've noted BBC and major newscasting organizations. I don't know that they use it, but I'm pretty sure that they do, judging what I've seen- [0:12:12]
Richard Rodger: [0:12:12] Your headline is definitely – it looks like- [0:12:14]
Martin Woodward: [0:12:14] Yeah, you recognize it. Yeah, you – once you've been on it, you think, I know how they've created that. [0:12:19]
Richard Rodger: [0:12:19] Yeah, I know. Let's change gears. So, that was all super useful; put in the links. You have a long and distinguished career of helping developers. Let's talk about the Dotnet Foundation, [inaudible] Time: 0:12:35 and the history of that, and making that something that was more community oriented, how that came about and the learnings from that. [0:12:46]
Martin Woodward: [0:12:47] Yeah. The – because this is an audio podcast, people can't see that I do have very little hair; I am old, and so, yeah, been around a while. I was a dev; I was an engineer in dev tools, so I've been doing dev tools since – I had a real job until about 2004 in banks and insurance companies, that sort of thing, and then in consultancy. And then did a startup in 2004, which we sold to Microsoft.
So, that was a developer tool startup, but it was all open source based, and a bunch of stuff there. And then we sold it to Microsoft in 2009, November 2009, and it was just four of us – five of us, sorry. There were more lawyers that would turn up -- there were more people actually that would turn up to take notes for the lawyers than we had people in our entire company.
So, we did that, and then – but because of that experience, I had to learn Microsoft's processes for dealing with open source, which at the time in 2009 were pretty – it was how do we keep that out of our organization was the process and that's how it was structured. But they weren't playing on a level playing field, because everybody, especially in the cloud services side,, they were – everybody that they were working with were building on top of open source and were collaborating with open source communities. And so, it was helping them understand that.
And then by about 2014, I'd been doing a lot of stuff helping the organize - as part of my – so I had my day job, which was building products and dev tools and shipping those to customers, as a PM, engineer and then a PM. And then my side product was helping Microsoft open source and change how it worked with open source, and rolling out training, rolling out tooling across the whole company to do that. [0:14:41]
Richard Rodger: [0:14:42] You've been slightly successful at that, I think. [0:14:43]
Martin Woodward: [0:14:44] It wasn't just me. I was part of it, but there was a lot of us on this mission, and so, we all found each other and did different bits. But things like, I created Microsoft's GitHub account; I looked – I was looking after CodePlex at the time, which was Microsoft's host, open-source hosting solution.
And I'm afraid to say, I'm the person responsible for explaining why this probably wasn't such a good thing for the Microsoft community to be in its own silo, and not to be exposing itself to the whole world of open source. And why it would be better for the whole community and Microsoft for the community to be part of the global community, which at that time was now clearly on GitHub. So, I was responsible for gracefully shutting CodePlex down and moving everybody over to GitHub for open source. [0:15:37]
Richard Rodger: [0:15:37] Was SourceForge still running at that time? [0:15:39]
Martin Woodward: [0:15:39] SourceForge is still running today. [0:15:40]
Richard Rodger: [0:15:41] Yeah, I -yes, in some… well, a virtual source. [0:15:43]
Martin Woodward: [0:15:43] It is. If you want malware or whatever, but you know what I mean? It's great; it's still running today. We've still got – I've still got open-source projects on SourceForge. [0:15:51]
Richard Rodger: [0:15:54] I was really into that years and years ago. Do you have any insights into why – what happened? Obviously, it wasn't well tended and it wasn't that community focused, sure, on the surface. GitHub seemed to come from nowhere. Was it driven just by Git being really interesting? What- [inaudible, 0:16:17]
Martin Woodward: [0:16:19] GitHub was driven – it was a very deliberate thing, but GitHub was driven by how hard Git was to host in some ways. Git as its – on its own, there wasn't a very easy way of sharing Git repositories, because Git – the source control system. So, GitHub did two things. One, they made it easier to share a Git repository with your friends.
But back then, it wasn't clear that Git was going to win either as the source control system. You got to remember, back in the 2000s, source control system was incredibly fragmented. You got SVNCVS, PVCS. But when you get that survey, there were hundreds of source control systems. [0:17:05]
Richard Rodger: [0:17:06] Mercurial, all that stuff. [0:17:06]
Martin Woodward: [0:17:06] Yeah, and people still use them all today; they're all still going today. There's just 90-odd percent of developers use Git now, but that wasn't the case; it was super fragmented. So, GitHub provided an easy place for people to host Git repositories. Then what it did was, it invented the pool request.
So, that's the ability to be able to say: "Hey, I want this Git change. You, person who's maintaining that open-source library, I'm going to take a fork of your Git project very easily, very quickly. I'm going to make a change; I'm going to push my change public, so that everybody can see it in the world still."
So, you're now not reliant on the person who's maintaining the repository to make a change, you can just fork it; go make a change. And then send a pool request to that upstream project to say, "It would be cool if you accepted this change." But importantly, from a developer point of view, you're not introducing friction; you're removing friction. You're unblocking; you're allowing them to work and make the changes, but also, you're allowing them to connect it back into their upstream project. [And push this button, 0:18:16?]
Richard Rodger: [0:18:16] Is that [inaudible] 0:18:17 – is that the killer feature? That- [0:18:19]
Martin Woodward: [0:18:20] Is what the killer feature? [0:18:20.8]
Richard Rodger: [0:18:21] Is that the killer feature? [0:18:21]
Martin Woodward: [0:18:22] Early on, it was forking and pool requests. And then what it was – we talk about dev rel and the fact I do dev rel at GitHub. In the early days, everybody did dev rel at GitHub. Everybody in the company did dev rel; they – because they all came from the community and they still do today. So, they all work with open-source projects; they all work – they all hang out in user groups.
And so, it's not like – in the early days, there wasn't a need for a dedicated dev rel team, because literally everybody in the company was doing it, whether they knew it or not. And it's only as the company got bigger that they needed to create a dev rel team, to make sure that the whole organization was doing it still. [0:19:06]
Richard Rodger: [0:19:07] GitHub was unusual. I don't think they had early funding; they got really big. [0:19:10]
Martin Woodward: [0:19:11] Yes, they bootstrapped for – until they got that Andreson funding. I got – I started – I didn't come over to GitHub until 2020. But I was working with GitHub very closely, especially with the Microsoft stuff, from 2012-ish. And that was just after – I remember my first HQ was – in San Francisco was when – just after the Andreson funding. And their first round of Andreson funding had arrived; up until that point; they were mostly bootstrapped. Because again, very developer focused, very in the community, very about serving those developers. And so, that's – it grew naturally up until that point. [0:19:11]
Richard Rodger: [Inaudible, 0:19:56] I'm just trying to think of the timeline. I would have started using GitHub in anger, maybe 2011, 2012. [0:20:04]
Martin Woodward: [0:20:04] Yeah. Still pretty early. GitHub didn't come around until – the first commit on the GitHub cobase was October 17th 2008. It didn't launch – if that's right? That's it. No, 25. No, it would have been 2017, October 2017. And it would be April 2018 that they – sorry, April 2008 when they actually launched publicly. And then this – it's been pretty fast growth since then.
Richard Rodger: [0:21:06] The app goes down and the software development stops. [0:21:09]
Martin Woodward: [0:21:12] It does and it doesn't; it's Git, so people can run locally, but yeah. It's definitely- [0:21:16]
Richard Rodger: [0:21:18] It doesn't [inaudible, 0:21:18] anymore though, right? Microsoft must be… [0:21:20]
Martin Woodward: [0:21:21] What's that, sorry?
Richard Rodger: [0:21:22] It doesn't go down as much anymore; Microsoft must have thrown in a few extra- [0:21:25]
Martin Woodward: [0:21:25] It goes down more often than we would like, but I'm glad you think it doesn't; let's put it that way. [0:21:30]
Richard Rodger: [0:21:32] As a daily user; I have noticed. [0:21:32]
Martin Woodward: [0:21:34] It's different – it's rare that the whole thing goes down; let's put it that way. But different parts do, because it's a distributed cloud service, and so you're always dealing with change; you're always dealing with issues and things. And DNS is always a problem, especially a global distributed service where you get ISPs that decide that they don't like a single product on GitHub so they take the whole side down and things like that.
It's fun; it's keeping any large cloud service up at this scale. GitHub is amazing to work for because you get to have a lot of impact. You get – small things you do can make huge benefits to people's lives. But it's also a completely scary place to work at, because small mistakes you make can have huge impacts on people's lives.
And so, it's dealing with the scale of it can be intimidating at times, but dealing with the level of impact you can have is incredibly fun. You can do so much good for the world; you can help new developers get into tech. You can put down those ladders and bring people into new careers. You can help the people who've got established careers get even better. The impact you can have in terms of productivity as well is amazing, so it's great. [0:22:50]
Richard Rodger: [0:22:51] It's huge; it's huge. The thing that would scare me most, if I was working as a developer in GitHub, is the permission system. [0:22:58]
Martin Woodward: [0:23:00] Okay. In what way? [0:23:00]
Richard Rodger: [0:23:01] Get that wrong; you're exposing private source code to the wrong person. That would keep me up at night. [0:23:08]
Martin Woodward: [0:23:12] There is lots of – yes. But if you're going to operate any system at scale, you want to make sure you put the appropriate safeguards in to allow your dev team to work quickly and within the safety rails and not do catastrophic things like that. You need to make it be a fundamental failure of a system that anything like that could happen.
Equally, even taking down a service or taking down a little bit of a service. It's not that developer's fault that they did that, unless they were extremely – went out of their way to log into – get at production access, log through several junk boxes and take things down. You should have the appropriate safeguards in the system to be able to slow those down, which is why constantly as a dev ops rights focused organization, you are trying to improve. And any issue that happens, you're trying to learn, how can we make it? Because we're all fallible humans; we all make mistakes. So, how can we make it so that those safeguards are in place.
And so, it's trying to create some sort of – and this is what's come back up as well. It's a blameless culture, in terms of, it's very much – that's interesting that somebody was able to do that. How can we make sure somebody wasn't able to do that?" Because it might have been a junior developer that did it this time, but it could just as well be some fancy VP, especially the VP of dev rel, who does have the ability to make changes on GitHub.com and has made two. It's – you want to put the safeguards in place to prevent everybody from making mistakes.
Richard Rodger: [0:24:53] I always tell my junior devs – a lot of them are a bit burnt from previous work, and they're a bit scared of making mistakes. I always tell them, "Don't worry. The scale of mistake you can make compared to me – it's fine. I make the really big ones." I think that's an interesting observation. Effective dev organizations have that. It's like airline safety, where it's – never mind the people; we need to understand the system failure. But I've experienced and hired people from so many – I don't know if I'd use the word toxic, but regressive organizations that don't embrace the idea that it's the system that you need to fix. [0:25:39]
Martin Woodward: [0:25:40] Yes. This – it's funny; I get asked to come in and talk about – go in and talk to customers about the future of development or the future of dev ops, or one of those types of things quite a lot of the time. Because you're GitHub; you must know what's going on. And we're all just making it up as we go along, but they think for some reason, you've got particular insights.
And the thing I always talk about is the fact that the future of development, the future of dv ops, is already here. It's just not evenly distributed yet, like William Gibson says. It's – the level of maturity within the same company on some of these processes and practices and creating a culture of psychological safety and how to create engineering as a creative act and things like that. And the reward structures are appropriate, all that stuff.
Even within the same company, there's a huge degree of variability, so across the whole business, across the whole globe, there's massive degrees of variability and levels of maturity. And it's very easy to assume – a) to assume that people that are up there in the same level in everything and everything we do is terrible. But also, you forget how far you've come.
And so, it's – to me, it's all about what little things can you do to make your organization just a little bit better today. What can you do tomorrow that will make the development practices inside your organization just a bit better. And do that every day; do that every week, and before you know it, you don't – you can't not ship features. Ship features, but how do you make it just a bit easier to ship features every day. And those incremental changes just add up over a decade, and you get organizations transform. It just takes a lot longer than you think it's going to. [0:27:36]
Richard Rodger: [0:27:37] Was that in the DNA of GitHub? Because I've seen organizations where it's the opposite. Every year, it gets harder to ship code. That seems to be the norm, right? [0:27:47]
Martin Woodward: [0:27:48] The DNA of GitHub is community. So, if you cut somebody open at GitHub, they would bleed open source; they would bleed the community, and the developer community. The culture of – there's – the culture of GitHub has had changes over the years as it's grown. And every organization, as it gets in order of magnitude bigger, changes in terms of how it does things. But yes, nowadays it is very much a culture of incremental improvements, not relying on hero engineers. And a mature – a more nature, bigger organization than it was. But- [0:28:28]
Richard Rodger: [0:28:29] I'm sure there were heroes back in the day. [0:28:29]
Martin Woodward: [0:28:30] There still are heroes today, but hopefully, we've got support structures around people so those heroes don't burn out. But making sure people can be career, making sure people are community focused; that's what – definitely what the DNA is of GitHub [0:28:46].
Richard Rodger: [0:28:47] I have a personal question for you. This is something I'm struggling with and trying to understand where it fits in - as a developer first and foremost – is Copilot and ChatGPT and large language models and what that means for the future of development. It's a big, open-ended question. My observation of the code that these things produce is, they look like answers, sample answers to undergraduate programming assignments.
Whereas day-to-day programming involves things like spending half a day trying to configure AWS API gateway to make sure that CORS works. It doesn't help if you can generate 20 lines of code. That said, recently I was writing Swagger documentation and ChatGPT was super helpful generating examples, so, I didn't have to spend longer reading the Swagger spec. So, that was pretty cool. [0:29:45]
Martin Woodward: [0:29:46] Have you used Copilot at all yet or- [0:29:48]
Richard Rodger: [0:29:48] I haven't used Copilot actually, no. [0:29:49]
Martin Woodward: [0:29:51] See, that's the thing is, people assume – well, there's two things. So, the people – yes, when – if you go ask somebody that's used Copilot is, it – the headline grabbing, go generate me a tweet thing, that it'll send and do sentiments and ask – it's like, that's a good demo. One of the hardest things with Copilot is doing demos, for two reasons, as a dev rel person, who has to dev rel Copilot.
One is that it learns. And you want to show – trying to demo something learning is insanely hard, because you also want to practice. And so, you do something, it learns as you're doing it, and you go: "Great. Here's an example of me showing you how it's learning from you by looking at my comments, looking at my intent, looking at the other code that's open in my editor and learning. Great.
And then you do it a second time and it's learnt and it's like; "Okay, that's annoying." So, there's little tricks you have to do to trick it into relearning again. Because it does learn and it does learn the way you want to do it. And it doesn't – in practice you don't go use it for generating massive functions and formulas. You typically use it to go: "How do I do this again?" And you type a comment and it just does it. Or you start typing and it's like, "Wow, that's literally what I was about to type." And it just does that as well. So, that's good.
In terms of creativity though, back to what I said earlier, people underestimate – people who are non-developers underestimate the level of creativity there is in engineering and in problem solving. That's the reason we do it; that is what gives us the dopamine rush and that's what keeps us attached to being developers. And computers are not creative; we haven't done that.
And so, I don't think we've anything to fear for our jobs and things like that wise. But what it does is take away a lot of the – like you said, a lot of the mundane side, and allows you to be tons more productive than you were. So, that's why generally, the reaction from somebody who's at Copilot is, you cannot pry this thing from my hands; it speeds me up so much. So, that's been my experience anyway. [0:32:13]
Richard Rodger: [0:32:14] I need to get an Emax; I need to get an Emax package for it. There must be one. [0:32:20]
Martin Woodward: [0:32:20] There is a Vim one. I don't know if you can bothered be escaping. I don't know; is there Emax? There's definitely a Vim plugin anyway. [0:32:26]
Richard Rodger: [0:32:28] My first boss sat me down in front of a Sun terminal, said, "This is the editor you're going to use." Didn't tell me. Got stuck with the muscle memory six months later, and I've not being able to – I've been unable to escape from Emax land. [0:32:40]
Martin Woodward: [0:32:41] Yeah. Or you can switch on Emax key bindings in VS code. But you can run it in a bunch of different editors as well, so it's all good. [0:32:48]
Richard Rodger: [0:32:48] What about the scenario that – the no-code scenario? What I'm feeling here is that you could use this type of AI model to generate the underlying description of the no-code system. And if you extrapolate a bit further, you can use it to generate architecture definitions.
I want to build a zero system that does X, Y, Z or an AW system that does X, Y, Z. There's a standard approach; it splits out your 10 or20 lambdas. Here's a classic microservice system that implements Twitter, something like that. Is that going to happen? Those are all greenfield projects, right? [0:33:37]
Martin Woodward: [0:33:37] Yeah. Put it that way. How many times do you go build greenfield projects like that as a developer? [0:33:43]
Richard Rodger: [0:33:44] Right. Exactly.
Martin Woodward: [0:33:45] And how many times do you go reimplement something that's already been done? It's very rare. Because if it was already done, why aren't you already using it? That's dumb to go build it again, in this sort of – there's a quadrant of cost value, complexity and things. And where we live, we live as developers. I think it was Ken Shuey who said this.
We live at the edge of chaos. We are – we're doing highly complex things that are also using unproven technologies and very novel. If we weren't, we would just go buy them; they would be commodity things. We would just buy a Riverside; we'd go buy a StreamYard or whatever. So, it could probably do things. It could do things that are done a lot, for example solve common programming problems or whatever.
But that ain't what you normally do. Normally, what you do is, you go talk to customers and you think, Wow, it would save you $1,000 a year if I was to move this button six pixels to the right. Okay, let's do that." And you get that by having that understanding in the problem space and iterating and learning, and again. So, I'm personally – there are people – a lot of applications that are written are crud apps around data records.
Look at the popularity of things like Access back in the day; look at the popularity of things like SharePoint and Airtable and things like that. These are system that people go, "Yes, you can create stuff," which will allow you to do business things." And Microsoft are doing a lot of those sort of stuff. I've been a lot – very detached from that since I left Microsoft; went to GitHub, but they're doing a lot of stuff there for those kind of business app and that side of things. [0:35:33]
Richard Rodger: [0:35:33] A bit more on that side.
Martin Woodward: [0:35:34] Yeah, but a lot of the times there, it's – again, it's common patterns. You don't even need AI. It's common patterns that you're theming up, and just in the records really. I don't know, but what's actually more interesting with AI is, we've got this project. If you go to GitHub next – and I'll send you a link for the show notes – but we've got a project there called Brushes.
And that's doing things like, hey, this bit of code I've got, comment it for me. You're a computer that can turn comments into code. Let's do the inverse. Let's take some code I've had to – and how often does this happen, versus building something from scratch. Take some code I'm now the maintainer of, that I've inherited and haven't seen before; explain to me what it does. Maybe reformat that code so it does exactly the same thing but now it's a lot more readable. Those are the sorts of things that AI is – what AI; AI is such a generic term.
These machine – these language models that understand programming languages and human languages, that's what they're astonishingly good at, and those are the sorts of things that I see massive areas of productivity and stuff rather than the – I've been doing computing since the 70s, 80s. But we've always been thinking these 4GLs and blah, blah, blah, are going to do all this stuff. As long as I've been doing it, it's been there, but it's just not there yet. [0:37:01]
Richard Rodger: [0:37:05] So, just feed Martin [inaudible, 0:37:07] book into a large language model and – as your initial prompt, and off we go. [0:37:12]
Martin Woodward: [0:37:12] Yeah, that stuff works. That stuff, you can do. [0:37:16]
Richard Rodger: [0:37:18] It's rare [Loss of Audio] – either we'll come back or – and then ]SciNet?] Time: 0:37:24], and there will be a plan – that discussion. Anyway, I'll just take t [Loss of Audio] Time: 0:37:29. Let's turn back to dev rel, final topic. Which is, how do you lead in dev rel? How do you define a team How do you structure it?
Do you use the community, code, content structure? Do you structure in a different way? Do you look for specific people? It's a very open question, so running dev rel, if you were – if I was to sit down with you for a cup of coffee and say, "I'm taking over dev rel in this 20,000-person software organization. Help! What do I do." [0:38:11]
Martin Woodward: [0:38:13] Needs to be focused on what the business is doing, which sounds dumb, but is – people forget. It's like: what is my business about what does my business care about? And from that, you can use it to base a lot of your decisions. How am I helping my business success? GitHub is a developer company; it's easy for me. But also, my audience are developers; I hire developers, that's great. But then the thing again, where is the company at? GitHub is a company that fundamentally, the whole understands community already.
And there are 100 million developers out there with a GitHub ID. Awareness is not GitHub's problem, which it usually is for most organizations. What is GitHub's problem is putting a human face in front of the company. And especially a few years ago, it was a lot more Googley, in terms of – it was anonymous; it was plumbing; it was infrastructure. But nobody knew a person; they didn't have their gal or their guy at GitHub that they knew that could help them.
And so, for me, the job of dev rel at GitHub was to go make it so every developer feels like GitHub is a thing that they can talk with. And especially open-source maintainers and especially the most important open-source maintainers, that they knew someone, that they could reach out.
Or they knew somebody who knew someone, that we spread these wide networks where they were able to get their frustrations answered, get their feedback heard. Get features that they really needed to do their jobs more successfully; get them built, and that we cared. So, that was what we did.
And to do that, organization structures in place. We've got programs; we've got advocacy. We have docs and things like that, and then the forums and things are maintained over it. They're not part of the dev rel team at GitHub; they're part of the support team. But there's that side of things.
So, it all depends on the structures that already exist in the organization, what the organization's already good at. And then what can you do as a dev rel professional coming in to solve the biggest pain points for that organization and allow that organization to scale. If your answer is go hire 30 advocates, you're always going to be told no. And so. it's how can you have the maximum bang for the buck, so every person you add to your team is adding 10x, 20x in terms of what the organization as a whole can do in terms of scale. Does that make sense? [0:41:04]
Richard Rodger: [0:41:06] You've touched on interesting point which I haven't heard before, which – allowing every developer that interfaces with you – so, it's GitHub in your case, but whatever the organization – to say, "Yeah, I briefly – I asked a question of that dev rel at this conference, or I briefly interacted with them on Twitter. So that there's a human pathway to the organization, as opposed to go read the docs or try and pester people on Twitter to get an answer or- [0:41:38]
Martin Woodward: [0.41.39] It's about scale as well though. You need those things already to scale. GitHub already have those things. Most of the time, it's dev rel in a normal – when you have a real dev rel job rather than my fun one. You are trying to help raise awareness amongst developers of your API, of your thing that does something, that has a developer front – interface to it, that that developer interface is well understood and well used and well known. So, I don't want to underplay the awareness, awareness from those people; it just wasn't GitHub's primary [inaudible, 0:42:17] really big.
Richard Rodger: [0:42:16] No, and that might be set as an explicit goal and that's where they start to buy. [0:42:21]
Martin Woodward: [0:42:21] Yeah, exactly.
Richard Rodger: [0:42:21] Me as a developer assessing a service. I would often be in a situation of deciding what services to use for a client. I'm the one recommends. [0:42:30]
Martin Woodward: [0:42:32] And it's about trust, isn't it, often. [0:42:33]
Richard Rodger: [0:42:34] Yeah. Do I know that I can get hold of people? [0:42:36]
Martin Woodward: [0:42:37] Yeah. And do they care? [0:42:39]
Richard Rodger: [0:42:40] Yeah. And it's- [0:42:41]
Martin Woodward: [0:42:42] And trust is lots of levels. We've talked about availability. You need to be up as a platform or you lose trust. You need to be ethical as a company or you lose trust. You need to be consistent in how you behave and you need to – when you do deprecate services, you need to do that in a responsible way that doesn't break trust. Otherwise, you're going to lose – problems. [0:43:07]
Richard Rodger: [0:43:08] That advice is not being suggested by any recent events at all ever, in any social media platforms that may- [0:43:13]
Martin Woodward: [0:43:13] Never. But you can – but it's interesting. You see things like that and you also see things like ULAs that go wrong or whatever. And I sit back and think, that PMing, that's some kind of PM that's not stood up. Or it's a leadership problem; it's a culture problem, because you've the PM that owns that area hasn't had the safety to be able to stand up and say, "Hey, this is 00 is this the right thing for our customers? Or are we doing this because it's the right thing for us? And you've got to make sure that the customer – that the developer is always at the center of these conversations, but it's easier said than done. [0:43:50]
Richard Rodger: [0:43:50] Safety takes courage, because especially if you've been in a leadership role. The people reporting to you sometimes say really stupid things; you want to wring their neck. But whenever I've done that, I've regretted it very much. [0:44:05]
Martin Woodward: [0:44:06] Even – not even wringing of necks, but it's scary just the impact asking questions can have sometimes, especially when – I forget that I'm a big boss. Some people who's – there's a couple of levels of reporting structure between me and the [likes I might see?] Time: 0:44:26 sometimes, and I forget that. So, then you come in and ask a question or you leave a bit – leave a suggestion for next time. And you might mean it as a -- don't worry about it, but here's a coo tip. But when that comes from the Vice-President of Developer Relations, it's like, oh no, I'm in trouble.
And so, I've had to learn to give my feedback appropriately as well and make sure I – especially if I want to be gentle feedback, if it's like maybe do it this way in the future, kind of thing, then give it -- talk to the manager and have them deliver that feedback rather than it be me and stuff like that. But you do, because you do – psychological safety and having that confidence to be able to do your best work, that to me is the most important thing to help ensure your team is healthy and keep you growing.
But people have to be safe to make mistakes, and oh my goodness, dev rel is scary. As a manager – you said – talk about things that keep you up awake at night. Things that keep me up awake at night are people on my team either being vilified because they're – I'm asking them to go be public, so, a) them getting attacked. Especially, I hire a lot of people who are minorities; I hire a lot of people from diverse backgrounds. I do not want them to get attacked; that scares me.
And the other thing that scares me is making sure I provide them with a safe structure, so they have sufficient air cover, because they will make mistakes. And so, I need to make sure that the mistakes they make are in contained areas and that I keep them out of places that have got minefields that could do big mistakes, that would be bad. And they wouldn't be bad for them; they'd be bad for me, because I'm the one that ultimately is responsible for everything that they say and everything that they do. [0:46:21]
Richard Rodger: [0:46:22] I think that's a wonderful – what do they call it? Servant leadership; isn't it? [0:46:25]
Martin Woodward: [0:46:25] Right, okay, yeah. [0:46:26]
Richard Rodger: [0:46:29] Yeah, that is a high note to finish on, the importance of safety when you're building the team. It always pays off. It's hard to do, but it pays off. [0:46:39]
Martin Woodward: [0:46:39] Very much. And it's a constant struggle as well. [0:46:41]
Richard Rodger: [0:46:41] It is. Martin, thank you. Many -- lots of -- we didn't stick to the planned topics at all, but it was much more interesting. Thank you so much. [0:46:50]
Martin Woodward: [0:46:51] Thanks for your time. Take care. [0:46:52]
Richard Rodger: [0:46:53] 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:47:20]