Technical writing is an essential element of countless products and services. So why is appreciation of it on the decline? Our guest, Chris Ward (or Chris Chinchilla as you may know him), is a talented writer. Not just of technical content, but also of fiction and music! He’s here to kick our writing brains into gear with a simple piece of advice: just start. Richard agrees that he needs to hear this as much as our listeners and that it’s one of the biggest hurdles for people who want to write - sitting down and actually doing it.
A lot of people in DevRel either write, or think about getting into writing. So how do you move from the group of people who want to, to the group of people who do? And why would you want to do it in the first place? There are many reasons. Whether you joined a team for your code and now you’re expected to write an eloquent newsletter on the uses of that code, or you’d like to write a book on your specialist subject to promote your expertise in it. Technical writing is a skill with endless applications. Writing a book for example, can be a fun challenge, as well as an asset you refer back to for years to come. Notice how we didn’t put “to make eye-watering profits” on that list. Yeah. That’s the first lesson in writing books, and Chris tells us all about it. The respect (and money) given to technical writers isn’t what it once was. And yet the services they provide are more relevant than ever.
There’s also the small factor that when you finally publish your book, you’re going to be talking about the contents of it for months and possibly years to come. So you’d better make sure the subject matter is one that you won’t easily get sick of (Chris may be speaking from experience on this one). Chris is also a musician, and he speaks about the connections between music and coding, how pattern recognition makes these two a lot more similar than you might think. And Richard makes Chris’s day by bringing up OctaMED, a long-forgotten Amiga music programme that they both lost hours to back in the day. How far they’ve come!
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.
I'm talking to Chris Ward, AKA chrischinchilla.com. Chris is a prolific technical writer, games developer and general amazing creative person. He has some really solid advice for how you get your documentation organized, how you start from nothing to build it up to get a great developer experience.
And then we also talk about the trouble with having a personal profile and having a company profile, and how you manage the difference between those two things as a developer advocate. All right, Chris, let us talk. [0:00:55]
Main Interview
Chris Chinchilla
Richard Rodger: [0:00:57] Hey, Chris, welcome to the Fireside with Voxgig Podcast. You are a number of different things, a musician, developer, technical writer. Where do we start? Let's start with – you're writing a book; let’s start with that. [0:01:11]
Chris Chinchilla: [0:01:11] Yeah, I'm in a period of transition, which is – so I'm writing. I just spent the past eight years working in contracts but also fulltime, part-time roles as – largely as a technical writer for a variety of tech companies. And I'm slowly getting out of that, and I'm bookending that chapter in my life with writing a book aimed largely at non-technical writers, but people who need technical writing done, for Packt Publishing at the moment. Early days: I am currently on chapter four out of about 10, so early days. But it should be coming out early 2024. [0:01:59]
Richard Rodger: [0:02:00] Awesome. You have my sympathies. [0:02:01]
Chris Chinchilla: [0:02:03] I like writing books. I've written my first fiction novel also in the past couple of years and I'm on the second and third. I do find with writing that once you open the floodgates and you get the practices, the tools, the rituals that work for you, it starts to come a lot easier. The biggest problem a lot of people have with writing is starting. Once you start, it gets easier. [0:02:26]
Richard Rodger: [0:02:28] Yes, and that applies to everything. I'm currently doing the second edition of my book and a lot of that is editing, even going over old chapters and even starting is the hard bit. [0:02:39]
Chris Chinchilla: [0:02:41] I didn't mind the whole revision process; I enjoy it. Just knowing when to stop with revising is the biggest problem. But it's enjoyable because you start to tie the ideas together. I am what they call a pantser, not a plotter. I don't tend to overthink things; I just go for it. And then you revisit what you've done and you think, that's okay. That goes with that. What on earth is that? [0:03:06]
Richard Rodger: [0:03:08] That is a decent strategy, just bang it onto the page and off you go. Let us separate the content of your book – which we'll come back to, but it is also very relevant – and the project of writing the book itself. Because a lot of people who end up working in developer relations do end up thinking about writing books or indeed writing them, because it's a natural part of growing your career and establishing your audience and all that sort of stuff.
Let's start with the big question; what's your advice on writing a non-fiction book. Let's make sure we're focused on that. Because a non-fiction book is for a professional audience and has a particular type of style and approach. So, day one, how do you – what do you do? How do you write a book? [0:04:08]
Chris Chinchilla: [0:04:10] I already alluded to it, but you just start. There are many tools and various things. You could sit there agonizing over what's the best choice and this kind of thing, but none of them will actually help you get – I can't think of a better phrase to say, but pen to paper. That's not what anybody does anymore, but key to screen; I'm not sure. Doesn't sound as good, does it? [0:04:35]
Richard Rodger: [0:04:36] No.
Chris Chinchilla: [0:04:41] Especially with non-fiction and especially with technical books, we have to be honest. Most technical books do not sell in massive numbers. [0:04:50]
Richard Rodger: [0:04:51] No, they do not, no. [0:04:52]
Chris Chinchilla: [0:04:52] You do not write them for the money; you write them for expertise, to be a thought leader, to be identified as an expert in their field etc. So, you have to be – has to be a subject you're prepared then to talk about afterwards. My first non-fiction book was a responsive web design book, when I was still the editor of a mobile channel. And by the time the book came out, I was over that subject and didn't do the book any justice. So, that's something to be wary of. A book takes a while, so make sure it's a subject that you're willing to continue talking about in 18 months' time. [0:05:34]
Richard Rodger: [0:05:36] Yeah, or five years' time with mine even. Did you have to do a proposal for the current book.? [0:05:44]
Chris Chinchilla: [0:05:45] No. I've been quite lucky so far with all my non-fiction that publishers have come to me. It's complete opposite of fiction. With fiction, you pour your heart out and then you spend six months pouring your heart out to agents and publishers, convincing them to do something. Whereas with non-fiction, I have found that they tend to come to you, but the rewards for a successful book, as we've talked about, are less. But the process is quite different. I do have some ideas in my head that I will do next, that I think will be a proposal process.
But I'm also lucky enough that with a handful of fairly well-known tech publishers, I already have a reputation with them. I've done editing and reviews for at least three fairly well-known tech book publishers. I have an established relationship which helps me personally a little bit.
But also, staff change.
So, just because I had a relationship with someone there a year ago doesn't mean they're still there, but it helps a little. But I have some more esoteric ideas there as well that I think will definitely need proposals. And sometimes the proposal also helps you. I said I'm a pantser, but sometimes a proposal helps you think about, is this actually a book or is it just a blog post. [0:06:58]
Richard Rodger: [0:07:00] Yeah, which – and that's a fair point. There are a great many business books that would be better off as articles. What – it's important for anyone who's listening to this, who's thinking, I need to write a book or I'd like to, but I haven't the first clue where to start. You hit an important point, that the technical publishers often scout and approach people.
And if you do go to them with a book proposal, it's much different from, as you say, fiction, because you're – they're looking for content all the time. They know – let us be honest – that on a per-hour basis, this is going to be less than the minimum wage. You're not doing it for the immediate money. So that the chances that you can get a book proposal accepted are much higher than you’d think right? [0:07:46]
Chris Chinchilla: [0:07:48] They are, unless it's a subject that’s' already been covered a lot or it's a subject they've already done and it wasn't very popular. Or they do some market research and there's no market for it. And to be honest with you, a tech writing book is one of those where the publisher we're dealing with had to have a think about it, because it's a niche; it’s a niche topic, to be fair. [0:08:07]
Richard Rodger: [0:08:08] I would argue the case there a littl3e bit; we'll get back to that. We'll get back to that. [0:08:11]
Chris Chinchilla: [0:08:17] I think I get you.
Richard Rodger: [0:08:23] Let's dive into that. The – and that gives us a good segue into discussing the content of the book anyway, which is technical writing. My position on that would be, with the rise of developer relations as an activity and with the rise in the number of developer tools companies, developer focused companies, and with many ordinary business SaaS companies having APIs and SDKs now, the ability to execute developer relations is critical to a lot of businesses. And that means lots of content and that means lots of technical writing. [0:08:56]
Chris Chinchilla: [0:08:57] For sure that is definitely true, but the number of people who do it and the number of people who legitimately value it is on the lower side. It's one thing I have faced over and over again. And I am trying to find ways to put this bluntly but positively in the book, of saying that if you start a career in tech writing/developer relations, you will endlessly meet people who tell you how valuable you are and what you do is, but don't treat you like that. [0:09:31]
Richard Rodger: [0:09:33] And yet the difference that it makes, just to think about this historically. There are lots of reasons why the C programming language was popular, but one of them has to be the Kernighan and Ritchie book and the way that it was so succinct and so well-written. And you could argue the same for Perl. This is showing my age but the camel book by Larry Wall was – it was so – such an amazing piece of writing. [0:10:03]
Chris Chinchilla: [0:10:03] It's interesting you say that, because there are definitely classic technical books that made some of those people and made many other people's careers. But I do worry and wonder; can you think of that many recently? And that's a concern, maybe, but- [0:10:22]
Richard Rodger: [0:10:22] It is, yeah; it is. Where are those fantastic texts that we can all agree on? [0:10:27]
Chris Chinchilla: [0:10:27] I would argue – the only one that jumps to my head immediately, and it's a very different beast, is the Rust book. [0:10:32]
Richard Rodger: [0:10:34] I haven't read that. That's a recommendation. [0:10:36]
Chris Chinchilla: [0:10:36] It's not one you're likely to read from cover to cover, but it's very interesting, because it's not written by one person. And it – the interesting thing with Rust from a documentation perspective as well is, it ships with the product. However you install Rust, you get the "book." And it's very good example; Rust as an entire project is a very good example of developer experience. [0:11:03]
Richard Rodger: [0:11:05] Yeah, because they have all these challenges. You gotta figure out how to do all this borrowing stuff, and as a new way to manage memory. So, there's all these new paradigms and mental models you have to build in the user. I'm going to check that out, good recommendation. [0:11:20]
Chris Chinchilla: [0:11:20] It's one of the ones that's there. I'd also argue that – interestingly, and I – showing my age here. I graduated in 2004, nearly 20 years ago, and I was a year late, so – and even in my first year of uni, we were told to go and buy a bunch of textbooks and didn't need them. And even then, we could find a lot of what we needed online. Especially in computing science, computer science, the ways people access information has changed quite a lot. And we are at the forefront of a completely new way at the moment.
And books serve their purpose, but I don't know how many people learn from reading a book anymore; it's hard to say. They're still being published, so they can't be completely gone, but I don't know how many people would find books career changing anymore; I'm not sure. And if they are, they tend to be the more higher-level ones like books that defined patterns like microservices and event-driven development, and these are also conceptual as well. [0:12:40]
Richard Rodger: [0:12:40] Yeah. They're more conceptual.
Chris Chinchilla: [0:12:41] Yeah, they're more patterns and paradigm changing, where – you can also argue things like white papers, which can be long. I won’t call them a book, but they're long pieces of content. I was at a presentation last night where the presenter was referencing the white paper that described Transformers, the T in GPT. And how interesting he found that to understand what's happening behind the scenes of these things. So, there's still a- [0:13:12]
Richard Rodger: [0:13:12] That's okay; that's another. That's another one to have a look at. Isn't it true though that the primary way that a developer now learns something is through the documentation, the API documentation. If you're going to learn – if you're using AWS, you're reading the AWS docs primarily, rather than a specific book.
Ironically, I did learn how to use AWS from Jeff Barr's original book back in the day. But nowadays, with all the news services, you’re – it's bite-sized chunks of what you're more specifically trying to do. What do you make of the technical writing of Amazon’s documentation, where they have lots of little articles? [0:13:56]
Chris Chinchilla: [0:14:00] I'm going to be careful here.
Richard Rodger: [0:14:03] We are mere flies. We're not even mosquitoes on the back of a very large elephant. They don’t care. [0:14:09]
Chris Chinchilla: [0:14:09] I will say I have generally found the entire developer experience of AWS to be not great. There are reasons for that. There are two largely different practices in tech writing. You could split the world down the middle and how stuff is documented, that roughly fit into the era when a product comes from.
And AWS, having been around for a while, falls into one of the older way. And in my mind, it sometimes shows that they almost tried to recreate an in-app help system on a web page. And without going into the details of what that means from a tech writing perspective, sometimes it shows in that often the – and AWS now has become such a large collection of products that it gets – I find it very disconnected sometimes when you're trying to solve problems.
You get bounced around all over the place, and some of the design behind it influences that. You want to go and set product A up, but in order to set up product A, you have to configure B, C, connect them through D; output it to F and – so you end up with this – I would sometimes argue that if AWS launched now, it wouldn't be as successful, because it comes from a slightly older origin story. Whereas things like Google Cloud for example I find much easier to get started with.
So, in some respects, I would say that you saying you find it easier to – that you learn better through a book makes sense, because it was filling in the gaps that its’ documentation doesn't do maybe. And maybe that's the reason behind the origins of some of these books, is that they were filling in those gaps that documentation didn't traditionally do and now does, but didn't used to. [0:16:15]
Richard Rodger: [0:16:17] Let's go to the other end of the spectrum. Let's say – let’s put ourselves in the shoes of a startup founder and we just launched a developer tools company that does – gives you authentication and a login form or something like that. And I'm either one of the founders or I'm the very first developer advocate hired by the company. And there's virtually no documentation, a couple of blog posts and some very sparse Swagger docs maybe or something like that.
And now you’re' tasked with producing quite a significant volume over time of technical writing to help onboard developers. But you've never really done technical writing before and you've been hired or you're with a founder because you could code. Starting from literally no training, but having to do it on the job, how do you coach someone? What's your advice? [0:17:20]
Chris Chinchilla: [0:17:22] I have two different areas where I would coach. One would be what to create and one would be then how. The what, I would say when you're trying to – and I've worked with plenty of startups, so I'm going to be realistic here and say you should do everything before, but you can't; that's impossible. That's not going to happen.
What I'd say is, you start at two ends; you start at two extreme ends. You start with getting started, how to show people the best your new product has to offer. If you have an intended use case, great. If it's a very general-purpose tool and you're not sure what your use case is going to be yet, that's a little harder., but you probably have a rough idea.
Try to pick a practical use case that is reasonable; don't pick what I would call a toy use case. If someone reads that documentation and thinks this product's great, but this example is so ridiculously basic. I can't see how this benefits me. So, try to find that balance. And that's a whole other conversation, but just to give you the highlights.
Create a get excited guide that – and this is something that dev rel people also focus on a lot, this time to getting started, this time to first API call, whatever it may be. Get people seeing why your product is as good as you say it is and let the product talk for itself. Then I would also then say, go to the other end and produce reference material.
There's a high likelihood you could auto generate a lot of this from code, from spec files, from SDK stubs etc. It's not going to be great, but it shows those people who want to go and dig beneath the surface and figure it out themselves. It shows them all the tools in the toolbox and then they can figure out how to use them and how to apply them together if they want to.
So, you help people see why your product is good; you see people how it's built. And then slowly, over time, you could fill in the middle, because the middle is where you'll spend the longest time, and always be iterating. You can't expect to get it right on day one, because you won't even have it right on day 200. So, slowly fill that in. And that's been my general approach on that side.
The how is more of a linguistic thing, and this is the sum of what I'm writing in the book chapter at the moment. And I've had a few presentations you can probably find online somewhere that I've done around documentation crash courses for developers, 101, whatever you want to call it. And there's a few linguistics and grammatical tricks I tend to point out to people. A lot of technical writing, what you really want to do is make your writing more confident.
There's some wonderful advice on this from fiction writers as well. Stephen King's book has some really good recommendations on this from a completely different perspective, as do a few other books as well. Most of these books were written in the seventies and eighties and nothing has really changed.
And a lot of it is about making your writing confident. A lot of people tend to fill their writing with all sorts of grammatical sugar that is not necessary. Makes the writing complicated and makes the people reading it think, I don't know if this is – what they say is – I don't know if I believe them or not. And fixing a lot of that is quite easy. And saying things like quite easy is one of the things you want to get rid of, but anyway. [0:21:27]
Richard Rodger: [0:21:28] I was going to ask you. Do you have – do some simple examples come to mind? This is good; this is bad. [0:21:33]
Chris Chinchilla: [0:21:34] There's things like getting rid of what's called weasel words is one. Just do this; it's easy, it's simple. Don’t say things like that, firstly because if you – if someone follows it and they – maybe I'll say that again. If someone follows it – you know the ins and outs of your product better than anybody, so of course, you think everything's obvious.
But someone coming to it completely fresh doesn't think that. May not have the same background as you; may not have the same thought process as you. Saying something is easy and then them finding it not is going to make them either feel stupid, think the product doesn't work or many other reasons.
I've always said you should let the quality of the product speak for itself. You don't need to point out how good it is; people should figure it out themselves. Then there's other things like active versus passive voice and all of this helps, and consistency and other grammatical tricks that help.
Every little thing you can do helps remove that cognitive overhead that people need to go through to understand what you are explaining to them. Because fundamentally, they're there to understand what it is you're trying to explain to them. They're not there trying to understand how clever you are at writing, how clever your code is, how much money you've raised.
Sure, that's something they will think about, but that is not documentation's job to convince them of, to stick to the nice, clear, uncluttered explanation of what it is they want to accomplish. And that sounds very easy, but there's a lot of little things we have a tendency to do without thinking that make it more and more cluttered and complex for people to understand.
And it's one of those strange things; it's like getting a reasonable microphone when you want to make an audio recording. You use your indoor microphone and you think, that sounds fine. Then you use a better microphone and you think, oh my God, I sounded terrible. And it's like that with a lot of writing.
Most people, especially in English, can write reasonably good copy; it's fine. And then you get someone to show you – who shows you how to make it better. And you re-read it and you think, wow, that's so much better. So, it's these little things that can lift something from being good to being really good. And it's not hard; it just sometimes requires you to -- people to point them out to you. It's like code and everything. You can code; you can write an algorithm that works, and then someone can show you to write an algorithm that shines. [0:24:20]
Richard Rodger: [0:24:27] Okay, let's also talk about another challenge that people in developer relations face, which is, you can get pretty lucky and you can have a normal job, as a developer advocate or as part of a developer relations team in a larger company. But a lot of people also work freelance, so they are helping startups mostly with building their content, that sort of stuff, building communities.
And you have quite a bit of experience in that mode of operation as well. So, any advice for the developer advocate who wants – some people like to be independent; some people like to be freelance. Is that – how do you manage that life? What are your painful learnings? I have many myself, but- [0:25:20]
Chris Chinchilla: [0:25:22] To be honest with you, I think I have – the best piece of advice is a very simple one, and it's one I've repeated a few times. And I think it could carry you a long way throughout everything else. And that is respect your value. And the flip side of is, most people – sorry, the flip side of that is that the people who disrespect you the least, which we can probably summarize into pay you the least, will waste your time the most.
If they don't value you, they will not value your time or your expertise. And it's difficult, because when you're beginning, you don't know what you're worth; you don't feel confident enough to push for higher things. Maybe you're just desperate for work. But there does come a point where you can start to be more selective.
And sometimes if you have the experience, the fortune, whatever it may be, to start from that point, then do it. It filters people out, and if you’re ever in a process where someone is trying to push you down, they’re generally a customer who’s worth avoiding, to be honest with you. Unless you’re being completely ridiculous with what you’re asking for, but you’re probably not, so- [0:26:38]
Richard Rodger: [0:26:40] That is – you’ve hit the nail on the head, so to speak; that is really the critical thing to realize. Which is – there’s a saying – I can’t remember who said it, but there’s – if someone shows you who they are, believe them the first time. And that is completely true with clients, because if they start nickel and diming you on day one, they’re going to be difficult the whole way through. And I think- [0:26:40]
Chris Chinchilla: [0:26:40] Pretty much.
Richard Rodger: [0:27:07] -you can also – you’re allowed to fire a client. You don’t have to keep working for them. [0:27:11]
Chris Chinchilla: [0:27:11] For sure, that’s definitely something that’s worth considering. And it’s hard; it is hard when you’re starting out, because you probably need the money. Whenever you make a big career change, especially – not when you’re beginning, of course; that’s a big career change it’s had to prepare for, but if you’re making a big career change, have a little bit in the war chest, as it were, to protect you from time wasters, to get the best you can out of it. [0:27:48]
Richard Rodger: [0:27:51] Yeah. And do you have any advice on finding clients? That’s – often the way – often the reason people end up with bad clients if they’re having trouble selling their wares. [0:28:04]
Chris Chinchilla: [0:28:07] In honesty, the only advice I’ve ever had for anything that involves you getting out there and being found is, you have to market yourself. How you do that has changed. And bizarrely, one of the best anecdotes I can eve recall for what does and doesn’t work is when I was unwittingly a professional musician.
Which was, people would say to me, “How did you get successful? What did you do? What was the secret formula?” There isn’t one; there isn’t a secret formula. But you have to try everything and you see what works. If you try nothing, then nothing’s going to work. And especially these days, we’re surrounded by people on Medium and Substack and LinkedIn, telling us how overnight, they sold 100,000 copies of something. And we know that – we all know that’s really not true. And also for- [0:29:07]
Richard Rodger: [0:29:07] It’s very discouraging for people starting out to see all these Twitter BSers who are going, “I got this much revenue in six months and this is how I did it.” Seriously, it’s all- [0:29:19]
Chris Chinchilla: Yeah, they were probably [inaudible, 0:29:19] for months or-
Richard Rodger: [0:29:21] Yeah. Even if it’s real-
Chris Chinchilla: -a [inaudible, 0:29:21] perk.
Richard Rodger: [0:29:24] -even if it’s real, the thing that they’re talking about is not what they’re selling. They’re selling themselves and the fact that they can charge you money for consulting or something like that. [0:29:34]
Chris Chinchilla: [0:29:35] Those are called pyramid schemes. If you’re not prepared to put yourselves out there – I’m just saying there isn’t freelance work for you, but it will be harder. And we’re talking about developer relations; these are people who are willing to put themselves out there. I don’t think we have to say that – there’s differing levels of that for various reasons and various justifications. But I also think there’s more ways to put yourself out there without putting yourself out there, so- [0:30:07]
Richard Rodger: [0:30:07] Is this – okay, so this is – you’ve touched on an interesting little side topic. If you are working as a developer advocate, often part of the value is the fact that you have built up an audience, whether that’s off the back of content for a specific company or you’ve written a book. Or just your personal blog has a lot of good technical content or whatever and you’ve done a whole bunch of conference talks.
But there is a separation, isn’t there, between your developer advocate persona and the specific company that you work for. Now if you’re freelance, maybe it’s not – there’s possibly not so much tension there, because you’re seen as being – as having been brought in and external, but you’re generating valuable content. But if you work for a company and your identity gets a little bit wrapped up in that, how do you balance that? How do you balance it? Because you’re going to need to take that persona to the next company, right? [0:31:10]
Chris Chinchilla: [0:31:10] Yeah. I will admit I’ve struggled a little bit with that. And it’s why I’ve gone back to contracting slash – even transitioning out of contracting into doing my thing. Is I realize I have a strongish or developing personality identity that often companies think they want, but often, what you are and what they want are not always connected. And when you’re swallowed into the machine, as it were, sometimes you have to compromise in different directions. And that does and doesn’t work for some people.
And when you freelance, you have the opportunity to pick and choose a bit. But in some respects, it changes, because you’re also – you may also not even be acknowledged for what you’ve done for them. I’ve done – I’m not entirely sure with freelance developer relations work, because obviously, it’s very much more you.
Whereas documentation can be a bit anonymous sometimes. If you make a video or something like that, it’s clearer to you, but it’s – I don’t know. There’s people who can make it work for them and there’s people who can’t. And I’m not honestly sure if I have an answer to this question in all honesty. [0:32:48]
Richard Rodger: [0:32:48] It’s a tricky one, isn’t it?
Chris Chinchilla: [0:32:48] It’s a tricky one, and I think I’m still figuring it out myself. I’ve just got to a point in my career where I realize I have to be me and I have to figure out what that’s going to mean. Because I have had too m many places where I go in as Chris to a company and what I think of as Chris and what the company thinks of as Chris is not entirely compatible. It – and I get frustrated with it. Other people can go with it more, but for whatever reason, I get frustrated. And then that starts to grate in both directions. [0:33:27]
Richard Rodger: [0:33:28] Yes, because you see – and let’s take the example of a Twitter account. An ordinary developer might have a personal Twitter account where they talk about rugby or whatever. And then if you’re a developer advocate, your Twitter account and talking about the technical stuff and posting pictures of your talks at conferences or whatever is part of the job.
But at the same time then, you have posts about your personal political opinions or something like that. And that’s where it gets – so you see some people are – it’s all out there, everything. The company stuff, the personal stuff, it’s all one big mishmash. And then you have some people where their Twitter account is always just professional. So, people seem to be approaching it in different ways, right? [0:34:17]
Chris Chinchilla: [0:34:18] Yeah. I’ve been thinking about this a little bit recently from a different perspective with my – especially my fiction work. I’ve met some people – I run a writers’ group here in Berlin. We have people from all flavors of writer or professional level. And there’s one guy I met recently who makes a living out of self-publishing on Amazon KDP, Kindle Direct Publisher. And he does it under multiple personalities.
He has a name that is a romance writer; he has a name that is a gay romance writer. He has a name that is a horror writer and he has a name where he puts what he actually wants to write. And he pumps it out, all these different personalities. And I was thinking about that and I was thinking, do I want to take that path or do I want to always be me? And every aspect of me that is me is out there. And I think I have to be the latter. [0:35:20]
Richard Rodger: [0:35:23] Fair play to that guy. And maybe it is a bit more normal for writers, for sure, but- [0:35:29]
Chris Chinchilla: [0:35:29] I think I have to be the latter. [0:35:30]
Richard Rodger: [0:35:31] And it’s so much work. Wow. [0:35:32]
Chris Chinchilla: [0:35:32] And to be fair, in a professional non-fiction writing perspective, that – you will find it hard to find that combination where you can be at a company and they’re okay with that. But at the same time, it’s like that freelance discussion we had. You will also filter out slowly the places where it was never going to work out. So, maybe it’s a lot more – it’ll take you longer to find that right fit, but you will. And it will be much better in the long run. [0:36:08]
Richard Rodger: [0:36:09] But just for-
Chris Chinchilla: [0:36:10] I don’t know.
Richard Rodger: [0:36:11] Just from the company side for anybody listening, trying to deal with this problem from the company perspective, it’s important to remember that part of the value that a developer advocate brings is that they are a real person. They’re credible; they’re developers. So, the downside of a few rough edges, maybe it’s not as terrible as you think. Because it shows that they are credible when they say stuff about a product. Because they’re also talking about their dog. [0:36:42]
Chris Chinchilla: [0:36:43] We have to be very careful though, is that we’re talking about professional and then maybe some less serious personal opinions. But there are places where people expressing their opinions about things may be completely incompatible with your business practices. And we don’t need to go into details, but people can- [0:37:09]
Richard Rodger: [0:37:09] Everyone knows.
Chris Chinchilla: [0:37:11] Yeah, you know. And that is something else. And there will still be companies that are – find that fine and are fine with it. But we have to be very careful that – posting pictures of your dog is not the same as offensive language and things like that. That’s different; that’s different [0:37:31]
Richard Rodger: [0:37:32] We have time for one final question, which is, how does a musician end up as a coder? [0:37:38]
Chris Chinchilla: [0:37:39] It’s pretty common. Especially in the era that I was playing in, which is the early 2000s, when the traditional model of music wasn’t working anymore, but the new world hadn’t happened yet. This was the era of MySpace and Napster, so no-one was making money from music. It meant that a lot of people from that era had to find jobs afterwards.
And it’s not that uncommon. There’s a lot of crossover between – these days especially – between music and coding. And there’s a couple of reasons. One is that there is some brain science, whatever the word is, between the patterns in your brain that code and the patterns in your brain that make music.
Music is quite – I don’t want to demean music, but it is – it does follow lots of patterns and so does coding. Taking those patterns and doing something creative with them is a whole other process, but fundamentally, music is quite algorithmic. So, there are – they do trigger similar things in the brain.
The other is practicality, relating a little bit back to the freelance thing. Music pays next to zero; coding pays quite well, so – and it’s quite flexible, and same with music. If you could get that combination where you work some of the time, you go out and play some of the time, and you have a degree of flexibility in terms of income and time, it’s a very good, perfect combination in some respects. [0:39:23]
Richard Rodger: [0:39:24] Have you ever been tempted to take a guitar on stage for a talk and do a sung version of your technical talk? Which I have- [0:39:33]
Chris Chinchilla: [0:39:33] No, not really, because it’s not ever been-
Richard Rodger: [0:39:34] I have seen it done; I have seen it done. [0:39:36]
Chris Chinchilla: [0:39:36] Yes, so have I. It’s not my style, and there are people who do it. Dylan Beattie is one. [0:39:43]
Richard Rodger: [0:39:43] Yes, Russ Miles is another; Russ [inaudible, 0:39:47].
Chris Chinchilla: [0:39:47] There are people who do it. There are – it’s a thing people can do, but that’s not my – if it was to be my style, probably be more likely – which I’m starting to do in a lot of my YouTube videos as well, is using the music to explain other things, other concepts. Also writing the music, that kind of thing. But there are a lot of tools that directly cross over between coding and music.
I saw a great – the after party for Build Stuff in Vilnius last year, there was a duo doing coded music. And electronic music is a whole other world of music that is created in very different ways from traditional musicians, which I’m starting to try and get my head – I live in a city full of electronic musicians in Berlin. [0:40:41]
Richard Rodger: [0:40:41] Of course, yeah, nearly the world capital of that sort of thing, right? [0:40:45]
Chris Chinchilla: [0:40:45[ Yeah. I’m still – I’m just starting to appreciate that. I come from a very much more – bunch of people in a room playing analogue instruments into amplifiers. I’m still figuring that out myself. I’m starting at the moment at MIDI keyboards and things, which is- [0:41:00]
Richard Rodger: [0:41:00] And are you tempted to go into algorithmic music, where you write code that writes music? [0:41:04]
Chris Chinchilla: [0:41:07]] Yes and no. What I want to move into, from a musical perspective in the coming future, is more soundtracks, which is what I always wanted to do before I got distracted by bands. And there’s definitely, depending on where you are creating soundtracks, like games for example. A lot of it is semi-algorithmic these days.
There’s also wonderful tools like MaxLive and many others. Also, another one from here, Isadora, where you can hook music up to triggers. And all sorts of things, like this MIDI – MIDI itself is a fascinating technology because Midi is a series of signals. And do you know, MIDI has been around for decades, almost as long as I have. [0:41:53]
Richard Rodger: [0:41:53] Yeah, it’s really old, isn’t it? It’s- [0:41:54]
Chris Chinchilla: [0:41:54] And version two was only released five years ago. [0:41:58]
Richard Rodger: [0:41:59] So, it’s one of those protocols that’s really well-designed from day one. Wow. [0:42:04]
Chris Chinchilla: [0:42:04] Exactly. And – but all it is is a series of triggers. You buy a MIDI keyboard; you buy a MIDI drumkit, because that’s what musicians expect it to be. It doesn’t have to be that at all. And there are various tools. I have a string deck in front of me; I have a MIDI keyboard in front of me. Tools like BetterTouchTool on the Mac and then other things.
I can cherry pick all of this to do whatever I want. I can play music on my string deck; I could use my keyboard to write an email. It’s all triggers. What you do with those triggers is up to the software. There’s – when you talk about coding and music, there is already this quite rich world around it, and it’s quite a lot you can hook up to things.
And programs like Live take this to an extreme, where you can use the input of one thing as an output to another thing and all this sort of thing. It’s used a lot in live performances, but what you connect to each other is – it’s up to you. And tools like OBS also hook into this ecosystem as well. It’s quite a fascinating world; there’s a lot of it in Berlin as well. And this is something I was always interested in when I was younger. I was an Omega fanboy when I was younger. [0:43:16]
Richard Rodger: [0:43:18] Oh, wow. Let me get really obscure now. If you had an Omega, if you ever – there was a music program for it where you – it was like tracks where you would put in the notes at certain points in the track. I think it was called MED, Music Editor. [0:43:38]
Chris Chinchilla: [0:43:38] I know exactly what it was called; it’s super weird. You’ve made me very happy, because the program was called OctaMED. [0:43:46]
Richard Rodger: [0:43:47] Yes, that’s the one.
Chris Chinchilla: [0:43:48] And I recently trashed an archive hard drive and had to pay a lot of money to get it recovered. And I thought, well, I’ve paid all this money; I should see what’s on here now. And I found a whole bunch of my old music. Most of it I could open in GarageBand and Cubase because that’s what I created it with. But some of it was much older and was made in OctaMED a million years ago. [0:44:11]
Richard Rodger: [0:44:11] Wow. That’s amazing. [0:44:13]
Chris Chinchilla: [0:44:13] OctaMED was amazing, because they managed to do some trickery to the sound chips, to- [0:44:19]
Richard Rodger: [0:44:19] They double the channels, wasn’t it? [0:44:20]
Chris Chinchilla: [0:44:21] You ready for this, kids? They doubled it to eight channels. [0:44:23]
Richard Rodger: [0:44:24] Yay!
Chris Chinchilla: [0:44:26] Crazy at the time. [0:44:27]
Richard Rodger: [0:44:27] I remember that, yeah. [0:44:28]
Chris Chinchilla: [0:44:29] So, I went down this journey of figuring out if I could open these files and I haven’t explored it fully yet. But it’s quite hard to find a download of it that will run in an Omega emulator. But at a certain point, someone made a Windows fork, and you can- [0:44:47]
Richard Rodger: [0:44:48] There’s a whole subcultures of this type of music composition style, where you just put in – F sharp happens at this time point in this channel, and it’s this instrument. [0:44:58]
Chris Chinchilla: [0:44:59] The reason you make me very happy is, I’ve mentioned this software to many people and no-one’s ever heard of it. You’re the first person who’s- [0:45:04]
Richard Rodger: [0:45:05] I spent a lot of completely – nerdy teenager in their bedroom, mucking about with that. Mostly trying to reproduce Axl Foley and failing miserably, because- [0:45:14]
Chris Chinchilla: [0:45:14] Once I’ve recreated these tracks, I will let you know and- [0:45:19]
Richard Rodger: [0:45:20] Wow, that’s fabulous. [0:45:20]
Chris Chinchilla: [0:45:21] There was one quite famous album I came across recently that was created with it. Let me look it up so we can tie that up, because we will leave people wondering what it was because it’s- [0:45:33]
Richard Rodger: [0:45:33] What on earth? Yeah, we’re going to have to put in links to this stuff. [0:45:35]
Chris Chinchilla: [0:45:35] Fairly well-known album that was made with it. Where was it? Calvin Harris. That’s it. There we go. [0:45:48]
Richard Rodger: [0:45:50] We could do a whole podcast on the Omega and all that world. [0:45:52]
Chris Chinchilla: [0:45:53] It’s been done, but yes, we could. [0:45:56]
Richard Rodger: [0:45:57] It doesn’t matter; I’d obsessively do it again. Chris, let’s wrap; let’s wrap on that. That is a high note – pun intended – to wrap up. Thank you so much; this has been fabulous. And I’m delighted as well; you just made my day. [0:46:10]
Chris Chinchilla: [0:46:12] No worries.
Richard Rodger: [0:46:14] All righty, take care. Bye-bye, bye-bye. [0:46:16]
Endnote
Richard Rodger: [0:46: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.46.45]